Kubernetes Tip: Is CI/CD Really Popular?.
I was reading a post, where someone posted this question. I wanted to check with Tailwinds customers if they really perform CI/CD. Some really interesting answers that I would like to share here.
But before getting onto the details, few definitions and disclaimers.
I don’t really want to get into the discussion of the agile vs waterfall model. IMO, organizations follow a process that they believe is right for them based on their business needs and the culture of the organization.
These days, organizations typically plan a sprint for 4 weeks (have observed 2 weeks as well in a few cases). Each sprint has many stories, and each story has many tasks.
Strictly speaking, CI/CD means, when the developer checks in the code, it automatically gets integrated into the repository and gets’s deployed into production seamlessly.
Deployment Spectrum.
As Figure-1 says it all, there are two ends of the deployment spectrum, they are task-based and Sprint based. There are many shades between these two such as story-based etc.
Note: Hot-Fixes are exceptions, where they are deployed immediately and don’t conform to deployment pattern.
Sprint-Based Deployment.
In this kind of model, deployment to production occurs at the end of the sprint cycle. If the sprint has many stories, All these stories end up in production at one shot.
From what we have known, many large organizations follow this process where their typical sprint cycle has been 4 weeks. There are pros & cons to this approach but most businesses choose the model from a purely business and cultural perspective.
In a sprint-based approach, customers deploy once every 4 weeks or end of their sprint cycle. So, strictly speaking, I would not classify them as CI/CD in real terms but in a very tightly controlled environment.
Story-Based Deployment.
In this model, deployment to production is based on a story. A story is typically a feature. Once the story is completed, it ends up in production. A story has many tasks associated with it. The task includes development, testing, integration tasks, etc.
Given that it is story-based, one story does not block the other. Therefore, as and when a story is completed, it gets deployed to production.
In a story-based approach, customers tend to deploy a few times a week. Again, would not classify them as a typical CI/CD but this model is closer to CI/CD and less controlled when compared to the sprint-based approach.
Task-Based Deployment.
In this model, deployment to production occurs when a task is completed. Most times the testing is done in the production itself.
These types of organizations are culturally very different and have great confidence in their engineers and make sure the speed of innovation is not hampered due to slowness of deployment. Additionally, the organizations set guardrails in form of SLOs to make sure someone does not break them often with an eye on the reliability of the system.
Customers typically deploy a few times a day in a task-based model. This I would classify as real CI/CD.
Conclusion.
IMO, If one deploys a task-based approach that's when one is doing real CI/CD but should be noted that CI/CD need not be the best and right model for one’s organization, the kind of deployment model purely depends on the business needs and culture of the organization.
There is always a healthy tension between innovation vs reliability. If the frequency of deployment is high, the speed of innovation is possibly high but there is a question on reliability and vice-versa is also true. Organizations will have to find the right balance between these two vectors using methods like SLO etc.
Most Tailwinds customers' do a story-based deployment. What does your organization follow?. Leave a comment below.
