Continuous Delivery

1. Continuous Delivery • Agile Software Development Erwin Bolwidt <ebolwidt@worldturner.com>

2. My Background • Continuous Integration • Scrum • Deployment scripts • Testing • DevOps • ... • But: how to tie all this together?

3. What is it? “Releasing high quality software fast through build, test and deployment automation.” • Keywords: • Automation • Quality • Releasing (as opposed to ‘just’ deploying)

4. Where does it fit? • The DevOps movement • Shares common goals • Development vs Operations • Deployment automation • Age-old practice by smart developers • Loads of scripts, tools, commercial and open source products • Part of Continuous Delivery

5. Where does it fit? • Agile and lean software development • Potentially shippable product (Scrum) • Deliver as Fast as possible (Lean) • Many concepts in Continuous Delivery come from Lean • Release Early, Release Often

6. Continuous Delivery • A very good book • Explains how to design/set up your continuous delivery proces • Including CI, deployments, etc. • Explains good software development practices that are necessary for CD

7. Anti-Pattern: Deploying Software Manually • Needs lots of documentation with steps • That are misinterpreted, and untested in a production-like environment • Many corrections during a release • Manual testing to confirm deployment • Releases take hours instead of minutes • Frequent roll-backs • Late nights

8. Instead... • Automate deployments as much as possible • Scripts equal up-to-date documentation, encourage cooperation and sharing • Encapsulate expertise and are version-controlled like any other source code • Automation makes processes repeatable, testable, less boring and fast.

9. AP: First to production-like after Dev finished • Testers have only tested in a development environment • Production deployers have never done deployment before • All kinds of infrastructure-related problems pop up after the PL said that development was done • Lots of fighting between operations and development

10. Instead... • Start deploying to a production-like environment (staging) as soon as you start developing • Integrate testing, deployment and release into a standard part of your development process • If you already have good Continuous Integration, this means: add deployment/release to it (correctly)

11. AP: Manual Configuration of Prod Env • Configuration of an environment is a lot • Deployments to production fails after succesful deployments to other environments • Differences between nodes in production • Cannot roll back your environment • Different versions of packages • Basically: No overview, no control

12. Instead... • Set up your entire environment using an automated process that is stored in version control • Specifically any and all configuration - of your OS, of OS tools and middleware, and of your application • Your production environment is key - it must be reproducible in your staging and dev environments

13. Feedback slide • How many people • use version control for their source code? • use Continuous Integration? • have automated deployments? • do Continuous Delivery?

14. The Deployment Pipeline • Describes your process of getting software from version control into the hands of users. • Similar on for most projects on a high level • Inspired by ‘Value Stream Maps’ from Poppendieck’s Lean Software Development book • Each step in the pipeline produces output which is taken up (pulled) by the next step when ready

15. A Deployment Pipeline • Also known as Continuous Integration Pipeline, build pipeline, etc.

16. Trade-offs • Early feedback v.s. more thorough testing • Early feedback v.s. more production-like environments • How long is a ‘build’ allowed to take? • Can it be split up?

17. Continuous Integration PreReqs • Version Control • A command-line automated build, outside IDE • Team agreement to do CI properly • Check in frequently • Maintain a sizeable Automated Test Suite • Keep build and test phase short (*) • Keep your workspace clean

18. CI how-to • Never check in on a broken build!! • When you’re done developing: • check to see if build is running - wait to see if it succeeds • update to latest version • build everything locally, and if it passes • check your code into version control • wait til CI server succeeds (don’t go home)

19. Noteworthy • Teams that are not in the same room need to have better agreements • Time zone differences need to be managed (and especially: never go home on a broken build) • Branches degrade CI usefulness • Distributed version control systems can be a pain and need to be managed very well if they are really distributed

20. Tools • Hudson (Jenkins) • TeamCity • Anthill Pro • Cruise Control • Bamboo • ...

21. Questions • What languages you use? • What build tools do you use?

22. Multi-stage builds • After the commit stage, an automated acceptance testing stage is typically run. • Depending on your CI servers this can be a build that is automatically triggered by the completion of the commit stage build. • Some CI servers can model this nicer.

23. Automated acceptance tests • They typically run much longer. • Some CI benefits are lost; this is a trade-off. • Before running these, the application (and the environment) is first deployed automatically • Practices like BDD and ATDD can be used here • Parallelization can speed up things a lot • Idea: use EC2 to run tests

24. Manual Testing • Most applications still need manual testing • Set up a page on which the testers can instantly deploy the right version of the app and environment onto their testing environment

25. Releasing • Releasing to production takes more • Don’t forget maintenance/support, monitoring, environments, change process, application configuration, external systems, logging, disaster recovery, SLA, capacity, upgrades, etc. • Agree on things as soon as you can: release strategy • Overlaps area of DevOps

26. How to automate? • Your own scripts (Ruby is popular) • Frameworks (Capistrano, Fabric, ...) • DSLs (Puppet, Chef) • (Commercial) products • XebiaLabs DeployIt, ThoughtWorks Go • Gazillions of other tools

27. The provisioning stack

28. Continuous Deployment • Deploy all changes that pass your automated tests to production • Pro’s and Con’s • Only when there’s time left

29. Wrap-up • Read the book - very inspiring, full of useful detail • Adjust your definition of done - it’s only done when it’s deployed • Grow over time: improve your testing strategy, make use of new possibilities

30. Practical session later? • For example, setting up an environment with Vagrant and configure it with Puppet/Chef.