Breaking Down Agile and DevOps Practices: The “Continuouses”

Software development is like NASCAR racing. Both require velocity, and in software development, it’s about developing, testing, and fixing issues at a speedy yet sustainable pace to avoid a crash and burn. And like driving a car, you need to drive your team forward fast and furiously, which means at least having continuous integration, then, if it’s right for your team, make it to the next lap: continuous delivery, and if it makes sense, the last lap: continuous deployment. Not every team needs to make it to continuous deployment, but all teams should aim for continuous integration, as a best practice.

Here’s a breakdown of these 3 “Agile C’s” a quarter mile at a time.

On your mark, get set, GO!

Image Source

Lap 1: Continuous Integration

Continuous Integration practices may have a smaller scope than Continuous Delivery and Continuous Deployment, but they are the first step in that direction. Even if teams only make it to Continuous Integration, they will realize a tremendous amount of value.

Continuous Integration (CI) makes frequent code integrations in an environment separate from the development environment, performing different tasks like build checks, automatic code analyses, automated functional and unit tests, performance tests, etc. The image below summarizes the CI process. Within it, you can see how developers work in their local environments and regularly send changes to a repository. Each time changes are sent, the integration server pulls those changes and builds them into a fresh environment and runs tests automatically. Then a notification can be sent to all of the developers indicating the health status of the build based on the latest changes submitted and the execution of the different checks.

The Continuous Integration process has many advantages:

• Reduces risk by integrating the code of different developers instead of doing work separately and making changes in parallel without synchronizing the repositories of different developers.
• Reduces repetitive and manual processes by delegating work to specific automation tools which decreases the likelihood of errors. This process of creating a build or version becomes automated, revised, versioned, etc., and is therefore more reliable.
• Adds visibility and transparency to the development process, so the entire team is always aware of the quality status.
• Improves the development team’s skills as they know how each advancement in the project is integrated and verified.
• Reduces the time necessary to advance software from development to production.

Interestingly, Continuous Integration gives a technological and tactical basis to methodologies such as Scrum, where development occurs in one to four-week sprints. A sprint is a period of time in which certain tasks must be completed and submitted for review. These tasks can include improvements, new functionalities, and the development of tests, among others. In Agile methodologies, the objective is to have a potentially deliverable product ready at the end of each Sprint, one which has been integrated and tested. How can this be achieved without putting integration and testing mechanisms to use frequently and automatically? This is why these methodologies work so well together (Scrum for management, and CI/CD for the development, testing and operation of the product).

Lap 2: Continuous Delivery

Continuous Delivery (CD) offers even more advantages because it represents an evolution from continuous integration. Once you have CI, the next leap that could be taken or “lap” is to move onto CD whose idea is to put a new version of a system into production at any time. This isn’t a complex process implemented once or twice a year, but something automated as much as possible and done frequently and quickly. To guide this process, teams should ask, “How long would it take to put a change in a single line of code into production?” If the answer is “too long,” chances are, your team could improve its delivery process.

A core concept of Continuous Delivery is the delivery pipeline. This concept uses a pipeline analogy with development constantly flowing through it, as the architectural pattern known as “pipes and filters” that represent a succession of tasks. This delivery pipeline considers all the tasks needed at each stage, from coding to production. In each task, filters (automatic checks) provide feedback on the process and quality of the product.

Another concept is environment promotion. In CI, software is built and tested in a fresh environment, or the “integration environment.” This environment is unstable, since each change has an impact whether it passes all the tests or not (thus breaking the build). So usually if all checks are passed in one environment, the same version of the product is promoted to another environment either automatically (if all tests are successfully passed) or manually with the execution of a command or action by a tool. The important thing is that the automation of continuous delivery is managed along with different environments and is designed to optimize certain tasks. For example, to create a more stable and controlled environment (without frequent changes) when “manual” or user tests are made.

Each stage of CI/CD makes a variety of system checks from different perspectives. Internal tests check the quality of the code, functional tests are made (automated at different levels, exploratory, and with users), performance tests assess the architecture of the solution and it’s also possible to test for security, usability, etc.

Lap 3: Continuous Deployment

And, for the last lap.

With Continuous Deployment, the degree of automation increases (going full throttle), providing even greater visibility to development and operation processes, starting with the writing of each line of code to when the program reaches production, evaluating the impact of each step. The goal of Continuous Deployment is to promote code to the production level automatically. To get to that point, it’s necessary to have in place a system of Continuous Delivery and Continuous Integration.

The following image shows how these different practices work together, along with their related activities.

The needs of Continuous Delivery are like Maslow’s hierarchy of needs. Each layer builds off the last: Configuration Management is needed to have Continuous Integration, to which we add Continuous Testing. Only with these in order can we reach Continuous Delivery and benefit from the continuous learning that comes with small feedback cycles, building a DevOps culture.

Building on these three layers of development can turn your process for testing, shipping, and delivering products into a well-oiled machine. Not only that, it builds teams as everyone becomes more knowledgeable about what others in the office are doing. And if we’ve learned anything from Fast and Furious it’s this:

Image Source

And by room, we mean office, or even, Slack Channel!

Which of the Agile C’s does your team use? How has it worked for you? Leave a comment below!

Recommended for You

Testing as the Driver Towards a DevOps Culture
3 Challenges to Effective Performance Testing in Continuous Integration