Continuous Integration in Selectle

To release a ready-to-use software product, it is not enough just to write code. After programmers have completed their work, it takes quite a long time to present the product to a wide user audience. It would seem that you only need to do nothing: merge everything that is written by different developers, create an installer, prepare documentation. Often, programmers do not even realize how long routine operations take. Often there is such a situation: everyone is in a hurry, and thus only multiplies the number of errors and shortcomings. The elimination of defects also requires some time - and the release of the product has to be postponed indefinitely.

The software product must constantly evolve, “overgrown” with new functionality and becoming more convenient to use. But as the development of projects of routine work, as a rule, also becomes more, and there is absolutely no time left to think about improving the project.
')
The situations in question are familiar to us firsthand. There was a time when our programmers assembled all the packages by hand. But projects became more and more, and the amount of routine grew. But the time for thinking about the development and improvement of products was becoming less and less. It was necessary to change something, and we thought about the introduction of continuous integration.

What is continuous integration?

The concept of continuous integration (eng. Continuous integration, abbreviated CI) was first used in 2000 in the eponymous article by Martin Fowler. According to the definition given in this article, continuous integration is the practice of software development, in which frequent project assemblies are carried out in order to quickly identify problems and errors in the early stages.

Continuous integration is based on the following principles:

1. each change must be integrated: every time a change is made to the code, a new build is launched. Compliance with this principle always allows you to have on hand the current version of the product;
2. assembly should be as fast as possible. In the recommendations for the introduction of continuous integration, sometimes there are such figures: the standard assembly should not take more than ten minutes. Actually, the meaning of continuous integration is to get quick feedback;
3. Testing should be regular: it provides prompt detection and correction of all errors;
4. integration should be carried out on a special machine, the configuration of which corresponds to the environment in which the project should be deployed. It must be a dedicated machine (it can be virtual).

What can you get by putting all these principles into practice?
First, once and for all solve the problem of changes and edits made by different programmers: everything happens in automatic mode.

Secondly, continuous integration allows for an impartial evaluation of the results of the work of programmers: something does not work on the build server - it means it does not work at all.

Thirdly, regular testing allows you to maintain the quality of the product at the proper level.

To implement CI in real practice, you need to take into account many different factors. An important point is the choice of software solutions for CI. We tried several products before we found an option that completely suits us.

CI system selection

The first continuous integration tool we tried to use was Atlassian Bamboo. By that time, we were already actively using Atlassian JIRA, and the main argument in favor of Bamboo was the unity of the user interface and ease of integration with other Atlassian services.

Before we implemented Bamboo, programmers had to do many things themselves, completely far from programming and taking a lot of time - this is primarily a matter of manual package building and testing. With the help of Bamboo, we expected to automate the assembly and save time, but, unfortunately, we did not succeed. One of the drawbacks of Bamboo at the time when we tried to use it was the routine configuration, which sometimes took so much time that the programmers themselves returned to the manual assembly: it was more convenient for them. Therefore, this tool we have not got accustomed.

Then we tried to implement the Jenkins open source tool - and ran into a number of serious problems. Immediately striking are his flaws, such as an uncomfortable interface and excessively complex settings. In the course of the work, another, much more significant minus became apparent. The fact is that in the original configuration "out of the box" Jenkins capabilities are extremely limited. The set of functions is extended with the help of various plug-ins. But these plugins are not always of good quality and often conflict with each other, and this also gives rise to many problems.

Because of all the difficulties described by Jenkins, our programmers also have what is called "did not go." But in the cloud server department, however, it is still used for reassembling cores and functional testing.

A suitable CI tool was found in further searches: this is TeamCity, a product of JetBrains. Among its undoubted advantages should be called:

• easy setup and administration;
• quite a large set of functions "out of the box", as standard;
• ability to integrate with various development environments;
• ability to integrate with Atlassian products used by us (JIRA and Confluence);
• availability of project template engine;
• quite flexible licensing terms.

Interestingly, TeamCity is based on the same approach, which was one of the reasons from Jenkins: the expansion of the set of functions is also carried out with the help of plug-ins. But, as mentioned above, Team City has quite wide capabilities in the basic configuration, and therefore no need to install plugins for all occasions; the few plugins that we had to deal with worked quite stably. Another important advantage of TeamCity is ergonomics and usability.

Instead of conclusion

Let us try to describe the benefits that we have gained as a result of the implementation of continuous integration in the language of numbers and facts. We give statistics for all the time that we use Team City:

• 102 projects;
• 280 assemblies;
• 320 GB of artifacts;
• approximately 1000 new assemblies are carried out every week.

As a result of automation of routine operations, we managed to save about 33 hours a week. We devote the released time to the development and improvement of existing services, as well as the introduction of new ones.

Those who can not comment on posts on Habré, we invite to our blog .