The Continuous Integration (CI) concept has been around for well over 15 years now. Agile teams have been successfully implementing this approach with CruiseControl, Build Forge, Jenkins, Bamboo, and other CI software. The idea is great, but the popular implementations have a major flaw – the integration isn’t truly continuous. I would call them Continuous Sporadic Integration systems. Let me explain, and share an alternative approach – Reactive CI. A typical CI system performs two functions. It periodically polls the source control repository and determines if new code changes have been committed for a specific project. When new commits are detected, it runs a build script to ensure that the new code compiles, passes unit and integration tests, complies with the coding standards, or doesn’t break the build in any other way. The code changes that caused the build to run are captured, so if the build fails, it is obvious what changes broke it. Since source control systems record which user committed each change, it’s also possible to quickly identify the developer who introduced the build breaking code and have them fix it as soon as possible. The goal is to integrate small changes, one at a time. Ideally, if change is atomic, which automatically means authored by a single developer, problems can be identified and addressed as soon as they occur. This leads to high development velocity while the codebase remains working at all times. Sounds awesome! Except, of course, we don’t live in an ideal world. While in many cases this schema works like a charm, in many others it doesn’t. Let me state this right off the bat: The CI systems widely used in the industry today are only pseudo-continuous. A couple of conditions must be met for the process to seem continuous:
With a small, modest-sized project, satisfying these requirements is not hard. However, for larger projects that contain hundreds or thousands of files, it is increasingly more difficult.
The bottom line is: the CI tools currently available work well on small and medium-size projects and teams. Implementing CI for large-scale projects using these tools may be more than challenging because of the underlying sporadic polling schema. A Solution: Reactive Continuous IntegrationThe solution to this dilemma could be very simple in principal. What if instead of having the CI system poll the source code repository for changes, the source code repository notified the CI system when a build should be run based on the new code being committed? At HCL we call it Reactive Continuous Integration. The implementation of the add-on Reactive CI service for ClearCase is currently under development and will be available later this year. Here is how it works:
This approach closes two major gaps in the current CI implementations:
Reactive CI makes it possible for the large system development projects to implement Continuous Integration instead of being stuck with the nightly builds. And with it, the system development organizations can become more Agile and adoptive of DevOps. Continuous Integration is the approach that allows software and system development organization to accelerate innovation and delivery of products and services to market. What we design and build constantly changes, so the methodology and tools must evolve along the way. Continuous Integration is no exception. How do you achieve CI in your organization? Please share your challenges and success stories below. I look forward to your thoughts and comments. Alex Seriy ClearCase/ClearQuest Technical Specialist alex.seriy@hcl.com https://www.linkedin.com/in/alexseriy https://twitter.com/AlexSeriy
0 Comments
Leave a Reply. |
Archives
November 2019
CategoriesHelpful Links
Open RFEs Knowledge Center IBM Marketplace
|