View
1
Download
0
Category
Preview:
Citation preview
CONTINUOUS DELIVERY: A JOURNEY NOT A DESTINATIONAkshay Karle & Badrinath Janakiraman @snap_ci | https://snap-ci.com
1
2
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
http://martinfowler.com/delivery.html
3
…high-performing organizations are still deploying
code 30 times more frequently, with 50 percent
fewer failures than their lower-performing
counterparts.
https://puppetlabs.com/sites/default/files/2014-state-of-devops-report.pdf
4
5
frequent, reliable releases of high quality
valuable software
6
SNAP, BACK IN 2012…
Built on 9 components (microservices, anyone?)
A message-queue for fast background job processing
Chef-server for infrastructure provisioning
Relational & NoSQL databases
Extensive Nagios monitoring
Completely automated infrastructure creation
Build and deployment pipelines for each component
So clearly - we had it nailed. Right?7
8
CONSEQUENCES
Likelihood of build setup passing 50%
Likelihood of changes actually triggering a build 50%
Likelihood that someone knew why 0%
Likelihood of 4 SSH sessions firing up debug 100%
Likelihood that the infrastructure was busted 50%
Frequency of production upgrades Twice a month
Consequence of upgrades Site unavailable!
Feedback to users about what was going on Minimal9
10
frequent, reliablereleases of high quality
valuable software
11
Our journey so far..
Queues per build
Messages lost, redelivery problems
Single, centralized queue
No need to manage queues
Delayed::Job
one Nagios to rule them all
too many components
too many metrics and alerts
ignored alerts when things actually did go wrong
separated application monitoring
basic server monitoring
aggregated logs
we don’t need to manage anything
Serverbecame cognizant of what state would go into chef
reliable and faster chef runs
nothing to manage
user build specific configuration data
dependency on the chef server for deployments
had to manage the server
Solo
Single mutable environments
Too many components
READONLY MODE Long running deployments
Loosing build requests
Loosing customers
Fewer components
Blue-green deployments
BLUE-GREEN DEPLOYMENTS IN SNAP
17
VZHOSTBuild Server
web server
VZHOSTBuild Server
web server
L B DATABASE
COUPLED MODULES TO MONOLITH TO REAL MODULES
Highly coupled initial state
Collapsed moving parts to a monolith
Deploying frequently highlights rates of change
This was used to make new modules
Much more decoupled state today
18
SO, WHAT’S THE CURRENT STATE?
Build setups almost always pass…
…but if there are failures, the team gets alerted
Deployments happen every other day
New releases happen once every 2~3 weeks
Near zero downtime
19
20
OUR CURRENT WORKING STYLE
Appropriate sequencing of stories
Using feature toggles
Structured evolution of data and app
Identical environments as trip-wires
21
SEQUENCING OF STORIES
22
short (idealized) cycle time, more technical risk
time
time
longer (idealized) cycle time, less technical risk
FEATURE TOGGLES
Hide unfinished UI elements
Control backend behaviour
Test with feature toggles
Avoid multi-component feature toggles
23
FRONTEND
24
<% if feature_enabled?(:parallel_stage) %> <!-- show new html --><% else %> <!-- show old html --><% end %>
edit.html.erb
BACKEND
25
if feature_enabled?(:parallel_stage) # new logicelse # old logicend
babysitter.rb
TESTING WITH FEATURE TOGGLES
26
describe "multiple jobs" do describe "feature enabled" do before(:each) do with_feature_enabled(:parallel_stage) end it 'should not show the job tabs when there is only one job' do end end describe "feature disabled" do before(:each) do with_feature_enabled(:parallel_stage) end it 'should not show the job tabs but should show the logs' do end endend
stage_run_spec.rb
MIGRATION OF DATA
Consider existing schema as well as data
Incremental changes
Rollbacks
Zero downtime releases
27
INTRODUCE JOBS
28
jobs
id
POPULATE ALL EXISTING STAGES
29
stages
id
started_at
completed_at
result
…
jobs
id
stage_id
…
COPY ATTRIBUTES TO JOB
30
stages
…
started_at
completed_at
result
…
jobs
…
started_at
completed_at
result
…
SWITCH THE APPLICATION TO START USING THE JOB MODEL
31
# After switchclass Stage def result results = jobs.collect { |job| job.result } return :failed if results.any?(:failed) :passed endend
# Before switchclass Stage attr_reader :resultend
# in transitionclass Stage def result if feature_enabled?(:parallel_stage) results = jobs.collect { |job| job.result } return :failed if results.any?(:failed) :passed else result end endend
REMOVE UNUSED ATTRIBUTES
32
stages
id
started_at
completed_at
result
…
jobs
…
started_at
completed_at
result
…
IDENTICAL ENVIRONMENTS/AUTOMATION
33
staging
buildn+1
upgradesmoketests�
ver. n
To production
34
buildn+1
upgradesmoketests�
ver. n+1
To production
staging
35
buildn+1
upgradesmoketests�
ver. n+1 staging
To production
36
�
ver. n+1 staging
buildn+1
upgradesmoketests
buildn+2
upgradesmoketests� To production
37
�
ver. n+2 staging
buildn+1
upgradesmoketests
buildn+2
upgradesmoketests� To production
38
�
ver. n+2 staging
buildn+1
upgradesmoketests
buildn+2
upgradesmoketests� To production
SUMMARY
Start with getting working software into hands of users
Layer on qualities of reliability, automation, frequent releases etc
Kick the can down the road
Don’t be afraid of “re-design”/”re-work”
Let CD guide your architecture and design - not the other way around
39
Akshay Karle, @akshay_karle
THANK YOU
Badrinath Janakiraman, @badrij
@snap_ci | https://snap-ci.com
Recommended