Continuous Integration and Deployment Best Practices

Continuous Integration and Continuous Deployment with Agile Development

For a good performance of agile development teams, in addition to applying the fundamentals with the 3 pillars of Transparency, Inspection and Adaptation, the software engineering practices mentioned (Integration and Continuous Deployment) provide the tools needed to increase delivery efficiency and our ability to inspect. In addition, it helps to reduce the time and effort of each delivery cycle, increasing the team's opportunity to adapt to changes more quickly.

In general, these processes, when well applied, tend to increase the quality of the final product delivered, anticipating problems that would only be identified in the final stages of development, making it more apt to meet the demands that will come along its useful life. Therefore, without having to go into more detail, we can already say that Integration and Continuous Deployment has a very close relationship with the culture of agile software development, regardless of the framework used.

Continuous Integration Process

Continuous integration is a software engineering practice that originated in XP (Extreme Programming) and boils down to integrating distinct parts of the source code at the highest possible frequency, that is, continuously. The problem that this practice proposes to solve is commonly known as "integration hell", when several parts of the code and / or project work separately, but together they become incomprehensible. This scenario is very common in development processes where multiple developers work on distinct functionalities and at some point need to be integrated. In traditional software development methodologies (for example Waterfall process) it was common to plan an integration phase at the end of the project, in which pieces of the puzzle were embedded and everything should work as planned months or years earlier. Obviously, we now know that this approach was mostly unsuccessful, and the effort to complete this integration process was almost always greater than planned.

If we analyze in a deep way, this was to be expected. Major problems arise by integrating distinct parts of the system, heightened by the even greater difficulty of predicting what kind of problems the interaction of these distinct and, hitherto, separate parts, can bring to the project. Continuous Integration does the reverse: We ensure that the pieces of the puzzle are embedded as soon as they are "ready" and have been sent to the parts repository. This approach lowers risk by bringing many fundamental issues into the present and ensuring that integration problems are resolved as quickly as possible, that is, we anticipate problems. In addition, since this integration is done all the time and with smaller pieces of code, it is less prone to errors, ensuring that the value of the project is preserved. We know all the time, within a short space of time, that all the pieces work (or not!) together.

In practice, what we need to keep in mind when we talk about Continuous Integration are some simple steps that will be taken care of by our build server:

●     The source code will be integrated with each update (or from time to time). That is, every time the code changes are synchronized with the repository, the build server will build the project.

●     As a software quality assurance proposal, automated testing will run after the build to ensure that bugs already found do not come back and existing (or new!) Testing scenarios continue to work.

●     After each source code integration process, automatic notifications are sent to those responsible if the build is broken or the tests do not pass so that any problems can be corrected as soon as possible.

Continuous Deployment Process

Continuous Deployment is another software engineering practice that begins where Continuous Integration ends. After performing Continuous Integration and the generation of the new build safely through the stages of integrated automated testing, it makes sense to move to the second stage of the process to be able to publish the changes and the new version of the product.

Every process involving manual publishing is a repetitive task that can burden the development process, so if we have a secure, automated build process, there is nothing better than to do continuous and automated publishing.

There are challenges related to the continuous deployment process, but most of them are not technical, but involve processes as well as how to manage the customer's expectations regarding changes in the product.

Through Continuous Integration and Deployment, we are able to increase transparency and decrease customer anxiety, which means that all those involved in the software development process participate more directly in the project. In addition, because we automate repetitive tasks, team productivity increases.

The adoption of any agile software development framework is already a breakthrough, but over time the adoption of other software engineering techniques will give more security and flexibility to the process as a whole, reflecting increased productivity and quality of deliveries.

The importance of automated testing in conjunction with Continuous Integration and Deployment

The use of Integration and Continuous Deployment techniques is not a guarantee of software quality, since there is no use of an automatic process of continuous integration and build generation if there are no well-planned automated tests that guarantee the quality of the builds, otherwise the situation may be much worse because we will increase the speed of troublesome deliveries and overwhelm the work of the development team to solve all the bugs that will be caused by these unsuccessful deliveries.

Within this context, we can say that software engineering techniques of Continuous Integration and Continuous/Automatic Deployment allied with a good quality assurance processes through the application of automated integration tests represent important pillars to support the agile development of software, these pillars will enable the agility, flexibility and transparency necessary for the development team in the evolution of each development iteration, regardless of the agile framework chosen.

Although it is not the scope of this article, the choice of good tools to support the integration, build and automated testing processes are also fundamental to the successful adoption of these techniques.