“Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.”
While the definition above represents a general understanding of continuous integration in association with enterprise development, as a practical matter, where does the rubber hit the road? In order to clearly understand this question one must first take a short walk down memory lane.
In 1994, noted American software engineer, and former Rational Software guru Grady Booch, proposed a central-integration model that consequently became known as the “Booch Method.” Its goal was to streamline the end-to-end production chain by suggesting the regular consolidation of multiple developer working copies within a common code base.
Booch’s theoretical model was generally accepted as being the first iteration of object oriented analysis and design (OOAD), and by 1997, the CI construct was directly applied by Kent Beck and Ron Jeffries while working on Chrysler’s ‘Comprehensive Compensation System’. Their work refined Booch’s model further by establishing a practical process doctrine that they called “Extreme Programming” (XP).
As a consequence, similar evolved CI process models have been created and subsumed accordingly, including what we now refer to as the DevOps methodology.
Why CI works:
In simple terms, continuous integration eliminates lag time between the commit phase and the practical build process when executing a systems development process. This allows multiple developers to leverage significant time advantages within a common code repository, by clearly identifying, understanding and fixing errors as they appear, rather than having to execute re-dos down the road.
As one might expect the most direct impact of CI represents an overall reduction in production time. But at a micro-business level, the model also reduces resource costs throughout the development chain; along with the creation of positive direct, and in-direct, budgetary effects throughout QA, and on the Ops side when considering a traditional build organization.
These are the central value points for manual CI:
- – Errors are largely detected early
- – Errors are simpler to track and resolve
- – Detect and resolve processes avoid release date crashes
- – If an error occurs development teams can immediately revert to a previous error-free codebase
- – Real-time versions can always be utilized for affiliate testing, or even product release if needed
- – Code reviews force development teams to produce modular, simpler code throughout
However, in today’s world where automated scripts are the norm, rather than the exception, CI also allows for value-adds in the form of continuous autonomous test regimes that create:
Rules-based discipline throughout the
Real-time feedback system-wide, even in the case of localized alterations
The construct applies rigorous metrics derived by data points associated with codebase universality leading to reduced complexity
However, these same operating values are multiplied, or tripled in terms of cost efficiency when applied as part of a DevOps evolution, since in the event, not only is the overall development model thinner; the management process is equally lean.
DevOps as CI; and vice versa:
As asserted earlier, the core values of CI are largely driven by a practical need for collaborative action directed toward a common code base. However, once a product is built, CI’s value doesn’t have to end there.
In the case of DevOps specifically, since the methodology essentially eliminates cultural obstacles by blending Development, QA and Ops management disciplines leading to larger, and more cohesive systems frameworks; once an enterprise devops mentoring or coaching evolution is conducted, applied teams quickly learn to appreciate just how CI behaves, particularly when it comes to the next step; rapid product ‘delivery.’
In this case, CI builds are intrinsically quality-assured prior to a build phase, post-build testing is usually trouble-free, and if there are any errors, tweaks can be handled quickly and efficiently. This means that once a product is delivered to the constituent, the CI process can, then, loop back on itself by affording further seamless updates as desired.
As a developer suggested recently, ‘you can update hourly if you need too’ although as a general rule, that particular approach would not apply at an enterprise level. Nevertheless, the point is simple CI accommodates DevOps as easily as DevOps accommodates CI, thereby creating a streamlined set of values that virtually any business operation can take advantage of
