1 / 30

Continuous Delivery

Continuous Delivery. Agile Software Development. Erwin Bolwidt < ebolwidt@worldturner.com >. My Background. Continuous Integration Scrum Deployment scripts Testing DevOps ... But: how to tie all this together?. What is it?.

amie
Download Presentation

Continuous Delivery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related