Much is said about agile methodologies, but there is a need to use some techniques for these methodologies to succeed, one of the techniques is Continuous Integration.
The continuous integration is a term originated in the agile methodology XP and used in other methodologies, consisting in a simple goal: the developer integrates the code altered and / or developed to the main project in the same frequency with which the functionalities are developed, being done many times to the day rather than just once. The main purpose of using continuous integration is to verify that changes or new features have not created errors in the existing project.
“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage” - Martin Fowler
Version Control System and Continuous Integration
As a crucial part on the development proccess and for the success of continuous integration, versioning should be used. One of the goals of version control is collaborative work, in which several developers work and share data. Versioning is essential for methodologies in which the team must constantly work together.
The version control system resolves some great problems when we work as a team:
- how share the information in order to have the last valid version and known who did the changes;
- how to prevent developers from reworking that already developed, etc.
There is a set of tools for centralized version control, of which Git as the most common. These tools allow developers to work together, enabling multiple clients to access, view, modify, and send new code. Among the benefits of using a version control system, we have:
- possibility to restore previous versions of the code;
- compare codes;
- change management.
In the versioning flow basically the developer writes your code, and performs a build before integrating your code with the code base. After performing the build, the system must be integrated into the main code of the version control system through synchronization.
This process should be done frequently, thus avoiding the accumulation of coding for repository integration. Some methodologies dictate that the developer can only consider the work done, when the code is synchronized, builded on an continuous integration tool and after all the tests executed successfully.
Continuous integration tools allow you to configure an automated build system. This is important because as the system is automated, if errors occur, the developer can be notified and the cause can be analyzed.
So, and the Integration?
With a centralized version control, automated builds and tests, we can have the integration, which is, above all, a communication, and for that, everything must be ready and adequate.
The only prerequisite for a developer to post their changes to the main release is that they can perfectly run the code. This, of course, includes going through the build tests. As with any code-launch cycle, the developer first updates his working copy to match the main version, resolves any conflicts, and then generates the build on his local machine (or continuous integration system). If the build passes, then it will be released to post its changes to the main version.
Continuous integration allows developers to quickly find version conflicts, and troubleshoot quickly and continuously. The key to good integration, as seen before, is a centralized version control environment, automated builds and tests.
Why CI is important to DevOps?
In few words, CI is one of the fundamental pillars of the DevOps concept, which is a term designed to describe a set of practices for integration between the software development, operations (infrastructure or sysadmin) and support teams involved (such as quality control ) and the adoption of automated processes for fast and secure development of applications and services. The concept proposes new thoughts about the work to valorize the diversity of activities and professionals involved and collaborative attitudes. It is a process that makes possible the agile development of applications in an infrastructure management model defined under rigid and bureaucratic rules.
The DevOps culture is based on the pillars:
- Continuous Integration: Establish a consistent and automated way to build, package, and test applications.
- Continuous Deployment: Fast and continuous release of new software or service releases.
- Continuous feedback: Frequent feedback from teams involved in all phases of the software or service life cycle.
As DevOps is intended to be a functional inter-working mode instead of a single DevOps tool, there are sets (or "tool chain") of various tools. These tools are expected to fit into one or more of the following categories reflected in key aspects of the system development and delivery process:
- Coding - development and revision of code, source code management tools, merge code;
- Compilation - Continuous Integration Tools, Build State;
- Testing - Continuous testing tools that provide feedback on business risks;
- Package - artifact repository, application pre-deployment stage;
- Release - change management, release approvals, release automation;
- Configuration - Infrastructure configuration and management, Infrastructure as Code tools;
- Monitoring - application performance monitoring, end user experience.
Continuous integration with automated tools brings several benefits. First is that teamwork generates fewer errors, lowers risk by how the system is integrated continuously and rapidly, errors are also detected at the same speed.
Bugs in this format do not accumulate, not generating general problems in the system, because instead of taking a day or a week, the error is detected in hours. For even the developer testing in the coding, when integrating, errors can arise and the sooner the errors are detected, the sooner they will be corrected.