Continuous Integration and Delivery as working techniques

An application is developed not only to operate only in an ideal vacuum. The same application will not only run on the administrator’s computer, it must also run on all necessary PCs and devices. As soon as it leaves your hands you will not be able to control the variables, so you must ensure that it works in all types of environments.

To achieve these requirements, we always seek the best practices for our projects and their correct operation and deployment. Today, we will discuss two terms that have become synonymous with the current trend in the industry to automate without compromising quality. We are talking about Continuous Integration and Continuous Delivery.

What is Continuous Integration or CI?

We know Continuous Integration as the automation of building and unit testing an application as soon as we add new capabilities. A CI-based pipeline typically uses a platform, such as Azure Pipelines, that reacts to a change in the code repository. It then performs pre-programmed steps from a designated agent machine.

First of all, the first thing is to download the most updated version of the repository with the changes of the programmer. The pipeline compiles the code and generates a functional, executable application. The first success is that we have already optimized the creation because we do not depend on a physical machine from the developer. Thanks to standardization, we can repeat the steps whenever necessary. Also, bugs in the code at these early times can be caught and fixed sooner.

As soon as the application is compiled correctly, we can perform Unit Tests and automatic validations. Validations can be customized with code analysis to avoid bad patterns, and unit tests can be coupled with code coverage to ensure that:

1. The application meets these tests
2. The tests cover a sufficient percentage of code for the correct operation of the app

If validations and tests fail, the pipeline stops working to notify the programmer to fix the code. It won’t activate again until your developer has worked on the code and shared it with the repository.

What is Continuous Delivery or CD?

Continuous Delivery refers to the next step after CI, which is the concept of automating the setup and startup of an application. Again, we employ automation tools that will do the work from an agent machine.

CD extends the CI concept because it prepares and performs the setting up in a development environment where we do the relevant tests. The CD pipeline automatically connects when its CI counterpart completes adding a few more steps to the process.

The basic first step of a CD is to pick up the application as it exits the CI pipeline from its corresponding repository or registry. Thus, the application will always be available for subsequent setup.

Once we have it compiled, the CD pipeline applies a specific configuration to the development environment where the application will be set up. Points such as the location of the database, the user, and the password to be used, are configured. Environment attributes can be stored and used by the application to make it work in that environment. In this way, we formalize the necessary configuration and will ensure that subsequent setup works sooner without manual steps.

With the app configured, the next step is to set up the app. Depending on the type of setup, the system may uninstall the previous version or reinstall the new one. In that case, the setup will be automated and can be reproduced as many times as necessary. Cutting many possibilities that there is a failure due to manual action during the process.

A well-implemented CD pipeline extends the assembly chain, as it standardizes the configuration and setup and the working application in a common development environment.

How does a workflow with CI and CD work?

Once the pipeline that combines both terms is implemented, we can create an optimized workflow. We are going to give you an example of what a workflow would be like to implement a new functionality:

1. The developer creates the new code, which includes the newly developed functionality, and uploads it to the repository
2. The pipeline compiles the code and validates it. If there is not enough unit testing for this new functionality, stop the process and report the error to our team
3. The developer fixes the code, adds unit tests, and uploads it back to the repository
4. The pipeline validates the new version and is set up in the development environment
5. Other developers or Q&A testers can access the environment and do their tests with the application. Every change is documented and sent to the development team
6. The development team reworks the changes, shares them in the repository, and the pipeline repeats the process a third time

By implementing pipelines similar to this one, we will see that using CI and CD within our work will help organize the workflow and automate the work of many departments in our company. A very relevant advantage is that we will always have a version with the most recent changes possible.

The keys to the new working methods

The pipeline around CI and CD is designed to automate development and have an environment ready for later queries. But later, it can be very useful in other functions. For example, if we have the setup automation-ready, it is very easy to extend it with variables for other environments for your setup on similar versions. In the most extreme cases, there is the Continuous Deployment (not to be confused with the CD that we have referred to throughout the article). In those instances, we perform automatic setups not only when developing, but also in all actionable environments.

All without any manual process, only automatic validations that ensure that we do not set up incorrect versions.

Automation tools also allow you to extend pipelines to perform additional actions. For example, you might want a warning page to appear automatically on setup, or test data to be cleared after each successful test.

Both options (and many more) are available in most of the tools on the market, demonstrating the real interest in the sector in automating many of the most tedious processes of work. It is a great strategy to encourage your employees to further explore the possibilities of the most involved parties.

As an overview of what we have written in this article, we have seen how to implement pipelines that use Continuous Integration techniques, complemented with others based on Continuous Delivery, ensuring better workflows, optimization of testing and setup times, and the automation of vital tasks for good development.

Learn more about other development methods or how to start automating in other environments of your company.

Daniel Morales Fitó – Consultant at Itequia