Who the fuck is DevOps?

When trying to gain more knowledge about microservices, it’s nearly impossible to get around all the aspects of DevOps. The improvement of the DevOps processes is one of the major advantages for following the microservices philosophy. To get a better understanding about what DevOps really means (and what not), I’d like to collect some information here.

First of all, Wikipedia defines DevOps as follows:

DevOps (a clipped compound of “software DEVelopment” and “information technology OPerationS“) is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.^[1][2] It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

So, the main target seams to be the same as the one I recognized for the microservices philosophy: Enabling the IT landscape to deploying applications and/or changes in them faster, making sure that new features can be brought to customer rapidly.

Some months/years ago, the term DevOps wasn’t that common, I’ve rather read about Continuous Delivery and Continuous Integration. Are those different topics or where is the difference here ?

Wikipedia shows the different aspects and their combination in a Venn diagram:

 

Continuous Integration

When talking about CI, the main aspect lies in the integration test. Other than writing code in isolation and process an integration test with the other components afterwards, the idea of Continuous Integration is to run automated integration tests much more often, so first the scope of the integration test becomes smaller and second, the time between creating new lines of code, bug detection and bug fixing gets much closer. It makes it just easier for the developer to remember the specific lines of code he needs to change because the time of creation is not that long ago.

A CI setup could for example (german link) look like this:

• developer check in their source code at least once a day
• after every check-in, the build process runs
• with every check-in, unit-tests are processed.
• build and test run fast, so developers can get feedback very quickly

On ThoughtWorks, Martin Fowler says:

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.”

Continuous Delivery

The term “CD” is occupied twice: by Continuous Delivery and Continuous Deployment.  They are both a following step to Continuous Integration.

The difference between those two terms comes in the testing: Continuous Integration is part of both of them, but Continuous Delivery stops the automation after the Build for a manual human acceptance test. Only after a manual approval, the deployment to production will happen automatically.

Continuous Deployment instead doesn’t contain a step of human testing in the process, after checking in the new source code changes, all following steps run automatically. That’s also the reason why Continous Deployment is described as the evolution after Continuous Delivery, but in my personal opinion, I think manual testing can be quite helpful in most of the cases. Anyhow, there might also be some high-sophisticated automated tests that can cover the test parts.

The interference of the different aspects / techniques is nicely visualized in the following picture:

 

And DevOps?

The article’s title is suggesting to bring more clarification about DevOps – now I wrote quite some words about Continuous Integration, Continuous Delivery and Continuous Deployment, but didn’t mention DevOps really a lot.

Well, DevOps offers a variety of definitions and interpretations, it’s not 100% clearly definable. Important to understand is that DevOps aims to establishing a culture in your software team. Some also call it “developer and operations collaboration” (theagiledamin.com).

A representative principle that gives a good idea about the approach is the “you build it, you run it”-paradigma which makes the developer the go-to-person for the software’s operation. It can mean that developers have to change their work life because – depending on the team’s organisation and the software piece they are responsible for – they have to be on-duty at weekends or at night. In most of the cases, that automatically increases the quality and stability of the solution because developers rather like not to be called with problems on their weekends 🙂 Stephen Orban from Amazon AWS-team wrote some interesting words about that.

Overall, DevOps changes the way an IT organisation is set up, roles of developers and operators/admins are newly defined. Most of the very successful tech-companies of our time, like Amazon, Netflix and Google are known for their intensive adaption of the DevOps principles and seem to be quite successful with them.

</article>

Some links I used for gathering information for this article:

• https://www.accenture.com/us-en/blogs/blogs-continuous-everything-devops
• https://aws.amazon.com/devops/what-is-devops/
• https://en.wikipedia.org/wiki/DevOps
• https://aws.amazon.com/devops/continuous-integration/
• https://en.wikipedia.org/wiki/Extreme_programming
• https://martinfowler.com/books/continuousDelivery.html
• https://www.thoughtworks.com/continuous-integration
• https://www.atlassian.com/agile/continuous-integration 
• (german): https://www.scrum.de/unterschiede-zwischen-continuous-integration-continuous-delivery-und-continuous-deployment/
• https://continuousdelivery.com/
• https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff
• https://theagileadmin.com/what-is-devops/
• https://medium.com/aws-enterprise-collection/part-3-in-the-enterprise-devops-series-why-you-should-run-what-you-build-c62f0990f4c3