Continous Delivery:
Reliable software development through automation
Jesse Szwedko
j.szwedko@modcloth.com
@jesse_szwedko
Location: University of Pittsburgh
Date: 4/4/2012
Audience: Those with no or little background in continuous delivery (version control, automated testing, continuous integration, etc).
This talk:
github.com/jszwedko/continuous-delivery-pitt-tasks
(slides are on gh-pages branch)
Presenter Notes
Agile
Continuous feedback
Presenter Notes
Waterfall is "similar" just with a longer timeline
Flikr deploys 10 times a day
Continuous Delivery
Continuous Delivery (CD) is a design practice used in software development to automate and improve the process of software delivery.
- Wikipedia
Presenter Notes
Anytime you are doing something manual, automate it
Rule of 3s
Presenter Notes
Presenter Notes
Outline
Process Evolution
Cowboy coding
Version control
Local development
Automated deploys
Automated testing
Continuous integration
Complete example
Presenter Notes
Tasks Application
Allow the user to create ToDos
Create
Read
Update
Delete
List
Presenter Notes
Simple CRUD application
Focus on process
Show running live
Presenter Notes
Focus is on process, not technology
Please ask any technology questions
Feature request: As a user, I should be able to add a description for each todo
Presenter Notes
Cowboy Coding
Presenter Notes
Presenter Notes
Do it live example
Presenter Notes
Add feature on remote box
Make syntax error
Revert to working version manually
Show broken site (motivate version control and developing locally)
Branch: initial-implementation
Disadvantages
Broken code is immediately visible to end user
Can not debug code (reveal application secrets)
End user sees a lot of volatility
Cannot easily undo changes
Presenter Notes
Outline
Process Evolution
Cowboy coding
Version control
Local development
Automated deploys
Automated testing
Continuous integration
Presenter Notes
Version control
Track changes to source code
Presenter Notes
Started with making copies of files
Unable to get back to stable state after changes
Presenter Notes
See source code at any point in time
Source code example (show commit, checkout of older version)
Image from http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-should-i-consider-or-not-consider-mercurial-or-git-or
Demonstrate commit and push to github
Version control example
Presenter Notes
Demonstrate commit, log, revert, checkout
Demonstrate needing to see current changes
Advantages
Can deploy code at any point in history (e.g. to rollback to stable version)
Can see why changes were performed
Allow for collaboration
Presenter Notes
Imagine collaborating on code
Still, we need to develop in a way where we can experiment
Presenter Notes
Outline
Process Evolution
Cowboy coding
Version control
Local development
Automated deploys
Automated testing
Continuous integration
Presenter Notes
Develop locally
Develop features, fix bugs, experiment locally
Push changes to server only after you are done
Consider using a virtual machine if your development enviroment is too different from the production environment
Presenter Notes
Use vagrant to spin up machine similar to "production" (especially when on Windows)
Will not quite be push button, but we will get there
Feature request: As a user, I should be able to add a description for each todo
Presenter Notes
Developing locally example
Presenter Notes
Develop adding of description text field
Push to github (show on Github)
git pull
on server
Broken because of data migration!
Are not updating JSON builders
Advantages
Can develop feature in increments, deploy when finished
Allows for debugging
Experimentation
Presenter Notes
Presenter Notes
Closer, but multi-step deployments introduce risk
Presenter Notes
Deployment tasks
Copy code
Migrate database
Restart web server
Presenter Notes
Outline
Process Evolution
Cowboy coding
Version control
Local development
Automated deploys
Automated testing
Continuous integration
Presenter Notes
Automated deployments
Specify each step of the deploy as code
Deterministic
Idempotent
Should be able to rollback
Presenter Notes
Rule of 3s
Presenter Notes
Automated deployment tool (primarily used for Ruby applications)
Other examples: ansible, chef, bash
Automated deployment example
Presenter Notes
Review capistrano configuration
Delete app/current
Deploy
Motivate need for tests
Advantages
Eliminate risk of multi-step deployments
Deploying to multiple servers
Automation as documentation
Presenter Notes
Presenter Notes
How do we make sure the application is stable before each deploy?
Presenter Notes
Poke the application manually (does not scale)
Stop regressions
Outline
Process Evolution
Cowboy coding
Version control
Local development
Automated deploys
Automated testing
Continuous integration
Presenter Notes
Automated Tests
Describe what the code
should
do
Catch regressions
Presenter Notes
MiniTest
Presenter Notes
Automated testing framework
Alternatives include RSpec, TestUnit
Feature request: As a user, I should be able to add a description for each todo
Presenter Notes
Automated testing example
Presenter Notes
Add description, but break title
Add view spec for show template to assert fields
Break test
Fix test
But what if we forget to run the tests?
Presenter Notes
Outline
Process Evolution
Cowboy coding
Version control
Local development
Automated deploys
Automated testing
Continuous integration
Presenter Notes
Presenter Notes
Continuous integration server
"Build" is triggered by commit or push to VCS
Run set-up tasks
Run tests
Build artifacts
Presenter Notes
git log w/ branches ("alternative timelines")
Github model uses pull requests
Branch
Add .travis.yml
Feature request: As a user, I should be able to add a description for each todo
Presenter Notes
CI Example (full example)
Presenter Notes
Create branch
Add description
Run tests
Push to github
Wait for Travis
Merge
Deploy
Advantages
Running tests happens automatically (you can trust other pull requests)
Running application under many different environments
Kick off longer test runs in the background
Presenter Notes
Conclusion
Presenter Notes
Presenter Notes
Mistakes we knew we were making
Skipped infrastructure configuration
You should try to avoid "building" on the server
E.g. we did asset compilation (translating of "higher" level languages to CSS and JS)
You should have a test stage target for deployment that is identical to production
Some issues are environment specific
Presenter Notes
Questions
Jesse Szwedko
j.szwedko@modcloth.com
@jesse_szwedko
This talk: github.com/jszwedko/continuous-delivery-pitt-tasks (slides are on gh-pages branch)
Further reading:
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Presenter Notes
Technologies
Used here:
Ruby
&
Ruby on Rails
Capistrano
MiniTest
TravisCI
Others:
Ansible
Vagrant
Chef
Puppet
Presenter Notes
Devops Days
Presenter Notes
Table of Contents
Table of Contents
Continous Delivery:
1
Agile
2
Continuous Delivery
3
-
4
-
5
Outline
6
Tasks Application
7
8
Feature request: As a user, I should be able to add a description for each todo
9
Cowboy Coding
10
-
11
Do it live example
12
Disadvantages
13
Outline
14
Version control
15
16
Version control example
17
Advantages
18
Still, we need to develop in a way where we can experiment
19
Outline
20
Develop locally
21
Feature request: As a user, I should be able to add a description for each todo
22
Developing locally example
23
Advantages
24
-
25
Closer, but multi-step deployments introduce risk
26
Deployment tasks
27
Outline
28
Automated deployments
29
30
Automated deployment example
31
Advantages
32
-
33
How do we make sure the application is stable before each deploy?
34
Outline
35
Automated Tests
36
MiniTest
37
Feature request: As a user, I should be able to add a description for each todo
38
Automated testing example
39
But what if we forget to run the tests?
40
Outline
41
-
42
Continuous integration server
43
Feature request: As a user, I should be able to add a description for each todo
44
CI Example (full example)
45
Advantages
46
Conclusion
47
-
48
Mistakes we knew we were making
49
Questions
50
Technologies
51
Devops Days
52
Help
Help
Table of Contents
t
Exposé
ESC
Full screen slides
e
Presenter View
p
Source Files
s
Slide Numbers
n
Toggle screen blanking
b
Show/hide slide context
c
Notes
2
Help
h