This document discusses continuous integration practices including automatically building code, testing it, and creating deployment packages. It describes how continuous integration has evolved to incorporate more automated testing and deployment to test environments. The document advocates treating deployment to test environments as a "known release package" that is logged, versioned, and can be rolled back in a similar way to application releases. This helps ensure production deployments are replicable and auditable.

1. Continuous
Integration
Evolved

2. The process of continuously applying
certain practices that the project team
holds dear in an attempt to make the
feedback loop as tight as possible thus
enabling the team to address issues raised
quickly.

3. CI Today
1. Build the codebase
2. Automatically test the codebase
3. Create deployment packages for the
codebase

4. Boundaries in Development
Development Testing Operations
Team Team Team

5. Doing more?
• Auto-releasing to test environments
…or even production
• Ensure the code works in the deployment
environment
• Verify multiple system integrations
• Verify infrastructure integrations

6. Involving the Test Team
• Current involvement usually is manual
• Automated (triggered) push deployments
• Tester pulled deployments

7. Involving the Test Team
Build
Automated
Testing
Release Package
Creation
Test
Environment
Installation

8. The Test Team…
• Emails someone about success/failure
• Updates a system to indicate the build
testing status
• Almost always is a dead end step

9. What We Know
• If the system has passed:
– The current version is production ‘release-
able’
– The different components/systems in the
test environment work together

10. What We Have
• Validated build
• Known integration components
• Known configuration

11. What We Should Do
• Create a ‘release-able’ snapshot of the
components/applications verified
• Creating a production release manifest
• Log information about the verified
component combination

12. Multiple Systems
Development Testing Production
Environment Environment Environment
Your
v0.0.1.11 v0.0.1.10
v0.0.1.11
App
Known
Internal
v1.0.8.33 Release v1.0.8.33
App 1
Package
Internal
v2.9.0.1 • Log the manifest v2.9.0.1
App 2
• Archive

13. Known Release Package
• Manifest of integrated systems and the
versions required to replicate the
environment where testing passed
• Not all systems will be installed, only
those that changed

14. Known Release Package
• Archive-able
• Log-able and Auditable
– Creation of the package
– Installation of the package
• Doesn’t have to install unchanged pieces
• Rollback capabilities

15. Multiple Systems
Development Testing Production
Environment Environment Environment
Automated Smoke Test
Your
v0.0.1.11 v0.0.1.10
v0.0.1.11
App
Known
Internal
v1.0.8.33 Release v1.0.8.33
App 1
Package
Internal
v2.9.0.1 v2.9.0.1
App 2

16. Operations
• Receive a known release package for
installation
• Can audit
– Installation timestamp
– Installer
– Manifest contents
• Can rollback by using the previously
installed package

17. Operations cont…
• Automation
– Installation
– Auditing
– Verification (smoke test)
– Rollback

18. Further Thought Points
• Database change management
– Release rollbacks?
– Incremental == Additive
• High availability
– Multiple installations of Known Release Package
– Additive releases
• Environment configuration
– Treat like an application release?
– Version, audit, package, etc.

19. Assumptions
• Ability to test in isolated environments
– Tester isolation
– *NOT* system isolation
• Some ability to manage release packages
• Automation

20. Challenge Your Assumptions
• Don’t Known Release Packages seem a lot
like a Nuget Package?
• Anything you can do in a Nuget package
becomes part of your release
• http://haacked.com/archive/2011/01/15/buil
ding-a-self-updating-site-using-nuget.aspx

21. @dbelcham
donald.belcham@igloocoder.com