Continuous Integration

Continuous Integration


Continuous Integration (CI) is a process that allows developers to integrate, in a repository share by the entire team, code developed by himself, at least once a day. At an Utopian Universe, those integrations should happen several times each day, basically every time some code is “pushed” into the repository. This action will trigger the automated process.


Agile methodologies demands code to be always “ready” to be delivered. This process of continuous integration of the entire team’s code, in the product/project code base, allows an early error detection.

In a Waterfall process, each code delivery might took several months to happen. As you can imagine, in that time, it was usual to set a “War Room”, where the entire development team would be, in the company of the entire operations team, QA team, product team, and management team. The delivery process were a terrible chaos, a real nightmare, and it could take hours to deliver (don’t bother asking about any issue that might occur, the responsible team had to fix it “pronto”).

In fact, back in those days, imagining that each code push might trigger a battery of tests (unit, integration, acceptance, …) and have immediate feedback about the possibility of the new code breaks any existing functionality, it was unthinkable. A true adventure !!


There are several available options for those that wish to start using a development pipeline with continuous integration. Probably the most notorious is Jenkins. An open-source tool written in JAVA. To those that do not want to add another tool to their setlist of tools to administer/manage, there are some SaaS solutions. At my ex-employer log, they use the CloudBees’ SaaS Codeship. Nowadays at RUPEAL, we use Rendered TExt’s SaaS Semaphore.

Once configured, every time a new push to a Git repository happens, it will trigger an automated process where a virtual environment, with characteristics specified by ourselves, is set and where the build process will happen, followed by the entire tests battery – unit, integration, acceptance, mutation, …

In any scenario, if a problem occurs, the entire continuous integration process fails and we will have a complete report. It is important to state that when the process fails, there are no possibilities for a deployment – automatic or manual – to whichever environment.

There will be no eXtreme Programming without this important process !!

Leave a Reply

Your email address will not be published. Required fields are marked *