Technology is the enabler of innovation, rather than the driver of innovation. You must have an innovative business idea to leverage technology.
In 2009, John Allspaw described an innovative approach to managing development and operations that enabled Flickr to complete over ten deploys per day, when many companies were completing fewer than one deploy every six months. This was a key moment in the growth of DevOps.
DevOps is the practice of development and operation engineers working together during the entire development lifecycle, following Lean and Agile principles that allow them to deliver software in a rapid and continuous manner.
DevOps is not it is not just Dev and Ops working together. It is a cultural change and a different way to work. DevOps has three dimensions: culture, methods, and tools. Of these, culture is the most important.
The essential characteristics of DevOps include cultural change, automated pipelines, infrastructure as code, immutable infrastructure, cloud native application design, the ecosystem of containers, and how to deploy with immutable infrastructure.
DevOps started in 2007 when Patrick Debois and Andrew Clay Shafer began to gather like-minded people together at conferences to talk about common experiences.
In 2009, Allspaw delivered his now famous “10+ Deploys Per Day – Dev and Ops Cooperation at Flickr” presentation and the idea gained ground. Also in 2009, Patrick Debois started a conference called DevOpsDays that helped spread the DevOps message.
Books such as Continuous Delivery in 2011, The Phoenix Project in 2015, and The DevOps Handbook in 2016, helped practitioners understand how DevOps worked.
The major influential people of the early DevOps movement: Patrick Debois, Andrew Clay Shafer, John Allspaw, Jez Humble, Gene Kim, John Willis, Bridget Kromhout, and Nicole Forsgren, went out and made a difference, showing the results that could be achieved with DevOps.
The message spread from practitioner to practitioner until they began to realise what was possible with DevOps and that it was a better way to work.
Social coding is coding as a community and public repositories and pair programming result in higher code quality.
Working in small batches reduces waste and means quickly delivering something useful to the customer.
Minimum viable product is as much about delivery as it is about building what the customer really desires.
Test driven development is writing the test for the code you wish you had, then writing the code to make the test pass. It allows you to develop faster and with more confidence.
Behaviour driven development focuses on the behaviour of the system from the outside in. It looks at the system as a consumer of it.
Behaviour driven development improves communication by using an approachable syntax that developers and stakeholders can understand.
Microservices are built around business capabilities and are independently deployable by fully automated deployment machinery.
Cloud native architecture enables independently deployable microservices that take advantage of horizontal scaling and result in more resilient services.
Failure is inevitable, so we design for failure rather than trying to avoid failure.
It is important to embrace failure and quickly recover when failures happen.
Taylorism was designed for factory work and software development is bespoke, that is, more like craftwork, and that working in silos leads to mistakes and bottlenecks.
Team ownership and stable teams make software development more like product development rather than project management.
Developers want innovation, while Operations want stability.
Required DevOps behaviours include shared ownership, collaboration, embracing change, and data-driven responses.
Infrastructure as Code is describing infrastructure in a textual executable format.
Ephemeral infrastructure can be used and then discarded because servers are built on demand, via automation, using Infrastructure as Code techniques.
Continuous Integration is building, testing, and integrating every developer change into the master branch after tests have passed.
The benefits of Continuous Integration include faster reaction time, moving faster, and reducing the risk in integrating code.
Continuous Delivery ensures that code can be rapidly and safely deployed to production by delivering every change to a production-like environment.
The five principles of Continuous Delivery have to do with quality, working in small batches, automation, continuous improvement, and shared responsibility.
Organizations need to have small, dedicated, cross-functional, self-organizing teams to successfully implement DevOps.
Conway’s Law implies that a company’s design results are a direct reflection of the company’s communication structure.
Instead of the traditional structure organized around technology, successful DevOps teams should be organized around business domains. Each team should have its own mission that aligns with a business domain.
DevOps is a mindset that the whole organization adopts.
DevOps solves problems caused by siloed teams.
DevOps is the practice of development and operations engineers working together during the entire software lifecycle, following lean and Agile principles that allow them to deliver high-quality results.
Actions without consequences can lead to apathy.
Allowing teams to feel the effect of their actions fosters empathy, resulting in higher-quality work.
The organisational objective of DevOps is to attain a shared mindset and empower everyone to deliver customer value.
Measure and reward what you want to improve.
People seek information on what is rewarded and then seek to do that.
Measuring social metrics leads to improved teamwork and measuring DevOps metrics allows you to see the progression toward your goals.
If you want people to be social, then measure them being social.
DevOps changes the objective of problem resolution from failure prevention to failure recovery.
Vanity metrics may be appealing at first but offer limited actionable insights.
Actionable metrics provide meaningful ways to measure your processes and take action toward goals.
DevOps actionable metrics include mean lead time, release frequency, change failure rate, and mean time to recovery.
You can rate statements developed by Dr. Nicole Forsgren to measure your team’s culture, including statements about information, failures, collaboration, and new ideas.
Mean lead time is the measure of how long it takes for an idea to get to production.
Change failure rate is the rate of failure from pushing new releases out.
Mean time to recovery is how long it takes to recover from a failure.
Failures are learning opportunities that should not be punished.
Dr. Nicole Forsgren developed cultural statements for measuring team culture.