Article series: DevOps part 1 of 3

DevOps - collaboration, ownership and continuous improvement 

DevOps - the merging of Development and Operations is a popular topic right now but has been around as a concept for over 10 years. The agile manifesto came in 2001 and the term DevOps in 2009, so change takes time even if they are hyper-popular concepts. But what does DevOps mean? Below is a quote that is a pretty short and good description in words: 

"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users."-Donovan Brown, Microsoft 

Getting developers and operators to work together hasn't always been a given. For many years, it was the development team who celebrated on Friday afternoon that they had finished the release and wished the operations team good luck with the production release over the weekend! 

The essence of DevOps is that we need to collaborate more and even work in the same teams to deliver value to our customers (so-called cross-functional teams). These teams are often categorized as product teams where the team works on one or more features or products over time. This is in contrast to project teams which have a shorter life span and often hand over the output, finished or not, to a management organisation. Another difference is that product teams are responsible end-to-end, from gathering requirements and feedback from the customer to delivering value back to the customer. They are closest to the information and have the knowledge to make the right decisions.

"DevOps teams are responsible for designing, building, delivering and supporting the code they write."

"You build it, You run it" 

The concept of "You build it, You run it" originates from Amazon where product teams were given operational responsibility for their products. This led to better quality for customers and also more stable delivery of technology. "You build it, You run it" gives the team daily contact with the customer where the quick customer feedback increases quality. It also provides direct control over how the team's product performs in production.

According to DevOps, the team that knows its product best should also be responsible for the support of its product. Having teams take support responsibility for their product 24/7 will result in more stable and secure applications as everyone knows that the ones who "suffer" are the team themselves. Being on-call for their product should not be strange and the goal for the team should be that the on-call week should be a way to earn extra money as a reward for building a stable and secure product (as there will be no incidents at night 😊).

Inspiration from Lean and Continuous Delivery 

DevOps has taken much inspiration from Lean where flow, feedback, and continuous experimentation and learning and value streams are key principles. The book "The Phoenix Project" launches the three principles that underlie many of the behaviors that create well-functioning DevOps teams: 

The first principle - Flow; speeding up the flow from development through operations to the customer. To achieve this, the team is working to make work visible, reduce the size and shorten the intervals of work done, and increase the quality of what is delivered.  

The second principle - Feedback; create shorter feedback loops at all stages of the value stream. It is about detecting errors and shortcomings as early as possible and working on continuous improvement. 

The third principle - Continuous experimentation and learning; creating an environment where the team works with experiments and where learning from both successes and failures, is also an important element.  

The Continuous Delivery movement has also inspired DevOps with its "deployment pipeline" where code and infrastructure are always in a release-ready state. 

DevOps-inspired development lifecycle 

The DevOps loop is often used to describe the never-ending cycle from planning to production:

If you google "devops loop" most hits are a variant of the above image where "Release" comes before "Deploy" but this is not entirely accurate as Deploy may be done to a production environment but the new version is only available to the customer at a later date, "release on demand".

There is a blog post on the correct order of "Deploy" and "Release" and an introduction to the term "release on demand" which you can find here https://omegapoint.academy/amplitude/devops-loopen-och-release-on-demand. 

Optimize the workflow from planning to production 

The DevOps loop describes a perpetual cycle with eight sub-areas where the team continuously works to optimise its workflow. The effect is that they get around the loop in less and less time. Optimising the workflow does not mean that they skip important quality aspects such as stability and security, but that the team works to automate and streamline. In the beginning, it can take months to get from planning to production. Then, with continuous optimization, it can be reduced to a month, two weeks, a week, and finally maybe just a day. Then the team is so far along in their maturity journey that they are working with true Continuous Deployment. Every time they check in code, a new release is created in production. 

CI/CD - Continuous Integration/Continuous Delivery 

Although People and Process are just as important as Products, an automated CI/CD pipeline often gets a lot of focus when talking about DevOps. Probably because it is perceived as easier and more concrete to talk about what tools and technology we need to start using to become "DevOps". 

However, choosing a modern and well-functioning CI/CD environment is important to enable continuous delivery. But what is meant by CI/CD? 

Continuous Integration - all code written by a developer should be integrated with the code of the other team members as often as possible. In this context, "often" is every day or at least every other day. 

Continuous Delivery - the idea and approach that every build could be a potential release. 

Continuous Delivery vs Continuous Deployment 

The abbreviation CD in CI/CD could mean either Continuous Delivery or Continuous Deployment (where the most common is Continuous Delivery). The picture below is a way to explain the difference between Delivery and Deployment:  

Continuous Delivery - where the output of your pipeline is something that can be put into production if you decide to. The decision is made based on automated testing or manual testing but it is still a manual step to go to production.   

Continuous Deployment - where production deployment is automatic every time, based on the success of all previous tests in the pipeline, giving the confidence to go live without manual steps. 

Security as a natural part of DevOps 

Integrating DevOps with security related activities is sometimes called DevSecOps, but for us at Omegapoint, security is a natural part of DevOps.   

We believe that activities related to security should be as natural a part of the work as testing. To take full responsibility for one's product end-to-end includes testing, security, operations and 24/7 support for the product.    

This means that those who have traditionally been responsible for security are partly given new tasks. As the way of working changes, they will be responsible, among other things, for helping product teams to identify which activities contribute to sufficient security without slowing down.