One of the most frustrating feelings for a developer is to have worked hard on a particular piece of code, only to submit it and then have to dodge curses and thrown objects from your teammates as it breaks the build. Continuous integration (CI) was devised as a way to avoid this problem, allowing programmers to work on code in isolation without risking the integrity of the core build every time a new piece of code is introduced.
This is achieved by having a project's codebase stored in a single repository, which the whole development team submits to. When a developer wants to work on the code, a copy is created so they can work in isolation, with modifications uploaded to the repository as 'commits'.
Automated systems then check these commits at the point of upload, validating them for errors and ensuring that the modifications do not break the sanitised codebase stored in the repository. Any commits containing errors or found to create conflicts in the main repository will be rejected. If a commit passes, the main repository will be updated to reflect the changes.
Another tenant of CI is robust version control, meaning any repository should allow for versions to be rolled back to a stable state if unexpected conflicts arise. Perhaps the best example of this in action is the GitHub repository.
Developer teams operating under CI often update their repositories dozens, if not hundreds, of times each day. This means workflows generally produce much faster deployments with fewer errors. Often the alternative is to wait weeks to integrate code, during which time duplications can occur or a change in strategy.
Verify, find, fix
Given that the repository creates a copy as part of the development process, each developer can work in isolation without disrupting the rest of the team – a major advantage of this type of approach. If any errors are spotted during this time, the updated copy can simply be added back into the main repository.
However, CI relies on developers adding commits on a regular basis. Given each developer is working on a copy of the repository, failing to integrate commits frequently can result in their work falling drastically out of sync with other developers, compromising the integrity of the main repository.
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.
CI/CD
Continuous integration goes hand-in-hand with continuous delivery, to the point where the two are generally referred to as a pair under the acronym 'CI/CD'. Continuous delivery is similar to continuous integration in a number of ways; it's highly automated and is designed to make development workflows faster and safer.
While CI focuses on automating the creation and maintenance of a central code repository, CD is based on sharing that repository with a wider team and then deploying to production. In continuous delivery models, once code has been successfully committed, tested and validated as part of a build, that build is then automatically shared with the operations team who are responsible for deploying it to production.
This helps speed up the overall pace of updates and releases by removing the need for developers to manually share code with operations and creates a faster and more seamless pipeline between the two functions. For this reason, it's usually a key component of DevOps workflows, and it's rare to see an organisation that has adopted continuous integration without also using continuous delivery.
However, while it is possible to use CI without CD, because continuous delivery relies on the code being automatically tested and validated before it's shared, having continuous integration is prerequisite.
Confusingly, while 'CD' generally refers to continuous delivery, it can also mean continuous deployment, which forms the final phase of the CI/CD pipeline. Once code has been tested, validated and integrated into a code repository, this function automatically deploys it to the application's production environment. This requires no manual checks or approval by operations staff, so relies on confidence that any errors or issues will be picked up as part of the previous automated testing and validation stages.
While this can greatly increase the speed at which updates and new features can be delivered to users, it does involve an element of risk, as any problems which do slip the net of automated testing could end up in live, production versions of the application. However, the flip-side is that it also makes patches and fixes similarly quick to roll out.
CI/CD tools
The ever-growing popularity of the CI/CD methodology has contributed to the development of an array of tools capable of supporting it. A significant number of these have been originally developed as internal tools for enterprises and subsequently released to the community due to the high demand. The majority of these are readily available without any cost in the form of open source software.
While many tools are focused either on continuous integration or continuous delivery, there are some which were created as an attempt to strike a balance between the two. However, many of the most commonly-used tools are interoperable with one another, making it easier for users to construct the perfect toolchain using the ones they're most comfortable with.
One of the oldest and best-known CI/CD tools is Jenkins, which is known for its high level of automation, minimal maintenance, and a GUI for easier operation. Due to high popularity, there are many integrations and plugins created to even further increase its flexibility.
GitLab also provides CI/CD functionality within its offering and has the advantage of providing users with an entire development cycle within one application - from build to deployment. Despite being an open source software, GitLab is mostly targeted towards enterprises and offers increased support and functionality based on a flexible subscription model.
Travis CI was developed around a decade ago and, despite what its name might suggest, handles CI as well as CD functionality. However, it was constructed specifically around Github, meaning that if you are planning to use an alternative code repository, such as Bitbucket or the aforementioned GitLab, you might have to start searching for another tool.
Lastly, there’s CodeShip. This is another CI/CD tool from CloudBees, the main company responsible for maintaining Jenkins. However, unlike Jenkins, CodeShip focuses on simplicity and user-friendliness, facilitating pipeline construction with as little management and maintenance as possible
