DevOps, the magic word. If you search it on the Internet, there are lots of definitions around it. Don’t get the first one you find, rather I recommend you to read at least a few of them to avoid getting a biased idea. If you ask me for a definition, I’d say: DevOps it’s the result of involving people, processes and technology in order to deliver changes automatically, efficiently, safely and predictively with higher frequency and stability. It sounds like a silver bullet, like the holy grail that will keep us away from the pain. As you may already know, that’s not true, but it helps.
Created in 2008 by Patrick Debois and Andrew Shafer, this term began to be commonly used by the industry in 2009, thanks to John Allspaw and Paul Hammond’s O’Reilly Velocity Conference speech titled 10+ Deploy Per Day: Dev and Ops Cooperation at Flickr. In their speech, they showed the significant separation between the developers and the operators and how this big pitfall between them (in addition to the missing budget) generated tons of technical debt.
Associated to the definitions you may find, there is an image that you will see. An image very similar to this one hereunder:
This image represents the DevOps lifecycle. In fact, the key of DevOps it’s not its lifecycle itself. This lifecycle already existed some years ago before DevOps appearance, even the monitoring stage. The essential point of DevOps is how short it can be and the low number of times (or 0 times, depending on the DevOps maturity adoption) you are forced to release in a “special” way, following a different flow.
How to adhere to DevOps?
In my experience, I’ve seen lots of departments and enterprises adopt DevOps in different ways. A well-known asset in this adoption is the usage of automation. However, the ones who started by defining the tools and the technology were who failed the most. Why? Because DevOps it’s not only about tools and technology, DevOps is a change in three ordered layers:
- People
- Processes
- Technology
A DevOps adoption should always follow this order. First, define the culture, an aligned objective with all the stakeholders, what every stakeholder wants the enterprise to become, what’s everyone’s vision of a DevOps company, even establish the stakeholder roles to be involved in it.
With all these thoughts and the shared vision defined by these stakeholders, it’s easier to set the adequate organization and processes to go to DevOps. The introduction of Agile methodologies is quite common in this step. To have self-sufficient agile teams with all the existing roles among their members will break any silo and provide the speed and stability required in DevOps.
Finally, this organization and process shaping will define the compatible subset of tools and technology to be elected. Even more, these workflows, processes, and organizations created in the previous steps will create the criteria for the tool election.
This is the process, never technology first. First people, secondly process and organization, and third technology and tools. Context should be understood before starting to implement something. Meet stakeholders, understand the path the company has followed and the reasons for past decisions to create an adequate DevOps environment.