Continuous Delivery
Agile Software Development
My Background
Continuous Integration
Scrum
Deployment scripts
Testing
DevOps
…
But: how to tie all this together?
What is it?
Keywords:
Automation
Quality
Releasing (as opposed to òjust’ deploying)
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
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
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
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
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.
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
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)
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
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
Feedback slide
How many people
use version control for their source code?
use Continuous Integration?
have automated deployments?
do Continuous Delivery?
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
A Deployment Pipeline
Also known as Continuous Integration Pipeline, build pipeline, etc.
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?
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
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)
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
Tools
Hudson (Jenkins)
TeamCity
Anthill Pro
Cruise Control
Bamboo
…
Questions
What languages you use?
What build tools do you use?
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.
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
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
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
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
The provisioning stack
Continuous Deployment
Deploy all changes that pass your automated tests to production
Pro’ s and Con’ s
Only when there’ s time left
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
Practical session later?
For example, setting up an environment with Vagrant and configure it with Puppet/Chef.