Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Continuous Deployment


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Continuous Deployment

  1. 1. ContinuousIntegration Evolved
  2. 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 thusenabling the team to address issues raised quickly.
  3. 3. CI Today1. Build the codebase2. Automatically test the codebase3. Create deployment packages for the codebase
  4. 4. Boundaries in DevelopmentDevelopment Testing Operations Team Team Team
  5. 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. 6. Involving the Test Team• Current involvement usually is manual• Automated (triggered) push deployments• Tester pulled deployments
  7. 7. Involving the Test TeamBuild Automated Testing Release Package Creation Test Environment Installation
  8. 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. 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. 10. What We Have• Validated build• Known integration components• Known configuration
  11. 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. 12. Multiple SystemsDevelopment Testing ProductionEnvironment 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. 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. 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. 15. Multiple SystemsDevelopment Testing ProductionEnvironment 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. 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. 17. Operations cont…• Automation – Installation – Auditing – Verification (smoke test) – Rollback
  18. 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. 19. Assumptions• Ability to test in isolated environments – Tester isolation – *NOT* system isolation• Some ability to manage release packages• Automation
  20. 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• ding-a-self-updating-site-using-nuget.aspx
  21. 21.