Eulogy of Continuous Integration

As Roost unveils continuous readiness, it is time to say good bye to continuous integration but also to celebrate the life of continuous integration as we knew it.

Continuous readiness heralded by Roost will be known as Continuous Integration 2.0.

I knew continuous integration since its early childhood. 


The Childhood Days

When I was working at a large bank in San Francisco in 2004, I learnt about continuous integration (CI) for the first-time. CruiseControl which was born in 2001, was the only CI tool available at that time so it was adopted by my team. CruiseControl was  that backlog was maintained as a spreadsheet. The birth of continuous integration was heavily influenced by the leading frameworks of those days like scrum and extreme programming (XP). Both merged with and became key part of the larger agile framework. 

Around the same time, Hudson project was created in Sun Microsystems. Hudson slowly gained popularity and when Oracle acquired Sun it was already a popular project. Hudson team split and Jenkins was created. Jenkins unseated Hudson and  today not many developers even remember Hudson.

Those were also the days of 3-tier architecture. Struts framework was gaining popularity with the invention of the front-controller pattern. Front-controller essentially was an improvisation on mvc framework. In MVC there was one large controller which in front-controller got divided into a front-controller facade layer and business tier right behind it. Today’s application-tier gateways and reverse-proxies can trace their origin to the front-controller pattern.


Time Check

We are now in late 2021 and CI has essentially remained the same since 2004

It is very interesting that most of the companion technologies of the CI have evolved, yet the CI process itself is still very much the same as it was in 2004.

I am not going to do a critique on Jenkins (and in turn the CI as we know it) feature-wise (there is enough material online that discusses this topic). CI has accomplished a lot and it was the right approach for the time.

What I am going to propose is a novel approach to look at the whole concept of production readiness. 


The SDLC of Pre-Cloud World

development → test → integration → staging → production

The software development life cycle (SDLC) was conventionally understood as development → test → integration testing → staging → production. This process was reminiscent of the Waterfall era. The agile framework which replaced waterfall has been very transformative but was not able to shrink this cycle. Agile did the groundwork by transforming the teams.


Siloed Teams --> 2-pizza team --> Fusion Team


Agile broke the siloed teams slowly and steadily. First target were QA teams which slowly became both empowered and part of the development team as quality engineering teams or QE teams. Second were production support teams which got morphed into SRE teams.  

The transformation was not limited to software teams but also happened in infrastructure & operations (I&O) teams. The trigger for transformation in I&O was cloud adoption which forced traditional IT to rethink their approach. Due to cloud migration, the responsibilities for managing cloud infrastructure and application infrastructure got divided. While CloudOps teams got the responsibility of dealing with enterprise wide cloud strategy and infrastructure, DevOps teams were created to focus on the application specific infrastructure & operations. 

The story of transformation would not be complete without dividing application infrastructure and operations. While platform teams take care of application infrastructure, SR teams are responsible for operations. 












While everything got transformed, the parts of SDLC remained the same and led to most of the challenges software delivery teams face today. To fit a square peg in a round hole, power was taken away from developers (who actually know what they are building) and more and more tooling was introduced in the release pipeline. 


The SDLC for Cloud-Native World

The only three stages needed for cloud-native workloads are:

development → pre-production → production

After development applications go through change validation process (with leading platforms like Roost). Sharable and disposable pre-production environment is created on demand and pre-validated applications go through the final stage of validation and certification. This process eliminates changes failure no matter how many changes are done in parallel. 


Figure 1. Three-stage Process for the SDLC 


GoogleAd-728x90 Build Faster

Sign up today for trial of the Roost platform at no cost and commitment.



See how Roost simplifies the SDLC to a three stage process!
Laptop-DemoVideo 500

Roost provides a sharable, disposable pre-production environment where developers can test with live services to test that their code/services changes work together prior to release.



Like this information? Share it:

You may also want to review these recent posts.

Create a Multi-node Production-like Kubernetes Development Environment
Create a Multi-node Production-like Kubernetes Development Environment
25 October, 2021

How you can run and test containerized applications on a local systems. For Developers to run and test their containeriz...

How to Validate the Interoperability of Microservices in Development
How to Validate the Interoperability of Microservices in Development
26 October, 2021

Learn how validating the interoperability of the microservices in development avoids service integration issues prior to...

New & Unique Way to do CI so Code Changes are Always Production-Ready
New & Unique Way to do CI so Code Changes are Always Production-Ready
15 November, 2021

What is the primary purpose of continuous integration (CI)? The primary purpose of CI is to integrate code/service chang...