Continuous Integration: A Brief Overview
In addition to writing code, a lot needs to be done before a program can be launched. This can be very time consuming. It might not seem like much—combine everything written by different developers, create an installer, prepare the documentation—but most programmers can’t imagine just how much time these fairly routine operations actually take. It’s not that uncommon for an entire team to rush to get their work done, but that only creates more errors and issues. These problems take time to resolve, and inevitably, the product’s release gets pushed back to TBA.
Software should constantly be developed and improved, new functions should be added, and the product should become easier to use; however, as the routine job of developing projects becomes more intense, improvements fall indefinitely to the background.
We know this situation first-hand. There was a time when our programmers compiled packets manually, but as projects got bigger and the number of tasks grew, we had less and less time to think about developing and improving our products. Something had to change. As a solution, we looked to continuous integration.
What Is Continuous Integration?
The term “continuous integration” (CI) was first used in an article by Martina Faulera in 2000. According to the article, continuous integration is the practice of developing software while frequently compiling a project in order to find problems and errors as they appear in the early stages of development.
Continuous integration is based on the following principles:
- Every change should be integrated. A new build should be released every time the code changes. According to this principle, it’s possible to have the latest version of the product always on hand.
- Builds should be made as quickly as possible. Articles and recommendations for implementing continuous integration sometimes include the following line: a standard build should not take more than ten minutes. Essentially, the point of continuous integration is quick feedback.
- Testing should occur regularly. This ensures errors are detected and repaired as they appear.
- Integration should occur on a clone of the product environment (or as close to that as possible). This should be a dedicated machine (which itself can be a virtual machine).
What’s the point of implementing all of these principles?
Firstly, you solve the problem of changes and corrections being made by different programmers once and for all: everything is done automatically.
Secondly, with continuous integration, it’s possible to make an impartial assessment of programmers’ work: if something doesn’t work on the compiled server, then it doesn’t work at all.
Thirdly, regular testing lets you maintain the quality of your product.
When putting CI into practice, a lot of different factors have to be considered. Special attention should be paid when choosing CI software. We tried several products before finding a solution that fully met our requirements.
Choosing a CI System
Bamboo
The first CI tool we tried was Bamboo by Atlassian. Now, we had already been using Atlassian’s Jira, so the main arguments for Bamboo were the single user interface and easy integration with other Atlassian services.
Before implementing Bamboo, there was a lot non-programming work our programmers had to do, and this took a lot of time. We’re talking mainly about manually compiling packets and testing. We figured we would be able to automate compiling and thus save time with Bamboo, but unfortunately, things didn’t work out like that. One of the problems with Bamboo was that when we tried to use it, the configuration at times took so long that the programmers just went back to compiling manually: it was just easier for them.
TeamCity
We then decided to look at TeamCity by JetBrains. Its obvious advantages include:
- easy configuration and administration;
- a fairly large set of out-of-the-box functions;
- integration with various developing environments;
- integration with the Atlassian products we already use (JIRA and Confluence);
- template engines for projects; and
- fairly flexible licensing conditions.
An interesting quirk about TeamCity is that if you want to expand its functionality, you have to use plugins. Granted, the basic set of functions is pretty extensive, so many operations can be performed without installing anything, and the few plugins we had to use were fairly stable. Overall, TeamCity is an easy-to-use program for CI, which may prove ideal for some systems.
We used TeamCity for some time and were fairly pleased with the results. Under this system, we achieved the following:
- 102 projects;
- 280 builds;
- 320 GB of artifacts; and
- over 1000 new builds each week.
Jenkins
Even though TeamCity proved to be a reliable solution, we decided to revisit an open-source competitor that we weren’t too thrilled with the first time around: Jenkins. We first tried Jenkins in 2013 and were quickly turned off by its awkward interface and overly complicated configuration; however, the product has since been significantly developed.
As an open-source project, the community support and plugins have made it a much more convenient solution with ever-expanding functionality. This has let us develop our own CI approach and management system. Additionally, we have been able to simply interactions throughout the company and system. Although there are sometimes plugin-compatibility issues (one may cause errors in another), these are often easily resolved.
Conclusion
When you’re working across departments and want to maximize your efficiency, continuous integration is certainly a move in the right direction. Although we first used TeamCity as our CI engine, we have since made the jump to the open-source solutions, Jenkins.
With Jenkins, we have been able to not just implement continuous integration, but develop our very own CI system. We’ve given our system the nickname “Jenkins of Jenkinses” and will be giving an in-depth look into it in our next article.