Continuous Integration (CI) is the process of integrating code changes from multiple contributors to create a single software project.
Not a real-world example of Continuous Integration
Take a theoretical example of a production line making teddy bears. The designers (developers) though have very little idea about what one looks like. They will code the machines to create the end product; the machine operators then run the production.
So, the first iteration may well look like this:
First iteration
Not great. The designers, sometimes different from before, make their changes and apply them to the machines. The operators then run the next batch:
Second attempt
A little better, but still not ideal. Next! After a few more iterations, we end up with:
Finally, a teddy bear
The factory originally started with bears, but using the same methodology as above, they can produce any number of different plush toys. The bonus is that any changes to that line (for example, giraffes) do not affect the bears or anything else. As we can see, gradual improvements have a long-term positive effect.
More success
In this example, the operators have been working closely with the designers and better understand the design process. In the other direction, the designers learn more about the operation processes. Everybody wins!
And the designers finally went a step too far.
Not a teddy bear
A real-world example of Continuous Integration
In effect, CI is being able to reconfigure machines on the production line rapidly in order to produce custom-made products. Continuous Integration increases the delivery rate of code, has an inbuilt quality assurance mechanism for checking the quality of code, and can adapt rapidly to client requests.
These processes lie at the heart of DevOps, where the developers have far more control over the environment in which their code runs. In a way, it is as if they were in charge of both the product and the production line itself. It also avoids the frequent challenge of code integration and allows bugs to be caught earlier.
Continuous Integration is an agile methodology - a fast-moving environment that is client-driven and strongly collaborative - and is usually partnered with the Continuous Delivery concept to provide what is known as the CI/CD pipeline.
Below, I explain the baseline approach, discuss the strengths and weaknesses of various CI tools, and finish with some recommendations.
The baseline
These diagrams show the process flow and implementation:
They show that Continuous Integration does not exist as a standalone concept. It requires continuous testing to validate both the quality of the code and the benefits from automation for the implementation phase. This phase packages all of the components together (for example, database scripts, Javascript, Java code, static web server files), and also allows performance tests to give feedback for the developers. These tests are also aggregated to provide what is known as a regression test for the entire application. This will be followed by testing performance, security, interface, and other forms of automated tests.
Continuous Integration is based on the idea that teams of programmers who make frequent releases involving small changes to code produce reliable and easily debugged output.
Code changes can be as frequent as the team wishes, with intervals usually ranging between a few hours and a day. This avoids the production of monolithic blocks of code. The approach is flexible and fast-moving but may not be optimal for every business application. Also, it helps to limit the volume of features being developed concurrently.
It is essential that the business needs are aligned both with the development and clearly defined acceptance criteria.
It is important to note that CI/CD can be managed under a project management framework such as Prince2, and the supervision of the operations and development elements can use the ITIL 4 and COBIT 5 frameworks respectively. All three frameworks use the concept of continuous improvement.
A CI/CD tool will be used for automation of the process steps and provide reporting. Some of the more popular tools for this are Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI, and Hudson. Each one will have plug-ins for support integration with third-party platforms, user interface, administration, source code management, and build management.
The CI/CD approach requires development teams and operational teams to collaborate on technologies, practices, and priorities. Teams need to develop consensus on the right approaches for their business and technologies so that once CI/CD is in place the team is on board with following practices consistently.
Comparison of different CI software
This document will try to make comparisons of several CI software offerings using the following criteria:
- User scope (single-user to enterprise).
- Price (open-source, licensing, per-socket, per-core, support contracts).
- Environmental factors (server, cloud, development language(s), OS).
- Strength and weaknesses.
- Best-use scenarios.
The CI software that will be examined are:
A review
Bamboo is widely used in aerospace research and as an element in the greater software stack, although it integrates better with other products from the same vendor. It should be noted that Atlassian Corporation has a reputation for providing very capable software at the cost of tremendous complexity and this is reflected in many of the product reviews.
CircleCI is widely used in IT businesses (service providers, software developers). It is generally praised for its ease of use and simple setup (it is hosted on the CircleCI cloud). This can lead, however, to outages due to the off-site nature of the product, and the user interface (UI) can be unreliable and support seems to be variable.
Hudson was absorbed by Oracle when they purchased Sun Microsystems in 2010. They copyrighted the name “Hudson” in an attempt to monetize the product, which led to the majority of the developers continuing the project independently, renaming it “Jenkins”. Interest in Hudson collapsed and the product was declared obsolete in early 2017.
Jenkins is a widely-used product and as such is implemented over a wide spectrum of industries. The primary developer of Hudson now supports Jenkins and Hudson is seen as the fork (development branch) of Jenkins. Because of its widespread support, there are many plugins available for Jenkins, and it can be integrated with almost any platform. It is also freeware. However, as it is locally hosted, the benefits of using a cloud provider are absent, and the UI is beginning to look a little outdated.
UrbanCode Build is used by a wide range of industries (though I have a feeling that quite a lot of them were existing IBM clients). IBM purchased UrbanCode in 2013 and now uses the typically opaque IBM pricing model. It is flexible and platform-agnostic, and its UI is clear and informative. The downside is that it is a little weak with configuration information. And – ironically enough – the IBM Z support has some catching up to do.
Conclusion
The CI/CD process is both flexible and fast, allowing developers to improve and deliver their code in a short timeframe and simplify implementation by the operations group. The methodology used is identical for all of the different software used, with some minor differences in terminology.
It also helps to decrease the separation between the developers and the operations group, enabling greater cooperation. CI/CD can be easily managed using standard frameworks such as Prince2.
So, while it may not be applicable in certain situations, CI/CD is a powerful and rapid development methodology for many organisations.
Further reading:
The Internet of Risky Things by Akram Mohammed
Images:
Canva
Hello, great article. Can you tell me how the Artificial Intelligence AI can influencer the CI?
Thank you very much.