DevOps is an increasingly useful tool for achieving business objectives, enabling your teams to work together to improve the efficiency and quality of software delivery. However, despite its growing popularity, there is still a lack of clarity over what DevOps actually means, how organizations should do it and what's the best way to get started.
DevOps 101 takes a brief look at the history of DevOps, why it started, what problems it is intended to solve and how you can start implementing it.
The slides were delivered by James Betteley, Head of Education at the DevOpsGuys in a one-hour webinar. The full recording is available here - https://youtu.be/4gC3WpbetKs?t=2s
James has spent the last few years neck-deep in the world of DevOps transformation, helping a wide range of organizations optimize the way they collaborate to deliver better software, faster. James was joined by Elizabeth Ayer, Portfolio Manager, from Redgate Software. Elizabeth looks after a range of Redgate products that help teams extend their DevOps practices to SQL Server databases.
For more information visit www.devopsguys.com and www.red-gate.com
4. 5
DevOps History Lesson
• 2008 Patrick Dubois is a consultant working on a DC migration project for
the Belgian government
• 2008 Agile Systems Administration group formed by Dubois and Andrew
Shafer
• 2009 Velocity ‘09 – John Allspaw & Paul Hammond give talk on 10+
Deploys a day at Flickr
• 2009 First DevOpsDays conference
• 2010 First DevOpsDays US
• 2013 DevOps defined (sort of) as “an intimate understanding between the
development and operations teams”
10. 11
why did DevOps happen?
“How do we keep up with the demand
for new features and new technologies
while maintaining stability and high
performance?”
We tried to answer this question:
11. 12
Why did DevOps happen?
“How do we deliver maximum value to
our customers and shareholders?”
It was the wrong question
25. 26
Configuration as Code
package "apache2" do
case node[:platform]
when "centos","redhat","fedora","suse"
package_name "httpd"
when "debian","ubuntu"
package_name "apache2"
when "arch"
package_name "apache"
end
action :install
end
27. 28
Test-driven
• As a lazy ops guy I want an Ansible role that will install Apache on an
Ubuntu Server So that I can host the best website ever
• Additional notes:
• Install whatever the latest version of Apache is, we're a bleeding edge company
• Must work on Ubuntu 14.04 (current) and 15.04 (future rollout)
• The external load balancer will route incoming http requests to port 55555 on all
machines
• The NSA wants their own root account on all our environments
• Please remove telnet for maximum security
28. 29
Test-driven
require 'spec_helper'
describe package('apache2') do
it { should be_installed }
end
describe service('apache2') do
it { should be_running }
end
describe port(55555) do
it { should be_listening }
end
describe user('NSA') do
it { should exist }
it { should belong_to_group('root') }
end
29. 30
Continuous Delivery
• “Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software”
32. 33
Continuous Delivery – 8 principles
1. The process for releasing/deploying software MUST be repeatable
and reliable
2. Automate everything!
3. If somethings difficult or painful, do it more often
4. Keep everything in source control
5. Done means “released”
6. Build quality in!
7. Everybody has responsibility for the release process
8. Improve continuously
33. 34
Continuous Delivery – 4 practices
1. Build binaries only once
2. Use precisely the same mechanism to deploy to every environment
3. Smoke test your deployment
4. If anything fails, stop the line!
37. 38
5 Steps to Doing DevOps
1. Establish your goals
1. What does DevOps mean to the team?
2. Build the platform
1. Environments
2. Continuous Delivery
3. Test Automation
3. Assemble the team
4. Be agile, not waterfall
5. Work together to achieve great things
1. Autonomy, mastery & purpose
Why do I do what I do?
Learning objectives: What are you hoping to learn from this session?
On the Dev side of the business: Development, Sales, Marketing, Business Analysis, Product Management
On the Ops side we have: DBAs, Inf, Networks, support.
Amazon:
DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity:
Just use this slide to underline the fact that Automation is only 1 component part of DevOps
In terms of practical application…
We wanted a high rate of change, and high stability.
We probably didn’t explicitly give these objectives to different departments, but we didn’t do enough from stopping those silo’s being built.
We ended up with Dev = change and Ops = stability
We had 2 competing goals
Gene Kim calls this “system’s thinking” in his “3 ways of devops” but we’ve been using shared goals for ages.
Flow game!!!! Paper planes.
Feedback loops game
Piss easy to provision, configure and scale
Here’s a little serverspec script to test our configuration!
Separate your services
Decoupled components
They all do DevOps differently
Agree what your goals are, what problems you’re trying to solve, and what DevOps means to you (is it just automation or is it a mindset?). You all need to be on the same page before you start, otherwise you’ll misunderstand each other, and without knowing your goals, you won’t know why you’re doing what you’re doing.
Build the platform. DevOps relies heavily on fast feedback loops, so you need to enable them before you go any further. This means putting in place the foundations of a highly automated Continuous Delivery platform – from requirements management though to branching strategy, CI, test automation and environment automation. Don’t try to create an enterprise-scale solution, just start small and do what you need to do to support 1 team, or this thing will never get off the ground. You’ll probably need to pull together a bunch of DevOps engineers to set this platform up – this is often how “DevOps teams” come about, but try to remember that this team should be a transitional phase, or at least vastly scaled down later on.
Assemble the team. We’re talking about a cross-functional delivery team here. This team will include all the skills to design, build, test, deliver and support the product, so we’re looking at a Product Owner, Business Analyst, Developers, Testers, and Infrastructure Engineers among others (it largely depends on your product – it may need to be extended to include UX designers, Security and so on).
Be agile, not waterfall. Waterfall’s just not going to work here I’m afraid. We’re going to need a framework that supports much faster feedback and encourages far greater collaboration at all times. So with that in mind, adopt a suitable agile framework like scrum or Kanban, but tailor it appropriately so that the “Ops” perspective isn’t left out. For example – your “definition of done” should stretch to include operability features. “Done” can no longer simply mean “passed UAT”, it now needs to mean “Deployable, monitorable and working in Pre-Live” at the very minimum. Another example: Your product backlog doesn’t just contain product functionality, it needs to include operability features too, such as scalability, maintainability, monitoring and alerting.
Work together to achieve great things. Let the delivery team form a strong identity, and empower them to take full ownership of the product. The team needs autonomy, mastery and purpose to fully unlock its potential.
No such thing as a single organisational culture
An organisation’s culture is a blend of several subcultures
See Netflix and Facebook as examples of cross functional product delivery teams
Amazon are like this too – you build it, you run it.
Spotify – Squads are cross-functional delivery teams, basically