DEVOPS, CI, AND CD, WHAT ARE WE TALKING ABOUT?

“Continuous Integration” (CI), “Continuous Deployment” (CD), and “Devops” are so many terms that we hear very frequently when we talk about Web applications and digital transformation.

Yet, they still need to be better understood in their implementation.

What is it about? To ensure the release of new application features at a much more regular and rapid pace.

Traditionally, a standard deployment rate on a classic application is one to two major releases per year.

For each major version, we bring together a set of new features, which gives a delay of 6 to 12 months between two new features.

In the meantime, we fix bugs and release minor versions. It’s long, especially in the age of the internet.

The objective is to ensure the consistency of developments, consolidate tests, secure production, and limit customer migrations, but this penalizes delays.

This delay is explained by the fact that it is a sequential process involving different teams and that at each stage, it is necessary to synchronize the actors, make requests, and plan them, all these generating delays.

Continuous deployment takes the opposite view and helps to accelerate this pace by:

• dividing the versions into a more significant number of smaller deliveries that are less complex to test,
• automating as much as possible the stages of testing and going into production of a new version to reduce cycles,
• allowing a very regular deployment of new products.

WHAT IS AT STAKE?

Traditional applications were essentially back-office applications that customers and partners did not access or indirectly.

Web applications, on the contrary, are front-end with customers or partners.

The objective is for the user’s navigation to be intuitive and the transactions simple and fluid.

We talk about optimizing the user journey, “UX” (user interface), and providing the “best experience.

” It’s an actual race against the competition to make the most efficient applications to use and improve the “time to market.”

Under these conditions, we understand that waiting six months to release a modification is impossible.

This is where DevOps comes into its own and brings superior responsiveness (we’ll talk about agility).

We will deliver in production quickly; over time, the developments will be carried out and tested to benefit customers as quickly as possible.

In the context of digitization of the economy and trade, it is indeed an issue of business competitiveness that we are talking about.

Added to this are web technologies’ specific constraints, which evolve very quickly: designs expire in 2 or 3 years; technology is replaced in 4 years.

Everything contributes to accelerating the pace of renewal and evolution of web applications.

HOW TO GET THERE?

Now that we are convinced of the need to step up the pace, how do we go about it? What should we implement?

DEVOPS

The principle of the DevOps method is to bring the development teams (Dev) closer to the infrastructure and production teams (Ops) by integrating the entire chain from the design of the project.

The design of the software architecture and the developments, the tests, such as infrastructure constraints and production methods.

We thus aim with DevOps to reduce inconsistencies and load breaks between developers and infrastructure teams.

LES “TWO PIZZAS TEAM”

The term “two pizzas team” has a gimmicky side to it, but we must retain the idea of ​​entrusting a small team (2 US-size pizzas = a dozen) with a coherent set of functions within a limited perimeter.

The team is small enough to drive itself; they know their functional area inside out and are responsible for everything from design to testing to production.

Beyond its caricatural side, because not everything is manageable in a “two pizza team.

” it is clear that this is very much in line with the idea of ​​DevOps, namely grouping responsibilities and reducing the wasted time between two teams.”

THE PRODUCTION CHAIN

The diagram below illustrates the steps for deploying a new feature in a traditional diagram; each is handled by a separate team that needs to be requested and planned.

This sequence takes time with each transition.

CONTINUOUS INTEGRATION

Continuous integration covers the first half of the chain. It aims to organize better and automate development operations and their transitions; it involves:

• A software version configuration server (SCM) will allow developers to work on their workstations while centralizing the modifications made as they occur and thus managing all the developments.
• As soon as the new code is deemed ready, it is “pushed” to the integration server. The most widespread SCM tools are currently Git (and Github) and Subversion (SVM), ideally in a collaborative mode.
• An integration server (CI) comes to retrieve the code and will carry out a series of tests and, if the result is green, integrates it into a new branch of the code which will be pushed both to the SCM server and the recipe. The flagship tools here are Jenkins, CircleCI, CodeShip, or TravisCI.
• Thus, developers can concentrate on their design/development actions. They have a server to manage their sources while working in a decentralized way, and as soon as a batch of code is ready, it is processed by the CI server without the need for planning and reducing manual tasks to a minimum.

CONTINUOUS DEPLOYMENT

The continuous deployment follows it consists of the infrastructure team scripting and automating the deployment steps in production so that a version delivered by the CI server can be deployed in production without delay. This goes through:

• An infrastructure configuration server on which the server configuration models (production and acceptance) will be stored, so any newly provisioned server is indeed according to the current model.
• The tools used are Chef, Puppet, SaltStalk, and Ansible.
• Maximum automation of acceptance tests via a tool like Selenium allows you to record and run complete test scenarios.
• A deployment server will orchestrate the deployment operations on the recipe server, trigger the tests, then launch the switch to production if the latter is positive.
• Among the orchestration tools frequently used for web applications, we can mention Capistrano.
• Of course, only some things will be 100% automated, and it is a good idea to keep manual validations, but the idea is to remove all non-essential load breaks.
• The well-organized deployment in production on a web application can thus be done without production breaks or in staggered hours without human presence.
• We see that the role of the infrastructure team is changing; it is no longer to carry out deployment operations but to create configuration models and automation chains, update them, and oversee them.

A CHANGE OF CULTURE AND A GRADUAL APPROACH:

Beyond the tools and methods, the organization must be adapted and the stakeholders trained. It is an evolution of professional culture whose importance implies change management.

If the job of the infrastructure administrator is transformed, that of the developer is also changed, as well as the relations between these two teams.

The new deployment chain allows developers to push their work as it goes into production. They become more autonomous to have the needed environments and less dependent on deployment deadlines.

They are also more responsible for it. We discuss the “return of the developer” to qualify this evolution.

Finally, we must consider the necessary investment in time/man for the teams.

Therefore, if it is necessary to have a macro plan, a gradual approach is the surest way to reap the first benefits quickly and to arrive more quickly at the complete objective.

IMPROVE “TIME TO MARKET” BY CONTROLLING COSTS

The objective of this DevOps organization is to ensure that the number of versions and the production stage is unrestricted.

The company thus gains agility and “time to market” to deploy new functionalities every week, every day, even if necessary, and on short cycles, 15 days, or one month, depending on the scale development to be carried out.

But the company also gains, which is not negligible, inefficiency and costs, managing to produce more with the same IT team.

The entire web development market has started to swing in this direction.

For those whose culture is less internet, the transition will involve more changes and more reasons to get involved without delay.