DevOps Cycle Archives

Deploying in classical organizations has always been a pain. In the DevOps cycle, two roles, Dev and IT, with divergent objectives and interests battle to publish the application. These go in different work environments, such as development, integration, quality / test, pre-production, and production.

Automated deployment

As in any chain, it’s easy to break through the weakest link. And the more steps in the deployment processes, the more possibilities of human failure. Thus, DevOps promotes the automation of deployments through tools and scripts. With the goal of solving the entire process with an approval or activation of a feature.

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

The most critical in this phase is the arrival of the Cloud, with its Infrastructure capabilities as a code. This forces a change from a finite infrastructure management to a management based on permanent cost optimization.

Operations: Ensuring proper functioning

Only a minority of apps go into production without constant optimization, evolution, or support. Usually, all operations related to its operation must happen continuously throughout the life of the software. This way we have:

Resources adjusted according to demand or growth of the application
Dynamic change in the infrastructure due to security, performance, and availability
Process optimization to improve execution and exploitation.

During the operations phase, the Cloud concept applies like a ring to the finger. Be it public, private or hybrid, this platform offers opportunities of scalability, persistence, availability, transformation, resilience and security. Furthermore, we automate the optimization of operations scenarios to mitigate failures that happen because of human error.

Monitoring

This last phase of a DevOps process is a permanent phase and applies to the entire cycle. It’s where we monitor, analyze and measure all that displays the current status overview of the application and its infrastructure. Including all the dependencies.

And it has a reactive slope, where according to the results, we adjust the platform. Moreover, continuous learning allows us to anticipate needs and risks.

What is not defined can not be measured. What is not measured can not be improved. What is not improved, always degrades.

William Thomson

Now, the continuous feedback of all the areas of the DevOps cycle is consolidated and included in the next iteration. Either during the Planning phase, or immediately with specific corrections.

About the phases of the DevOps cycle

This was a generic, and perhaps idyllic, vision of a complete DevOps cycle. One following a logical structure, based on experience and literature. However, the reality is much more complex both in the implementation and in the execution.

But without a doubt, the biggest obstacle is communication between teams with different objectives and interests. Or maybe leaving your comfort zone to follow a trend. However, the benefits remain important in the field of productivity, Time to Market, or the flexibility of the business against customer demands.

One thing producing innovative movements in companies is DevOps. Let’s now clarify the phases of the iterative DevOps cycle: Planning, Development, Continuous integration, Deployment, Operation and Monitoring.

Phases in DevOps

It’s important to understand that it’s one of multiple representations, not the definitive canon, simplified into 6 main phases. However, it’s not a cascade cycle where the phases are separated by boundaries. Nor are initiated when the previous one has ended completely. Now, let’s look at each DevOps cycle phase in more detail.

Planning

Every project needs a vision that indicates the ultimate work goal to its participants. Defining a set of functionalities giving each iteration value, the criteria to be fulfilled and the end – for each project phase. A Living Product Stack which continuously supports a process of gardening – from a business point of view.

This feeds the different phases of development and operations. Also addressing changes and evolutions according to a continuous improvement process, based on continuous feedback. It’s also important that Business and Management get training on tools and metrics in order to have enough visibility of the project’s development.

Development – Building code

This phase is where the project gets built. Writing code, designing infrastructure, automating processes, defining tests or implementing security. It’s where, at present, you’ll find the most important effort in automating repetitive or complex actions.

However, the most important part of this phase is evidence. Either in a management application, operations with data or in the deployment of virtual infrastructure. Developers will store code in a code manager that allows historical viewing, branches, versioning, and more. But this isn’t enough, and each piece built must include its own automated tests.

Meaning, the mechanisms with which the system itself can ensure that what we have done is correct. That it doesn’t fail or negatively impact other parties, meets the acceptance criteria, and points out developmental errors.

Continuous integration – aka. peaceful sleep

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. The arrival of DevOps and the concepts of Infrastructure as a code, make IT also a full participant of this phase.

This is the unique functionality or feature, built in the development environment, together with the automatic tests that ensure it works well. Then published in a service that integrates it with the rest of the application.

Tests include ones for each functionality, integration tests of the whole application, functional tests, acceptance tests, quality analysis of the code, and regression tests. And if something fails, the early warning will pop up, indicating which piece/ line is breaking the system.

Ultimately, the closer you get to the moment of initiating the critical path of deployment, the quieter you get. Because more evidence is included in the work. Stay tuned for part 2 of the DevOps Cycle tomorrow, where we’ll discuss the final three phases: automated deployment, operations and monitoring.