Using CI/CD/CD for Software Lifecycle Automation - DevOps Series, Part 8

If you have been following my DevOps blog series, you know how developers work in their local environment, and how operations teams manage application deployments on public Cloud and on-premises environments.

As we’ve discussed, there are many different scenarios where each of the options might apply. Let’s just think about one as an example, where we might have three different environments:

Development: local laptops
Quality Assurance (or Testing): on-premises
Production: public Cloud provider

CI/CD/CD Addresses Problem of Error-prone Manual Processes

The way we have been working until now is quite manual. Developers work on source code on their laptops. They create new Docker images, deploy them locally for testing to make sure application new features work as expected, and finally publish those images to share with other teams. Operations then will pick those images and update application deployments on Kubernetes clusters (Cloud or on-prem).

Each one of these is a manual step that involves actions from individuals in multiple teams, so it is quite prone to error. The whole process of moving code from one environment to the next one would greatly benefit from being automated, so that there is minimal human intervention required.

This specific and important concern is what continuous integration, delivery and deployment (aka CI/CD/CD) tries to address.

New Learning Lab Let’s You See Automation Working on Your Own Software

In my new Learning Lab we will cover all aspects on what CI/CD/CD is, and what are the benefits it brings to different teams. Then we will discuss the required infrastructure to implement it, deploy all required elements in our own setup, and integrate them. Once everything is ready we will put it to work by creating a pipeline for our modern, microservices-based example application. This way you will see automation working on your own software changes, and what are the real benefits it brings.