By Gologic with the collaboration of Alexandre Couëdelo.
Continuous integration (CI) and Continuous deployment (CD) are the core practices you will need to master in order to achieve a successful DevOps transformation. In this article, you will learn the CI/CD definition and what needs to be done to prepare your organization.
CI/CD definition
The first question we ask ourselves when we talk about these two notions is what is the difference between Continuous delivery and Continuous deployment.
- Continuous deployment is the Holy Graal of DevOps. I mean your entire process is so mature that any code change is fully validated and sent to production automatically. Continuous deployment uses automated testing to validate if changes to a codebase are correct and stable.
- While Continuous integration is the foundation on which everything relies, allowing developers to frequently and reliably make changes to an application and be sure those changes integrate well with the work of others.
To bridge the gap between CI and CD, you will need to equip yourself with several other DevOps practices such as Continuous testing (CT), Continuous delivery (CD), observability, and monitoring.
However, change management is complex. Simply building a CI/CD pipeline by the book is not sufficient to succeed. For your organization to be ready, you need to pave the ground for a real “Dev” and “Ops” collaboration.
On one hand, “Ops” will need to define the proper infrastructure in which the DevOps culture can grow, and on the other hand, “Dev” needs to put in place the fail-fast approach. Finally, you will refine the process by using the Shift Left principle.
Now that we have done a brief reminder of CI/CD definition and difference, you will learn in this article what needs to be done to prepare your organization.
Defining the next Infrastructure
On the operation side, moving the organization towards CI/CD implies redefining the infrastructure. Indeed you need a more collaborative way to operate the production environment.
The success of DevOps comes along with the self-services model. You must have heard of IaaS (Infrastructure as a Services), PaaS (Platform as a Service), SaaS (Software as a Service). These external providers will help your teams build your infrastructure more easily using API and configuration management CI/CD tools.
You also need to build an internal self-services on which the teams can rely to build a new application with sufficient autonomy. Often operation teams will automate and create recipes to fasten software development and delivery process while keeping cost and security under the radar.
Your new infrastructure should look along these lines:
1. Micro-services: manages by development teams “You build it; you run it.”
2. Resources: infrastructure components require by micro-services (ex.: database) are managed by developers based on templates provided by Ops.
3. Shared services: tools used by both Dev and Ops to manage software life cycle (code repository, CI/CD toolchain, monitoring).
4. Platform: a layer of abstraction to facilitate integration and software operation (ex.: Kubernetes).
5. Infrastructure: the bottom of the iceberg with machines and network.
Before you start. Identify what is missing to adopt the self-service model. Evaluate your existing tools and see how to make them better fit in the new model. Challenge your current providers or find new ones that better fit with the targeted model.
Building the feedback loop
On the software engineering side (“Dev”), everything starts with adopting the fail-fast approach. The fail-fast approach requires you to implement validation at every step of the process. If a validation step fails, the teams need to rework the source code until it passes the required criteria. It may be a frustrating transition for those not familiar with the fail-fast approach. Therefore you need to use an iterative process. Automate a small part of the process until it becomes robust and stable. Only then move on to another part of the process.
You always start the journey by implementing continuous integration. Once the teams commit changes to the version control system, the code is compiled, and unit tests are executed. If the code doesn’t meet a quality threshold (code coverage, bug detection, security audit), the teams are alerted, and the code needs to be fixed to move further in the process.
The second step is to put in place the foundation for continuous testing (CT). Only automate critical and repetitive tests with high added value. At this point, it is more important that you simplify the process than implementing tests.
Next improve your monitoring and alerting capabilities. The best way to start is to get notified every time an error occurs during office hours and take time to analyze them. There may be a lot of alerts initially, but in no time, the team will learn to better manage errors in their code, and alerts will become more meaningful.
Finally, keep improving until you are confident enough to deploy into production automatically (Continuous Deployment). To achieve this goal, try to remove the bottlenecks as early as possible. A common strategy is to apply the Shift-Left principle. Automate all those things you used to do at the end and do it as early as possible to reinforce the fail-fast approach.
Wrap up
Continuous Integration (CI) and Continuous Deployment (CD) are a must-have for an organization to achieve fast and reliable software delivery. To succeed there is two things you need to address:
- Bring “Devs” and “Ops” closer by revisiting your architecture and adopting the self-service model.
- Put in place the fail-fast approach and slowly add capabilities to the process until you achieve continuous deployment.
Get expert DevOps advice
Do you want to create your automated software deployment chain and speed up your deliveries? Gologic DevOps advisors can help you set up pipelines as code, including continuous development, integration, testing, delivery and deployment (CI/CD). Explore our continuous delivery automation services or contact us to learn more about our strategic approach.
By Gologic with the collaboration of Alexandre Couëdelo.
