CONTINUOUS INTEGRATION,
DELIVERY & DEPLOYMENT
ONE CLICK DELIVERY
QUICK POLL
SAFE?
Are you using version
control?
QUICK?
Can you release new
version of your software in
one day?
QUICK AND SAFE?
Can you release new, well-
tested version of your
software in one day?
DEVELOPMENT NOW
DEVELOPMENT NOW
Each developer has feature branches
If the version control is used at all
Features are deployed when completed
Integration issues
Small test suite
PROBLEMS
Bringing software into production is hard
Takes a lot of time
Error prone
SOLUTION – CONTINUOUS
INTEGRATION
CONTINUOUS INTEGRATION?
“Continuous Integration is a software development
practice where members of a team integrate
their work frequently, usually each person
integrates at least daily - leading to multiple
integrations per day. Each integration is verified
by an automated build (including test) to detect
integration errors as quickly as possible.”
- Martin Fowler
CHANGE THE WORKFLOW!
Checkout/update
Code
Build & test locally
Update (merge)
Retest if changed
Commit
Continuous Integration server takes over …
CHANGE THE VERSIONING!
No ‘feature’ branches
Temporary ‘developer’ branches
Good to test crazy ideas
Branch and throw away
Trunk must always compile
Avoid big scary merges
HOW TO HANDLE FEATURES
No ‘feature’ branches
Features can be toggled on and off via
deployment or compilation configuration
Also helps with Continuous Delivery/Deployment
Keep features small
Improve features interactively
Introduce early, then improve
SIDENOTE – VERSION CONTROL SYSTEMS
History
Log
Blame
Revert to version
Bug-finding tool
Branches
Tag/mark every release
Always use VCS – even for single-person projects!
TESTING
Automate everything
If it hurts, do it more often. Continuously.
Fail fast.
Integration testing
Unit testing
Functional testing
Application testing
Mobile testing
Whatever you don’t test against, will happen
REQUIREMENTS
REQUIREMENTS
Source code repository (version control)
Subversion, Git, Mercurial, …
Project build
MSBuild
FinalBuilder
…
Testing
TestComplete
Continuous Integration server
CI SERVER IN ESSENCE
while true do
begin
if change_checked_into_vcs then
begin
if not build then
report_error;
if not test then
report_error;
end;
sleep;
end;
CI SERVERS
Continua CI
VSoft (FinalBuilder)
Jenkins
Hudson fork
Java
Commercial support - Cloudbees
[Link]
XML configuration :(
PROJECT MONITORING
CI RECOMMENDATION
Use a separate server (or VM)
For CI, or
For CI + build, or
For CI + build + test
CENTRAL DOGMA
Build early, build often
On every checkin
Check in early, check in often
BENEFITS
BENEFITS
Brings order into chaos
Everything could be achieved without the
Continuous Integration, but …
CI is the great enforcer
BENEFITS
Code is always in the consistent state
Code always compiles
Automatic tests
Automatic feedback on product readiness
CODE ALWAYS COMPILES
CODE ALWAYS COMPILES
Code should always build and test.
→ Continuous Delivery
CONTINUOUS DELIVERY
CONTINUOUS DELIVERY?
“The essence of my philosophy to software
delivery is to build software so that it is
always in a state where it could be put into
production. We call this Continuous
Delivery because we are continuously
running a deployment pipeline that tests if
this software is in a state to be delivered.”
– Jez Humble, Thoughtworks
CI <> CD
CD = CI + fully automated test suite
Not every change is a release
Manual trigger
Trigger on a key file (version)
Tag releases!
CD – It is all about testing!
CONSIDER THIS
“How long would it take your
organization to deploy a change that
involves just one single line of code?”
- Mary and Tom Poppendieck,
Implementing Lean Software
Development
CONT. DELIVERY VS. DEPLOYMENT
Continuous Delivery
integratio MANUAL
unit validation deploy to
build n
tests tests production
tests
Continuous Deployment
integratio AUTO
unit validation deploy to
build n
tests tests production
tests
CONTINUOUS DEPLOYMENT
CONTINUOUS DEPLOYMENT
A WORD OF WARNING
Continuous integration is simple.
Continuous delivery is doable.
Continuous deployment is a hard problem.
DEPLOYMENT SCHEDULE
Release when a feature is complete
Release every day
DEPLOYMENT STRATEGIES
Zero-downtime deployment (and rollback)
Blue-green
Two environments
Install on one. Switch. Switch back on problems.
Canary release
Deploy to subset of servers
Real-time application state monitor!
PROBLEMS
Technical
Databases
Schema migration
Revert!
Change management software
Configuration
Human
Even more important
Automatic deployment = great fear
Customers don’t want software to constantly change
TRANSITION
HOW TO INTRODUCE
(Introduce VCS)
Gain expertise
First step accomplished – you are here
Automate the build
Introduce tests
Prove the concept
Introduce CI system
Run it in parallel to existing infrastructure
Give it time
Show the win-win
NOTES FROM THE FIELD
WHAT WE FOUND
Continuous Integration is relatively easy
It is all about communication
Continuous Delivery is harder (but we are getting
there)
Some things are hard to test automatically
You need dedicated test-writers
Continuous Deployment is not a requirement
Customers don’t want it
Only for mission critical systems
SIDENOTE - VCS RULES!
Disks are large, store as much as possible in the
VCS
Continuous Integration server configuration
should be stored in the VCS
You should be able to restore complete build
system from the VCS (after installing necessary
software)
IMPLEMENTATION
Run everything in VM
Backup!
CONTINUOUS
INTEGRATION/DELIVERY/DEPLOYMENT
It is all about the people!
SOFTWARE
Continua CI
[Link]
Jenkins
[Link]
[Link]
[Link]
BOOKS
Continuous Delivery
[Link]
Continuous Integration
[Link]
Implementing Lean Software Development
[Link]
Release It!
[Link]
REFERENCES
[Link]
[Link]
[Link]
[Link]
[Link]
delphi/
[Link]
[Link]
[Link]
[Link]
[Link]
with-continua-ci
[Link]
QUESTIONS?
