Linuxtag 2012 - continuous delivery - dream to reality
-
Upload
clement-escoffier -
Category
Technology
-
view
1.037 -
download
1
Transcript of Linuxtag 2012 - continuous delivery - dream to reality
Continuous Delivery
Dream => Reality
Dr. Clement Escoffier, akquinet
This is a work of fiction. Names, characters, places and projects are all products of the author’s
imagination. Any resemblance to actual events, locales or projects is
entirely coincidental
SITUATION
Again, purely imaginary ;-)
• Running for 2 years
• 4-6 developers
• Agile (Scrum)
Quite a big project
As in all big projects,the build is chaotic
Taking forever, Intermittent failures,Inconsistent output,
Non-reproducible builds,Authorization failures
…
Releasing => Stress
Delivery => Error-prone
=> Delays
Delays => Customer
Trust => Pressure
Quality => Technic. Debt
=> Non optimal project situation
“Let’s deliver a version every day”
Output from an escalation meeting
• Web App, JavaEE…• Up and Running
• Mobile App• Downloadable or in a Market
• Desktop App• Installers, Market, Auto-update• Installed on a system
Did you say “deliver” ?
Developers
More Releases =>
Project Managers
More Paperwork =>
Ops
More Changes =>
CONTINUOUS DELIVERY – THE CHALLENGE
Seamless Disruptive Changes
How to introducecontinuous delivery
seamlessly ?
“Let’s all commit to a continuous delivery
model …
… but without changing the way
we work”
CONTINUOUS DELIVERY – PRINCIPLES
Will try to make it not so boring
• Manual software building and deployment
• Deploying in production-like environment only after releasing
• Manual configuration of the environment
Delivery anti-patterns
A set of good practices to
simplify software delivery
AutomationResponsibilityPipeline
Automation
Bootstrap / Configuration
[Insert your own] Tests
Release, Deployment ProcessDatabase Evolution
Commit Stage
Acceptance Tests
UI Tests
Deployment Tests
Capacity Tests
Release
It’s not only source code…
Source
Data
Configuration
Environment
Build tools &
Build processes
Check-in everything
Source Code
Deployment Script
Data
Evolutions
Build ScriptsEnvironmentDescription
Configuration
Traceability
Unique Versioning
Human-readable
Introspectable
Tags
ReproducibleBuild
Notifications
Continuous Integration
Commit Often
Avoid branches
UnderstandableTest Suites
Use ‘branchby abstraction’
Fast feedbackComprehensive
Tests
Automate Tests
Unit Tests
Test Groups
DeploymentTests
IntegrationTests
SystemTests
UI Tests
Automate Deployment
Describe yourenvironment
Always deploy the same way
Manage configurations
AvoidDev vs. Prod
Did I tell you toTEST ?
Do itfrequently
Plan rollbacks
Implement a teststrategy
Promotion / Release<<Prod Ready>>
Capacity Tests
Deployment Tests
UI Tests
Acceptance Tests
Commit StageTest + Package V1 V2 V3
Artifact Repository
Source Repository
CommitStage
V3
AcceptanceTests
Prom. / Rel. Stage
V3
• As fast as possible• < 5 min is good• < 10 min is acceptable
mvn clean install
• Package, Changelog, Scripts…
The Commit Stage
Build only one package:Distribution
This package is reusedby all the test phases
Describe your environment
Reduce the distance betweenDev & Prod
Always deploy using the same way
BACK TO OUR PROJECT
Implementation Time
SCM => SVN, Git, Git-SVN
Build Tool => Maven
continuous-versioning-mp+
maven-release-plugin
CI => Jenkins
Artifact Repo => Nexus
Development
• Maven build• -SNAPSHOT
• Continuous Versioning
A1.0.0-SNAPSHOT
B1.0.0-SNAPSHOT
C1.0.0
• Provisioned using• Shell script• Puppet Manifests• Chef Recipes
=> Your deployment script
Virtual Environment
Commit Stage
Artifact Repository
Source Repository
mvn clean install
1.0.0-SNAPSHOT
Commit Stage
mvn clean install
1.0.0-SNAPSHOT
Fast-Release
1.0.0_42
Artifact Repository
Source Repository
tag
All other stages are using the _42 version
Testing Stages
IntegrationTests
DeploymentTests
UITests
Vagrant Box
Initialize a new VM +
Deployment
Testing Stages
DeploymentTests
UITests
Vagrant Box Staging System
DeploymentTests again
Deployment on a staging system
OtherTests
Releasing
Releasing Promoting
Take the current staged version (RC) => Declare it as G.A.
TOOLING
• Builds• Reproducible• Avoid system deps
• Make, Ant, Maven, Gradle, SBT
Build Tools
• Avoid ‘works on my machine’•Dev/ Test / Run on prod-like system
• Vagrant is awesome
Virtualization
• Customizable• Pipeline concepts
• Jenkins, Hudson, Team City, Bamboo• Travis
Continuous Integration
• Describe your environment• Treat your infra as code
• Shell Script, Puppet, Chef
CMS
• Specific CMS to deploy your application
• Go, Deploy-it, Puppet/Mcollective, JMX
Application Deployer
SOME FINAL WORDS
Responsibility
Following the rules
Trust is back
Seeing changes
Always being ready
Track & Visualize everything
Danke !