The DevOps cycle, a guide to start in the phases that compose it

There are terms that are fashionable, have a lot of capacity for empowerment, and produce innovative movements in companies. Above all, those dedicated to businesses related to the digital economy. One of them is, together with micro services, Agile, or digital transformation, the term DevOps.

This is a concept, almost a philosophy, which in this article I will focus on the description of the phases of the iterative cycle that compose it; with the aim of clarifying basic concepts that I must have internalized before embarking on its adoption.

Phases in DevOps

Currently, DevOps can be defined as an infinity symbol or a circle that defines the different areas and phases that comprise it …

• Plan
• Development
• Continuous integration
• Deployment
• Operation
• Monitoring

It is important to understand that it is one of the multiple representations, not the definitive canon. Having fully valid simplifications in the form of four main phases, or detailed decomposition of each of them.

Another essential idea to internalize is that it is the definition of an iterative flow, so that different processes can be comprised in different phases in an organic and superimposed way, always adjusting to the fundamental concepts of value and continuous improvement.

I must avoid falling into the temptation of considering it as a cascade cycle, where the phases are rigidly delimited by a boundary that separates them, or that a phase can only be initiated when the previous one has ended completely.

Now, I will look in more detail at each phase, allowing me a very common license in the DevOps processes, which is to use the Scrum framework (and its archetypes) as a working methodology to make explanations easier.

Management and planning

Every project needs a vision that indicates to the participants -whether direct or indirect- the reason and ultimate goal of the work to be done; defining a minimum set of functionalities that allow providing value in each iteration, the acceptance criteria to be fulfilled and the definition of finishing; for each of the phases and in the whole project.

This is constituted as a Living Product Stack, which is continuously supporting a process of “gardening”, from a business point of view, which feeds the different phases of development and operations; and that addresses changes and evolutions according to a continuous improvement process based on early and continuous feedback.

For this I will use the “liturgies” of Scrum, such as the iteration planning meetings and the iteration review; but without, therefore, stop having a communication and constant involvement between business and the technical team. It is essential that Business and Management are trained in the tools and metrics designed so that they have a true and sufficient visibility of the development of the project.

Development, building code

This phase is where it is built. Be itching code, designing infrastructure, automating processes, defining tests or implementing security.

It is where, at present, the most important effort is being made in the automation of repetitive or complex actions; and that it should be one of the first steps to scale to implement DevOps in an organization.

If I had to summarize in a single word the most important concept of this phase, this would be “evidence”.

Either in a management application, operations with data or the deployment of virtual infrastructure; I will always work in code – either with a programming or scripting language; which must be stored in a code manager that allows basic operations such as historical, branches, versioning, etc.

But this is not enough and each piece built must include (obligatorily) its own automated tests. That is, the mechanisms with which the system itself can ensure that what we have done is correct, does not fail, does not fail other parties, meets the acceptance criteria, and early points out the errors that arise in any development. .

In fact, this is an imperative way to adopt Devops, from its most incipient stages.

First I store the code / script in a manager in order to have versioning and rollback; then start to include the automated tests, which will produce a profound transformation in the coding techniques (decoupling, segregation, modularization, etc); finally, we arrive at the orientation of what was built towards the following phases, including the transformation of the work flow itself.

Continuous integration, or how to sleep peacefully

Although in this phase and the previous one most of the authors focus on a development point of view, the arrival of DevOps and the concepts of Infrastructure as a code, make IT also a full participant of this phase.

The continuous integration is to automate the mechanism of review, validation, testing and alerts of the value built in the iterations, from a global point of view.

That is, my unique functionality or feature, which I have built in my development environment, together with the automatic tests that ensure its proper functioning, are published in a service that integrates it with the rest of the application.

So, by launching all the tests included in each functionality, plus the integration tests of the whole application, plus the functional tests, plus the acceptance tests, plus the quality analysis of the code, plus the regression tests, I can be sure of that my application is still working correctly.

And if something fails, the early warning will jump, indicating in which piece and in which line it is breaking my system.

So, the closer I get to the moment of initiating the critical path of deployment, the quieter I will be because more evidence includes my work.

Automated deployment

Deploying, in classical organizations, has always been a pain. Two roles (Dev and IT) with divergent objectives and interests are in a battle of isolation and mutual suspicion to publish the application in different work environments: development, integration, quality / test, preproduction, production, etc.

As in any chain, it is easy to break through the weakest link, and the more steps there are in the deployment processes, the more possibilities of human failure are added.

Thus, DevOps promotes the automation of deployments through tools and scripts, with the ultimate goal that the entire process be resolved with an approval button or, ideally, the activation of a feature.

Between each deployment environment, we must take into account the context management (create, configure and destroy environments); perform and pass the specific tests of each one (such as performance, resilience, functional, safety or UX tests); and managing configuration management (CMDB) according to the complex needs of different deployment contexts.

The most critical and difficult in this phase, more than known and adopted in the IT environment, is the arrival of the Cloud concept with its Infrastructure capabilities as a code, which forces a change in the paradigm of infrastructure management. What happens from a finite resource management to a management based on permanent cost optimization?

Operations, ensuring the proper functioning

It is a minority the applications that are put into production and do not require constant work in its optimization, evolution, or support. But, in addition, I must take into account all operations related to its operation that must be carried out continuously throughout the life of the software.

This way I will have, the adjustment of the resources in agreement with the demand or the characteristics of growth of the applications ; the dynamic modification of the infrastructure due to security, performance, availability, etc. .; or the optimization of processes and procedures that require changes in the context of execution and exploitation.

In this phase, it will apply as a ring to the finger the adoption of the concept of Cloud – be it public, private or hybrid – where operations can exploit the capabilities of scalability, persistence, availability, transformation, resilience and security offered by this type of platform.

Having to work in the automation of the optimization of the operations scenarios, so that I return to mitigate the failures due to human error.

Monitoring, or the art of measuring

This last phase of a DevOps process is a permanent phase and applies to the entire cycle.

It is where I will define the measures that I will be monitoring to control the health status of the applications and their infrastructure, this being the history of the measurements over a period of time, which show me the evolution of the system.

It has a reactive slope, where according to the results I will adjust or modify the platform; and another proactive in which a process of continuous learning will allow me to anticipate the needs and risks.

What is not defined cannot be measured. What is not measured cannot be improved. What is not improved, always degrades. William Thomson.

But not everything is technology, and in this phase the continuous feedback of all the areas and levels of the Devops cycle will be consolidated to be included in the next iteration during the Plan phase, or immediately with specific corrections.

I will monitor, analyze and measure everything that can give me an overview of the current status of the project (in its broadest definition), including all the dependencies that I had; but with capacities to go down to the singularity to observe carefully the operation of a particular piece.

And through the performance of retrospectives, I will complete the Kaizen process (continuous improvement) of the project, including all the origins related to the positive development of the works.

About the phases of the DevOps cycle

I have shown a generalized and idyllic vision of a complete DevOps cycle, following a logical structure based on experience and the profuse literature that has been published.

The reality is much more complex both in the implementation and in the execution; but without doubt the biggest obstacle is the communication problems between teams with different objectives and interests, and the distrust of leaving my comfort zone following a “fashion”.

However, the benefits are very important. And not only in the field of productivity, Time to Market, or the flexibility of the company against the demands of business and customers; if not also in the human factors, of improvement of the quality of life, that we must value in its fair and positive measure.

About Post Author

Alyssa Brown

Alyssa@cyonwo.com