Dev Theory – CI/CD Pipeline 101

Think inside the block!

Dev Theory – CI/CD Pipeline 101

No (still relevant) Software Stays at Version 1.0.0

Recently a mentor of mine posted an article about how creating software is an iterative process (you can read it here), where products are released and then constantly improved. Software goes through many changes in its life cycle, and there is always room for improvement. Imagine what Amazon or Facebook would look like if everything stayed at Version 1! Any modern developer needs a way to quickly and efficiently build, test, and deploy changes to code while keeping production environments secure and stable. There are several ways to push code out at a high-velocity, but a very common approach is through a CI/CD pipeline. So what exactly is that? And how can we apply some DevOps to get there?

CI/CD

Continuous Integration and Continuous Delivery/Deployment is a group of software development practices that build upon each other with the goal of automating and improving the deployment process. They all focus on small, very frequent commits to a common repository, as well as automating building and testing.

Some key goals of CI/CD are:

  • Find and address bugs quickly
  • Shorten the time it takes to push an update
  • Improve the quality of software and code
  • Increase developer productivity by eliminating rework

To start we begin with automating the build and unit tests….


Continuous Integration – The Foundation

 

A diagram of a continuous integration system

Continuous Integration is the starting point for any team of developers that want to begin building a CI/CD pipeline. CI requires the developers to make frequent commits to a central repository( by frequent, I mean very frequent – often more than once a day), and to merge them to a release branch. Once a change is merged, a build management system is triggered. The build management system will build the application and start running some basic unit tests. This gives the developers a chance to catch errors sooner, and avoid spending extra time trying to rework changes so that they integrate with everyone else’s new code. After the build management system accepts a change, things can be moved on to staging manually and eventually pushed to production.

“To successfully implement continuous delivery, you need to change the culture of how an entire organization views software development efforts.” –Tommy Tynjä


Continuous Delivery – Automate!

 

 

A diagram of a continuous delivery system

 

Continuous Delivery takes the automation one step further, automating the staging phase and more testing. The staging environment needs to emulate the real world (production stack), and more tests (quality control and load testing for example) run on the changes. At this point, the entire process should be automated and developers should hopefully always have a deployment-ready build on hand. A developer than can take that build and manually push it out into the world for the end-users. All this automation allows programmers and devs to be more productive, write better code, and deliver quality updates faster.

 


Continuous Deployment – Automate Everything!

A diagram of a continuous development system

At this point, our development team in the diagram automated the process up until pushing to production. Why not automate that as well? Continuous Deployment takes this automation a step further, and automatically pushes the new build out to production. This lets the team get feedback from the end user quickly, and creates a perfect environment for quick and effective coding. It streamlines the entire process, so that changes (if they pass through all the testing we hope the team thoughtfully set up) get to the end user quickly and automatically.

So let’s start writing systems instead of just software! Hooray for DevOps!

 

Leave a Reply

Your email address will not be published. Required fields are marked *