In its literal meaning, CI is an uninterruptible process of integration of something. That implies the integration of separate parts of software program code. The more often we group the program code (and test if it can be grouped at all or if autotests are performed), the better!

With the help of CI, you can easily convert all the manual tests into automated ones. It is used by some groups of developers who not only create a program code but also write autotests. Sometimes, HR asks about it on interviews – just to see if a candidate understands what it is. And no doubt, this concept must be familiar for every self-respecting software tester.

Further in the article, we’ll talk about the main concepts and basic purpose of CI. We’ll analyze how CI works and what tasks it carries out!

The Concept of CI

CI is a unique process of building, deploying, and testing software without human resources. To make it clearer, let’s take a look at a simple example.

Let’s just say, we have 2 programmers John and Lisa, and 1 tester Paul.

Lisa writes program code and adds it to the version check system (VCS). This is some kind of repository for program code – a special place where all the current changes should be stored. Specialists can analyze them at any time for what changes and under what conditions were made.

After, John finishes working on his part of the code and saves it inside the VCS. But this is very trivial source code – just a set of necessary .java files or some other file extension.

To make it possible for Lisa to check all the changes, one needs:

• Make a build from the source code;
• Run it inside the test machine.

Making program build is a process when developers make one necessary file from several ones. It is possible to make a build by oneself but it is quite a long process: one should remember the following: in what order it needs to be run, what files are dependant on each other, if there is an error in the created command, etc.

Typically for such purposes, specialists use a specific tool. If we have java files, it can be Ant, Maven, or Grable. Based on the builder, the user can customize the overall build process just once, and then run everything with one command at a time.

Human Factor

Everything that was described above is a kind of semi-automation. It’s impossible to avoid human resources, since only a tester or a programmer must enter the necessary commands and make test builds manually.

Let’s imagine that only programmers are engaged in this process. When Lisa asks for a build for testing, John updates the version from the repository and manually builds the new test version.

However, it is worth remembering that building a version of the program does not mean that we will definitely get it for testing. You need to run this somehow! These tasks are performed by the application server: jetty, apache, wildfly, and many others.

But again, this is semi-automation since the programmer must copy the test archive to the stand and connect the service. This is done by several people, which means the human factor once again.

If we remove a person from this chain, we’ll finally get a real CI, a product that automates the verification process. It collects all the current changes from the repository!

When the CI receives the changes, it automatically runs the entire build of the current version of the program and the automated tests. If the build fails, the system automatically writes an email to everyone who needs to know about it:

1. A project manager;
2. The programmer who made the changes;
3. Others: everyone who has access will receive notifications.

If the build goes well, CI will automatically deploy the program to the test machine. As a result, Lisa can test the new build version!

To Sum Up

The CI system is a specific software product that monitors your version control system, and in case of the slightest changes there, automatically collects them and conducts autotests (of course, after the specialists write these tests). If there is a failure, it lets all the interested parties know about it.