Post on 29-Nov-2014
description
Continuous, continuous, continuous.
A better way to delivery better code
Michele Orselli - @_orso_ Francesco Trucchia - @cphp
Francesco Trucchia Vice Presidente @ideato
@cphp
Michele Orselli CTO @ideato
@_orso_
Agenda1. Motivations
2. Bad smells
3. What is CD
4. Implementing CD
Delivering working software
matters to business people
1. Find the right target market
2. Testing the business model
3. Continuous improvement
4. Scaling fast
Find the right target market
Testing the business model
Continuous improvement
Scaling fast
Bad smells of software delivery
https://www.flickr.com/photos/gotosira/4699308007
1. Business knowledge is not shared
2. Long release time
3. No reality check
4. Long bugs backlog
5. Dev and ops silos
Business knowledge is not shared
Long release time
No reality check
Long bugs backlog
Dev and ops silos
How can you fix these problems?
Continuous Delivery to the rescue!
software is always in a deployable state
deployable software over adding new features
everyone can have feedback on a change
one click deploy
Why CD it’s useful?
value stream map
Requirements Development QA Release
where do we start?
when are we finished?
how do we proceed?
!
CD Maturity Model
framework to understand where we are
two dimensions: process vs app
!
Processoptimized
!
measured !
consistent !
repeatable !
non repeatable
Application
code | configuration | host | data | test
Thank you!
How to proceed?incremental approach
remember: everyone in the team is responsible for software delivery
!
Iterative Development
no big releases
prioritize by business value
deliver value on every iteration
short feedback cycle
small releases are easier to manage
!
but… I want all the features!
short feedback means
test your business early
short deploys
less bugs
Continuous Integration
changes are integrated early
reduced risks
early feedback
“if it hurts do it more frequently”
keep everything in version control
code, doc, data
you have tests for you app
unit
acceptance
capacity
but… tests are a waste of time!
what about testers?
automated tests mean
higher confidence on your software
short deploys
less bugs
CI aims to automate build process
checkout
compile
data integration
automatic tests
metrics collection
deploy
everyone commits every day
data as code
the DBA is part of the team
don’t checkin broken code
team gets visible feedback on builds
keep the build green
Wait… I have a big feature!
branching vs developing on trunk
latent code patterns eg. feature flags
test in a copy of the production env
no more “works on my machine”
today creating vm/containers is cheap!
vagrant, docker
Continuous Delivery
the last mile
Deployment Pipeline
core concept in CD
visualize the stages of the process
metaphor: assembly line
Commit StageAutomated
Acceptance Stage
UAT Manual Testing
Capacity Testing Stage
Production
if a step fails the pipeline stops
build binaries once
deploy in the same way in every env
smoke test deploy
deploy in a copy of production
compile
create binaries
unit tests
code analysis
prepares data for subsequent steps
Commit Stage
acceptance tests
slow but high confidence
run in parallel
whole team responsibility
high confidence our software works
Automated Acceptance
Stage
what we learned from CI
data as code
the DBA is part of the team
UAT Manual Testing
infrastructure as code
puppet, chef, ansible, docker
ops are part of the team
UAT Manual Testing
QA with testers
showcase
env should resemble production
UAT Manual Testing
You can measure:
Scalability
Throughput
Load
Capacity Testing Stage
deploy is already tested on UAT
blue/green deploy
canary release
Production
Create the Pipeline
incremental approach
walking skeleton
automate build
automate unit tests
automate acceptance test
automate release
So…automation can reduce waste
focus on value
incremental approach
cross functional teams
http://www.infoq.com/minibooks/continuous-delivery-overview
Questions?
https://joind.in/12250
Francesco Trucchia Vice Presidente @ideato
@cphp
Michele Orselli CTO @ideato
@_orso_