icon-grim-reaperEulogy of Continuous Integration

As Roost.ai 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 production-like environment are 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. 

Three-stage Process for the SDLC 



Rishi Yadav

About Rishi Yadav

Rishi is the CEO and Co-Founder of Roost and has over two decades of experience in leading enterprise application teams. He is a published author and active blogger.

Please Share this Blog

You may find these blog posts of interest too.

A New Approach to Managing DevOps Pipelines | Replace Test Environment
A New Approach to Managing DevOps Pipelines | Replace Test Environment
November 3, 2021

Replace Rusty DevOps Pipes with Dynamic Pre-production Environments When I bought my home a decade ago, I was asked whet...

How to use Event Framework for Complex Test Environments
How to use Event Framework for Complex Test Environments
November 3, 2021

With the increasing number of services in cloud-native applications and their dependence on various third-party applicat...

Simplify the Management of Kubernetes and Cloud-native Environments
Simplify the Management of Kubernetes and Cloud-native Environments
November 3, 2021

Current DevOps Processes are Slow & Cumbersome Current DevOps pipelines have multiple test environments between deve...