What is continuous integration?

Source- itpro.co.uk

It’s easy to spot mistakes once a project is finished, but it isn’t easy, or cheap, to rectify them. This is particularly problematic when it comes to coding and a reason why many software developers frequently turn to continuous integration (CI) during the build process.

CI is the practice of contributing lines of code to a central shared repository, usually multiple times per day. These frequent integrations allow teams to detect errors far more frequently and far earlier in the development process – longer periods between each integration make it more difficult to isolate a problem.

As a result, there is far less backtracking to search for errors and developers often enjoy more time building. It’s also far cheaper to operate as it results in fewer major fixes and also means that projects come in on time and, significantly, on budget.

Verify, find, fix

CI is now considered best practice for building code as developers often work in isolation and then add their changes in with the rest of the team’s code base.

It can be quite problematic to wait days or weeks to integrate code – not only does this result in more bugs, but it can also create diverging code strategies or duplicated efforts. What’s more, as individual developers may be working on a copy of the original code base, failing to integrate regularly may result in the code becoming drastically out of date as the original is integrated upon by others.

Developers first share their own code into a central repository. From there the committed code triggers an automated quality control script, grabbing the latest code from the repository to build, test and validate the code sequence – if clean, it gets added to the main ‘branch’ or ‘trunk’ (the sum of all the contributions).

With the single repository being used by a whole team, developers can continue to work in isolation, although their contributions are constantly checked and tested. Everyone else in the team can see what is being added, taken out and changed, thanks to timestamps.

Because CI has a specific set of rules, such as check-in frequently, don’t check-in broken or untested code, don’t check-in when the build is broken and don’t go home until after checking in the system builds, the process takes care of itself, meaning teams need little management oversight.

The operation makes it so developers can not only add code at any time but also submit ‘pull requests’, grabbing bits of code to fix and tweak in isolation of the main branch.

Building an automated shared repository of this kind can be quite challenging and time-consuming, to begin with, but once established it can drastically improve the quality and efficiency of code development.