Integration poses problems that are well known to those involved in software development: new code is written that performs a crucial task, the source code is deployed to the project, and problems arise. To avoid a catastrophe at the end of a long development phase, many teams decide to apply continuous integration, with which changes are implemented every day directly in the project, preferably several times. times a day.
Like continuous delivery, continuous integration is a very common practice, especially in the field of agile software development. The goal of this modern approach is to work in small steps to achieve a more effective development process and to be able to react more flexibly to changes. Continuous integration was first mentioned in Kent Beck’s definition of extreme programming methodology (eXtreme Programming). However, this idea already existed before and was applied, for example, in the Booch method.
What is continuous integration?
Continuous integration is a solution for scenarios such as the following: a company works on a large project, which consists of custom software development services for a client. Teams design partial aspects of the application and developers program the various features. After several months or even years of work, all the software must be assembled and compiled and this is where the problems appear. In these cases, it could take months to detect and iron out all the bugs, put all the code fragments together, and push the software into the testing and deployment phases.
In continuous integration, new code is added much earlier and not when everyone involved has completed their part. Developers integrate their code once or several times a day into the main line, the source code that all programmers can access. Since these are small pieces of code, the integration is done quickly and, in just a few minutes, the developer can make his work available to the rest of the team. If any errors are discovered in this process, they can be quickly located and resolved.
Continuous integration is an agile software development service in which engineers integrate the pieces of code they develop little by little rather than after the entire project is completed.
Procedure
In practice, continuous integration is applied as follows: an engineer must develop a function. Before starting work, the full version of the application code will be downloaded, the so-called main line. In this local version, also called a working copy, it will be the one you work on. When you have completed your task, you will test the program, fix any errors, and then upload the new version back to the main line.
However, this engineer does not work alone. While he was developing his task, other team members carried out theirs and each of them will have a different version of the software on their computer. Also, the mainline version has probably been modified by other developers in this period, so you will need to update your local copy. If any problem arises, it will be your responsibility to fix it. Next, he will integrate the code into the main line and test the program again. Only when no further errors occur, which may occur if you have not successfully updated your local copy, are you complete and ready to move on to the next task.
Behavior
When working in this way, a series of rules must be followed. In most cases, programmers follow the principles that Martin Fowler described to carry out successful continuous integration. Firstly, it must be ensured that everyone involved is on the same level and that there is no one whose behavior could cause problems.
A single source code
Although it may seem obvious, this is one of the most important factors, since all team members must use the same tool, that is, the same repository, when working on the code. And this doesn’t just apply to source code. For applications to work, other elements are needed, such as databases, which must also be contained in the same place. For this reason, Martin Fowler recommends building a repository in such a way that any engineer joining the project with a new team will find all the necessary files in one place.
Automate project build
Obtaining a functional project from source code involves compiling it, updating databases, and moving files from one place to another. All of these tasks can be automated and it should be possible to run the build with a single command.
Systems that perform their tests
A team can benefit from even more automation and speed through continuous integration by incorporating testing mechanisms into the build process. Like the build itself, testing can be carried out in a short amount of time, and ideally, a complete plan of testing mechanisms will be implemented.
Daily integration
A continuous integration process will only work if all team members respect the system. The moment any member of the team does not integrate their code into the main line, the rest of the teammates will start from a false premise. All developers assume they are working on a stable system, but if someone takes more than a day to integrate their code and continues working on it, bug-finding could eventually become a real problem. Communication is also an important factor in continuous integration, as if developers stay on top of things, small issues can be resolved more quickly.
Operational main line
Mainline code will need to be continually tested and always operational, so developers should build the project here and not just on their local copy. In this context, everyone will also have to worry that their contributions are valid and that they work correctly, so everyone will have to check the code and the build. If a bug appears, they will have to fix it and ensure that the code does not contain errors.
Immediate repair
The most important thing about continuous integration is that there are no defective versions left in the main line, which means that the resolution of the bugs cannot be postponed. In the words of Martin Fowler, there is no problem if the builds do not work and the code must be changed, but the system requires that the repair be carried out immediately. All developers need to be able to assume that their mainline code works correctly, otherwise, they could be working on broken code that will end up triggering a wave of bugs.
Quick integration
The complete integration of the project (including the testing phase) should be done as quickly as possible. Extreme programming (XP) allows only 10 minutes for this. Since a developer must perform several integrations daily, if mechanisms were not established to speed up the process, a large amount of time would be lost. So that it does not take too long, the idea of performing all possible tests directly should be discarded and instead, a two-phase system should be applied: in the first phase, tests are carried out in which the compilation of the project can be fast. The second phase will last several hours and will carry out more exhaustive tests.
Testing in a replica of the production environment
Testing should be performed in a secure environment with a configuration the same as the production environment. Under certain circumstances, this could be very expensive, but virtualizing your computers will reduce the cost factor.
Accessibility
Everyone involved in the development of a certain software should be able to easily obtain the latest executable of the program and run it. Implementing this aspect is relatively simple since continuous integration requires that all files be in a single repository that everyone knows about. This way, additional testing can begin in the programming process, stakeholders can use executable files for demonstration purposes, and quality managers can examine the numbers.
Good communication
Not only is it important that everyone involved has access to the source code and can execute the file, but there must also be a record of who has made what modification. Additionally, custom software development company must report when they are in a build process, for which some teams use visuals that indicate that integration is being worked on.
Automated deployment
Finally, the software deployment must be automated. Performing continuous integration requires moving executables between multiple environments, which can require a significant amount of time. Therefore, it will be better to do it automatically using scripts that facilitate the deployment of applications between environments.
Advantages and disadvantages of continuous integration
Despite its positive aspects, continuous integration has proven not only to provide advantages. Without a doubt, it avoids carrying out a long and difficult integration phase at the end of the project and provides the possibility of detecting errors in time, but it can be very difficult to apply for teams accustomed to other methods, in which case it could even waste more time than you would save.
Advantages
- Constant communication
- Avoid a large final integration
- Exact record of modifications
- Constant availability of a functional and updated version
- Early error detection
Disadvantages
- Change of usual processes
- Requires additional servers and environments
- Development of your test plan
- This can lead to delays when multiple developers try to integrate their code at the same time
Selection of continuous integration tools
In principle, continuous integration can be applied without the need to use specific tools, since all phases can be carried out manually, but this would require a lot of time and discipline. With the help of the right tools, the job can be made easier. These tools usually provide a server and help in project compilation and version control.
- Jenkins – This popular program written in Java is a fork of Hudson, which has stopped being updated. Open-source software works with different build tools and version control systems.
- Travis CI – This continuous integration tool is especially appreciated for its support for GitHub, which informs Travis of changes made to the code. There is a free version of the software for open source projects and there is also a paid version.
- Bamboo – With Bamboo Server, developers will be able to perform integration, deployment, and rolling release management. It belongs to the Atlassian company and has a web interface and Java technology. Bamboo helps developers by automating processes and works with different build tools. There is a free version for open-source projects.
- Gitlab CI – GitLab offers its continuous integration program that works with the well-known version control tool. Pipelines can be configured and adapted to the requirements of each project. Additionally, it is compatible with GitLab CI Docker.
- CircleCI – There are two different versions of this software for continuous integration. The versions allow you to work directly in the cloud or on your local server.
- CruiseControl – Although it was developed by ThoughtWorks (a company related to Martin Fowlers), CruiseControl has become an independent project. This free software is based on Java and is compatible with any platform. Among others, CruiseControls offers developers a control panel (its web page) where the status of builds can be consulted.
- Codeship – Codeship aims to offer developers an easy option for continuous integration. Based on container technology, automation can be easily created with it. For this task, the company offers two different versions: Basic and Pro.
- TeamCity – This commercial software puts a lot of emphasis on interoperability with other tools. Its standard version is compatible with numerous programs and the spectrum can be expanded using plugins. A feature of this software is Pre-tested commits. TeamCity checks new code before integrating it into the mainline and reports any errors.
Source: Continuous Integration in Software Development
