Continuous Integration
0 comentarios

What is Continuous Integration?

Like many other agile methodology procedures, one of the main functions of the CI (Continuous Integration) is to facilitate the work for the developer.

When we talk about Continuous integration, we refer to the creation of code between different developers and under a thorough review of it. To make this possible and easy, it is not expected that the code is finalized, as was done in conventional or cascade methods, but that the work is divided into small tasks, also called sprints, which do not involve a great effort or a great investment of time, so that these tasks can be reviewed frequently.


It is the automated process to assemble and test executable versions of the software, so that the development team can build and test the software they are working on several times a day.

This concept is known as “continuous integration” and is one of the practices of Extreme Programming, however it is not necessary to be following Extreme Programming to apply it.

Continuous integration is a development practice that requires developers to integrate the code into a shared repository several times a day. Each record is then verified by automated compilation, which allows teams to detect problems at an early stage. By integrating regularly, you can detect errors quickly and locate them more easily.

To take into account: When talking about "integrating" software, it refers to the specific process of generating an executable version of a software, which may involve compiling the source code, packaging, including configuration files, etc.

Integración Continua

Figure 1: Continuos Integration



Like many other Agile methodology procedures, one of the main functions of Continuous Integration, according to Duvall, Matyas, and Glover (2007), when talking about continuous integration, it refers to the creation of code between different developers and under a thorough review. To make this possible and easy, it is not expected that the code is finalized, as was done in the specific cascade methods, but that the work is divided into small tasks, also called sprints, which do not involve a large effort or a great investment of time, so that these tasks can be reviewed. These reviews must be done at least once a day and are usually done at the end of each working day. Based on the results, you can continue creating or entering the modification phase, where once the error is detected, the group will decide how to overcome it and what should be modified.

Agile involves working quickly and trying to reduce the range of errors to the minimum possible. One way to achieve this is to promote teamwork, so that they help each other overcome obstacles and learn from each other.

Another feature is to break down large projects into small tasks, so that the work is much more bearable, lower pressure and more frequent delivery / validation times.

Therefore, a continuous flow of reviews, opinions, tests, feedback between the client and among the team members, overcoming errors, taking care of the code and working comfortably makes these types of practices so frequent today. It is now possible for a job to be more efficient and profitable.

Importance of continuous integration

Beck (1998) made a publication that emphasized the importance of fulfilling the objective of the development of modern applications, with multiple developers working simultaneously in different functions of the same application. However, if an organization merges the entire diversified source code into a single day (known as the “day of merger”), the resulting tasks can be tedious and manual, and can take a long time.

This happens because, when a developer works in a separate way to implement a change in an application, there is a possibility that this change may conflict with other changes implemented simultaneously by other developers. Continuous integration helps developers merge the changes they introduce into the code to incorporate them into a shared division (or branch) more frequently, even daily. Once the changes implemented by a developer in an application are merged, they are validated with the automatic development of the application and the execution of different levels of automated tests (generally, unit tests and integration) to verify that the changes have not damaged the application.

This means trying everything from classes and operation to the different modules that form the entire application. If an automatic test detects a conflict between the new and existing code, the CI facilitates the resolution of these errors frequently and quickly.

Continuous Integration System

For a system of continuous integration to be efficient, there are certain practices that we must carry out:

  • Maintain a repository from a single source.
  • Automate the construction of a project.
  • Make the project run its own exams.
  • All project members commit to a main branch every day.
  • All those committed to the main branch execute a compilation.
  • Erroneous constructions should be fixed immediately.
  • Perform construction as quickly as possible.
  • Make tests on a copy of the actual production scenario.
  • Continuous deployment
Ciclo de vida de devOps

Figure 2: Life cycle of devOps


What is continuous delivery?

Continuous delivery (CD) takes the CI principle a step further according to Wallgren, A. (2016). It is the automated process of compilation and testing that extends to all application components, including configuration files, database schemas and environments. Each time changes are made to any of these components, the compilation and testing procedure is performed (ideally through automated channeling) so that the resulting compilation can be easily implemented. The resulting compilation does not always have to be published in production, but at least it must be implemented in an environment (such as staged organization) as close as possible to production. Therefore, product owners can be sure that any compilation that passes through this channel is released to the public.

Version control

The developer's job is the code. This code is shared and stored securely generally with the use of tools. We call this type of version control tool according to Typical CI process (Pepgotesting, 2019) because it not only stores the code securely and allows developers to share the code and collaborate together as a team in the Same code, but also code versions. This means that every time a developer adds some code, it does not replace the previous version, but adds a change in the history. That way, developers can mess up the code and can easily return to an earlier version. They can also investigate problems and understand what happened in the code by looking at the story.


GitFlow is a branching model according to Scot Chacon (2009). The GitFlow model is ideal for continuous integration. The idea is to ensure that every time a function branch merges to develop, continuous integration checks that everything is correct in this main branch.

This control is done regularly. Depending on the context of the project and the maturity of the equipment, this check can be performed only once a day or every time a developer makes a unique change.

Creación de una Rama

Figure 3: Creation of a branch



Basically, what we are talking about is called branches in the version control terminology. One of these branches has a special meaning, it represents what is in production and what is the latest current version. All generated code is uploaded to one of the branches and is often called (but not always) the master branch to generate the deploy.

