Death to manual deployments
42
Death to Manual Deployments! Implementing Reliably Consistent Deployments Across Environments
-
Upload
ibm-urbancode-products -
Category
Technology
-
view
1.209 -
download
1
description
Manual deployments are slow, error prone, and generally terrible. In this presentation we look at why they fail, the elements of an automated solution, and was to build on them.
Transcript of Death to manual deployments
Death to Manual Deployments!
Implementing Reliably Consistent Deployments Across Environments
IBM Rational ©2013
Eric MinickTechnical [email protected]
Background as a developer, tester and tools guy
Helping customers implement build & deploy for the past 9 years
IBM Rational ©2013
I hate manual deployments
They’re slow They aren’t consistent across environments You fail in production You don’t know who deployed what, where or when
IBM Rational ©2013
Why do people like manual deployments? I feel more in control from the command line
It’s how I’ve always done it
I know what I did and see the output of the commands I ran
When something goes wrong, I can be the hero and fix it
IBM Rational ©2013
What about scripts?
I don’t have a manual deployment: I have scripts! How many scripts? What order? Who has permissions to run them? Are they the same across environments? What else do you need to do?
Scripts are only part of a fully automated deployment.
IBM Rational ©2013
I love automated deployments
They’re NOT slow They ARE consistent across environments You DON’T fail in production You DO know who deployed what, where or when
IBM Rational ©2013
Automated deployments provide benefits Provide a platform you can build on
continuous deploys, smoke tests, other goodies
Empower people while increasing control stop waiting on other people stop being harassed by other people
Better, Faster, Cheaper (Pick any 3)
IBM Rational ©2013
The Program
Today’s Manual Deployments Elements of an Automated Solution Best Practices with Automated Deployments
IBM Rational ©2013
The Program
Today’s Manual Deployments Elements of an Automated Solution Best Practices with Automated Deployments
IBM Rational ©2013
… you might have a manual deployment Hand-offs are through email (or file shares) Developers, QA, and Ops deploy differently Tweaks communicated on an as-broken basis Deployments steps are a huge document The term “deployment weekend” is used Developers have production passwords
IBM Rational ©2013
Hand-offs are through email (or file shares) They’re slow They aren’t consistent across environments You fail in production You don’t know who deployed what, where or when
IBM Rational ©2013
Developers, QA, and Ops deploy differently They’re slow They aren’t consistent across environments You fail in production You don’t know who deployed what, where or when
IBM Rational ©2013
Tweaks communicated as-broken
They’re slow They aren’t consistent across environments You fail in production You don’t know who deployed what, where or when
Themainpagewon’tload?
Oh…Right,youneededtoaddanotherdata
source.
IBM Rational ©2013
Deployments steps are a huge document They’re slow They aren’t consistent across environments You fail in production You don’t know who deployed what, where or when
IBM Rational ©2013
The term “deployment weekend” is used They’re slow They aren’t consistent across environments You fail in production You don’t know who deployed what, where or when
That’sok,Idon’treallylikemykids
anyway
IBM Rational ©2013
Developers have production passwords They’re slow They aren’t consistent across environments You fail in production You don’t know who deployed what, where or when
IBM Rational ©2013
If only people were more disciplined…
Deployment docs could capture everything always be updated could be followed them, perfectly, every time.
Audit spreadsheets could capture everything could update them
Image from: http://www.ultimatebasictraining.com/blog/2010/02/what-area-drill-sergeants-like/
IBM Rational ©2013
People aren’t machines
People: good at using creative judgment
Machines: good at consistency
Automated deployments leverage the strengths of people and machines.
Alistar Cockburn, “Characterizing People as Non-Linear, First-Order Components in
Software Development”
IBM Rational ©2013
DevOps isn’t natural
Conway’s Law: organizations are constrained to produce solutions that copy the structure of their organization
IBM Rational ©2013
DevOps isn’t natural
Conway’s Law: organizations are constrained to produce solutions that copy the structure of their organization
Ops wants to maintain control doesn’t care about DEV, can’t keep up with the frequent
changes Development doesn’t want responsibility for
production deployments
QA lacks influence in DEV & PROD
IBM Rational ©2013
The Program
Today’s Manual Deployments Elements of an Automated Solution Best Practices with Automated Deployments
IBM Rational ©2013
Elements of an automated solution
Automated process Coordinating tiers Environment definitions Artifact repository Access control Audit trail
IBM Rational ©2013
Automated process
Status Quo Don’t exist Incomplete Multiple order-dependent
scripts Multiple versions per
environment (or machine) Uncontrolled
What we need Single script reused across
environments Controlled access to
deployment steps Auto record what happened
Fast, consistent and repeatable
IBM Rational ©2013
Coordinating Tiers / Components
Status Quo Based on oral history In a Release Manager’s
spreadsheet Total plan based on
documented changes for each release Redesign every time
What we need A model for whole systems Standard deployment based
on changes to all pieces and parts
Actual deployment runs the needed subset.
Move all tiers, services, config etc together
IBM Rational ©2013
Environment definitions
Status Quo Configured manually Details embedded in
binaries, scripts, property files, ini files
Environment information either uncontrolled or in source control
What we need Environments a first-level
entity Properties controlled at the
environment level Secure storage of sensitive
values (passwords)
Per-environment configuration and passwords
IBM Rational ©2013
Artifact repository
Status Quo Is email a repository File share on the network Source control for binary control Uncontrolled Crude control over what to keep
What we need Definitive Software Library Consistent set of artifacts across
environments Tamper-proof artifacts Automated retention policies
based on deployments
Know what you’re getting
IBM Rational ©2013
Access control
Status Quo Controlled by who can log
onto the machine Access tends to grow over
time in response to crisis Access control distributed
across machines
What we need Role-based access control Access control by
environment Single source of access
control LDAP / Active Directory
authentication (or authorization)
Who can deploy to which environment
IBM Rational ©2013
Audit trail
Status Quo What audit trail? I have the spreadsheet Our Change Management
System has what we think we did
Audit trail starts at PROD
What we need Win at Clue:
Who What Where When (better than Clue!)
Require no additional work End-to-end traceability
Know what happened
IBM Rational ©2013
Solution Benefits
We have confidence that our production deployments will succeed
QA can take new builds faster DEV deployments fast enough to keep up with our
rate of change We have an audit trail from day one We have separation of duties
IBM Rational ©2013
The Program
Today’s Manual Deployments Elements of an Automated Solution Best Practices with Automated Deployments
IBM Rational ©2013
Automated Deployments Best Practices Deferred deployments Self-service deployments Automatic deployment Automatic smoke-test Automated rollbacks Continuous production deployment
IBM Rational ©2013
Deferred deployments
Story: I want to do my deployment at 11 pm on Friday after my users are offline.
Solution: Schedule deployment for desired time, go home. Wait for notification of success or failure.
IBM Rational ©2013
Self-service deployments
Story: QA wants to be able to take a new build when they need one.
Solution: Use per-environment access control to allow the QA people to deploy on-demand, but only to the test environment.
IBM Rational ©2013
Automatic deployment
Story: Want to keep the development test server in sync with the latest changes in source control.
Solution: After building, automatically deploy to the development server.
IBM Rational ©2013
Automatic smoke-test
Story: I want to know if something breaks immediately.
Solution: After deploying, automatically trigger a suite of automated tests and report the results.
IBM Rational ©2013
Automated rollback
Story: If my deployment fails I want to restore the previous build.
Solution: When a deployment step fails, trigger the restoration of the last successfully deployed build.
IBM Rational ©2013
Continuous production deployments
Story: When a change is committed it should be deployed to production if it doesn’t break anything.
Solution: After deployment to test environment run automated test suites. If they all pass, trigger a deployment to production, then test that production deploy was successful. Rollback on failure.
IBM Rational ©2013
Summary
Manual deployments are slow and broken because they require people to act like machines
Computers make good machines
Automated deployments provide a solid foundation for further improvement
IBM Rational ©2013
References
http://urbancode.com/resources
Deployment Automation Basics Lean Build & Deployment Automation ITIL Release Management and Automation
Blogs.urbancode.com Twitter.com/UrbanCode
IBM Rational ©2013
Yes, we sell DevOps oriented products IBM UrbanCode Deploy
Application Release Automation
IBM UrbanCode Build Build automation on an enterprise scale
IBM UrbanCode Release Release management and release weekend execution
IBM Rational ©2013
Wait… Have we been here before?
Take action Send people to the
recording or the slides
Distribute the white paper
Start a conversation
Just start automating
Slideshare.net/Urbancode@EricMinick
Linked-in group, “Automating Deployment and Release”
