Intive Blog

Continuous Integration: What It Is Not

Such could be a theme to elaborate in an exam. It could account for 5 or 10 points of the final score. Some may answer that continuous integration is to integrate continuously. Some may even be unable to answer. In order to say what continuous integration is not, first we need to understand what it is.

Continuous Integration

Continuous integration is considered to be a good practice when developing software. It involves integrating the changes made into the source code and making sure that it works, even when it has been modified by different people. It is recommended in agile methodologies, and a foundation for extreme programming and DevOps practices.

To be able to say that we are implementing continuous integration in our projects, we should guarantee the following three aspects:

  • A Central Repository

Regardless of the tool used to centralize (git, subversion, mercury), the code to be deployed in our environments should be kept in this repository. It is advisable that developers define the rules for working in the repository. The communities gathered around each tool may offer guidelines that could be useful to leverage its full potential. You can find an example of git here.

  • Automated Tests

Many times, commiting the code within the repository seems to be enough to consider it stable. But in reality, it is NEVER the case. EVER. When one aspect of the application is modified, one can unintentionally affect a functionality that was working just fine up to that moment, so it is vital to carry out automated tests in order to identify potential issues. Continuous integration is very useful for detecting errors in early stages, considering that the cost and effort of solving a problem increase as development progresses.

Within automated tests, we can also run unit tests. In agile teams, the tech lead should promote an acceptable code coverage. Code coverage means defining what percentage of the unit tests cover the written code. That does not mean that all the use cases are covered, but that all the parts are, and that they are tested at least once.

Unit tests are not the only type of tests in continuous integration. There can also be integration and functional tests, which will yield better results if we seek to achieve a quality product. In addition, we can analyze whether the code meets coding and complexity standards.

  • A Stable Product

Implementing tests leads to a product worth sent to production environments in short periods of time. Ideally, after we integrate the code and carry out tests (and those tests are passed), at the end of the day we should have a new version available to install. We will probably obtain metrics too that will help us improve our product, such as cyclomatic complexity and test coverage.

We are now able to establish what continuous integration is not:

  1. Using git.
  2. Using jenkins or other similar tool to download and compile the code.
  3. Compiling the code directly in an environment.
  4. Not testing.
  5. Films starring Adam Sandler: nor can they be regarded as good films.

Rodolfo Cordero

Rodolfo Cordero has been a developer at intive since June 2016. He is a graduate in Software Development from the Universidad Latina de Costa Rica, his country of origin. A regular reader and music lover, he took courses in cocktailing and to become a barista, skills that delight the staff of intive in the after parties organized by the company.

Add comment