When developers create a new feature, they don't work directly in this branch, they create it in a different one where they interact.

Main Branches

The central repository has two main branches with an infinite life:

  • master (by default and in production).
  • develop (in development).

Support branches

Unlike the main branches, these branches always have a limited lifetime, since they will eventually be eliminated.

  • Feature branches
  • Release branches
  • Hotfix branches

Figure 4: Merge



It is the term merge in the previous section to a single branch, usually the new branch is integrated into the master.

Advantages of continuous integration

Continuous integration provides several advantages or benefits in software development which are mentioned below:

  • Easily deductible, the name acquired by this practice is descriptive and literal. It is based on the continuous review of the code to be able to integrate the improvements little by little or update daily to obtain a much more reliable result and in a shorter period of time. This allows a better adjustment to the proposed timings and avoid the pressures derived from last minute deliveries.
  • Aptitud on a personal level. Since these practices are carried out in joint projects, it is the developers themselves who analyze the code created, supporting each other. They will learn different integration methods and are forced to overcome different errors or failures found in the created code day after day. This implies encouraging communication between the team, and makes it much more enriching both at the individual level and at the group or team level.
  • Accelerate the detection of faults, constant version for tests, or a first phase to be able to contrast the evolution of the code in a way that makes it possible to detect errors in time and to correct them.
  • At the same time, at all times each team member has access to the final version.
  • Continuous integration guarantees quality results and correct operation of the project thanks to its continuous supervision and error reduction.
  • Obviously all this process of revisions and corrections that are carried out as frequently as possible, are part of an automation that is developed to facilitate communication between the team and the evolution of the project which requires the time span dedicated to debugging errors.
  • Avoid waiting to find out if a code works for this by monitoring the most relevant project metrics, so that the quality of the project can be kept in mind at all times. This will eventually lead to a good code without modifications once it has been taken to the last phase, since it is optimized as it is built.

In summary, the benefits of continuous integration consist of "solving problems quickly." Since the software is frequently integrated, when an error is found, it is typically not necessary to go back much to discover where the fault was introduced. In comparison, when a team does not follow a continuous integration strategy, the periods between integration are long and the code base is very different between each integration, so when errors are found, much more code needs to be reviewed, which requires more time and effort. In Fowler's (2009) words, "continuous integration does not eliminate defects, but it does make it much easier to find and correct them."

Disadvantages of continuous integration

  • Complexity in handling the tools, this implies a cost in the training of the personnel or the equipment given that this entails additional time in the development.
  • Hardware costs, for this a set of machines is needed that will house the various tools for continuous integration: repository, automation, environments, etc.
  • Initial configuration time, in an environment in which the test cases are designed, developed and documented properly, we have to invest the appropriate time in the configuration of the continuous integration tools.
  • Change of usual processes.
  • It requires additional servers and environments.
  • It could lead to delays when several developers try to integrate their codes at the same time.

Adanza, F. (2016), Implementing continuous delivery: Jenkins or Bamboo. Disponible en: Junio 2017)

Apache Maven (2019). Disponible en

Atlassian, (n.d.), Understanding the Bamboo CI Server, Disponible en: (04 Junio 2017)

Beck, K. (1998, March). Extreme programming: A humanistic discipline of software development. In International Conference on Fundamental Approaches to Software Engineering (pp. 1-6). Springer, Berlin, Heidelberg.

Carlos Blé Jurado(2016) Diseño Ágil con TDD.

Continuous Integration (2019). Disponible en:

Docker (2019). Disponible en

Fowler, M., Beck, K., Brant, and J. (2009) Refactoring: Improving the Design of Existing Code.

Gitlab (2019). Disponible en

GIT, GitFlow and Continuous Integration for Dummies (2019). Disponible en: (20 Julio 2019)

Gómez-Luna, E., & Fernando-Navas, D., & Aponte-Mayor, G., & Betancourt-Buitrago. L. (2014). Metodología para la revisión bibliográfica y la gestión de información de temas científicos, a través de su estructuración y sistematización. Dyna, 81 (184), 158-163.

How To Orchestrate DevOps Tools Together To Solve Our Problems? (2019). Disponible en: (20 Julio 2019)

Jenkins 1.396 released, The first release of Jenkins is posted, Kohsuke Kawaguchi.

Jez Humble and David Farley (2011). Continuous Delivery. Disponible en

Jgarzas (2014, 18 de octubre). Ph.D. en informática, Postdoctorate en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Martin Fowler (2006, 1 de Mayo). Continuous Integration. Disponible en:

Nexus (2019). Disponible en:

P. M. Duvall, S. Matyas, and A. Glover (2007) Continuous integration: improving software quality and reducing risk. Pearson Education.

Scot Chacon. Pro Git. (2009).

Sneha Kunja, S. (2017), What is Jenkins?. Disponible en: (04 Junio 2017)

Sonarqube (2019). Disponible en:

Stafford, J. (n.d.), Why automated continuous integration is a must for microservices success. Disponible en: (03 Junio 2017)

Typical CI process, (04 Junio 2019) Disponible:

Wallgren, A. (2016), Continuous Delivery and Release Automation for Microservices, Disponible en: (03 Junio 2017)


No existe comentarios

{$ comment.fullName $}

{$ | date:'medium' $}

{$ comment.comment $}

Deja tu comentario: