I originally wrote this back in April for the engineering blog of my company at the time. Figured I'd copy it here for visibility (and in case they ever take down that blog lol)
Picture this: the project that you’ve spent a long time working on, put in the hard hours for, and poured your soul into just releasing a new build. Sweet! But now a developer on the project pushed a brand new change and it’s your responsibility to determine if this change is good enough to be deployed to production. Time to pull that branch, open up your favorite terminal, build the application, and run some unit tests… Did they all pass? Time to run some integration tests. Did they all pass? Time to run the end-to-end tests. Oh geez, someone is bothering you on Slack too now, it’s hard to concentrate. Did those tests pass? Should I start preparing this for production deployment? Wow, this is taking a long time! Wouldn’t it be great if there was some way you could get all this done without having to do it manually? Well, I have some great news for you – you could use CI/CD for all of this!
What is CI/CD?
CI/CD (or a pipeline, as it may colloquially be known) is an automated process, or series of processes, that speed up the release of software applications to the end user. Essentially, it is automating all the manual parts of the release process that normally a developer or test engineer (TE) would do. The CI part of CI/CD stands for “Continuous Integration”, which boils down to having an automated process for code changes (often from multiple contributors). The CI will regularly build, test, and merge these changes into a shared repository like GitHub for the whole team. The CD part can stand for one of two things – “Continuous Delivery” or “Continuous Deployment”. There is a slight difference in the meaning of those two phrases. Continuous Delivery refers to a process on top of CI that will automatically have your code changes ready to deploy to an environment such as Test, Dev, UAT, etc. This means that in theory, you could decide to release whenever’s best for the project schedule. Continuous Deployment takes this process one step further by having automated releases to production. In Continuous Deployment, only a failed test or check of some kind will stop the code changes from being deployed to production once the code change is approved & merged.
How can CI/CD benefit a software project, both for Development and QA?
Everyone can benefit from CI/CD, and that’s one of the main reasons that it’s good for everyone to have some experience with it.
For developers, having CI/CD set up can improve the quality of code and the speed at which code reaches product owners and end users. With the build and deployment processes automated, the most recent changes are automatically available to other members of the project team to look at, reducing the time it takes for issues to be found. This means that TEs and product owners can take a look at the deployed version of the codebase sooner than if a developer had to do this manually since the pipeline will run each step automagically and not have to have a person sit there and watch each step until it is done. This also frees up the developer’s time to work on other tasks while the pipeline builds and deploys the changes. In addition, this can reduce the impact of code/merge conflicts since the pipeline should expose any of these issues before allowing code to reach production. Unit test failures and integration test failures in the pipeline will alert the developer early on that there are changes that need to be made to their code before deploying to production.
For the TE team, running automated tests as part of the pipeline reduces the time and effort needed to test the most recent code changes. This free time lets TEs focus on other testing scenarios such as exploratory, performance, and regression testing. It also means that the TE team will have time to write new automated tests that can be added to the pipeline. Additionally, running changes regularly through the pipeline means that TE can isolate failures to certain change sets, making it easier to diagnose and fix issues found with end-to-end automated testing.
There are also benefits to having a CI/CD pipeline that applies to everyone on the project, not just development or QA. One distinct advantage of CI/CD doing all this work for you is that it reduces human error that could otherwise be introduced in the process. At any time during the process of building the app, kicking off tests, and deploying to another environment, a person could make an error – copy/paste, typing the wrong thing, ignoring an error message – that a machine would not. A human can do things differently every time, whereas a computer will do the same thing every time. Another benefit that I touched on earlier is freeing up time that would otherwise be used to do the steps in the CI/CD pipeline manually. Developers would spend more time deploying and running unit tests, and TE would spend more time running end-to-end tests if the pipeline wasn’t there. On top of this, unless they are a miracle worker of some sort, there’s latency in between each step if a person does it, whereas a computer moves between the steps in the process instantaneously. The last benefit I’ll mention is that CI/CD can bring some good collaboration between development, QA, and other members of the project team. TEs and developers get to work together to understand each others’ processes more, which helps make sure that the pipeline is doing everything that is needed. Other members of the project leadership team may also have requirements for the pipeline that they can collaborate with the engineering team on.
How can I get started?
There are several vendors for CI/CD that you can check out, read the documentation for, and start writing. GitHub Actions and Azure DevOps are vendors that work with CI/CD and have good documentation that you can read up on before you start writing. I’ll even give you some sample steps for GitHub Actions.
Once you’re ready to get hands-on with it, you can go to your project in your IDE, create a .github/workflows directory, and add a pipelines.yml (or whatever name you choose) file to get started with GitHub Actions. You can create several .yml files in the directory, named whatever you want, to run the various actions that you want to do. I recommend using a naming convention that makes sense i.e. nightly.yml [for running a nightly build], pr.yml [for running on opened Pull Requests], deploy.yml [for running on deploys], etc. There’s plenty of configuration that goes into your .yml file, but once you have it set up, test it to make sure that it works. The action you take to trigger said pipeline varies by how you set it up (I recommend making it on push for testing so it runs whenever you push code). Once you have it running, you can visit the GitHub page for your project and check the Actions tab to see the runs of your pipeline. (Or you can just follow the Getting Started guide from GitHub themselves 😉).
Now it’s your turn to use what you’ve learned!
Having a solid CI/CD pipeline setup is crucial to delivering a well-made, on-time project with as few defects as possible. Both QA and Development benefit from having a good pipeline on a project, so both sides need to learn about CI/CD and work together to keep the pipeline in tip-top shape. Using CI/CD allows engineers to work on other/more important tasks, ensures human error is kept to a minimum, and gets the code changes out to the stakeholders quicker. Every project should have a CI/CD setup!
Bonus
I asked ChatGPT to write me a few sentences on the importance of CI/CD in a project setting with multiple contributors in the style of a pirate and it had this to say…
“Ahoy matey! CI/CD be the wind in yer sails and the rum in yer cup when it comes to a successful project! Without it, yer ship will be dead in the water, floundering like a fish out of water. With CI/CD, yer code be tested, built, and deployed faster than ye can say “shiver me timbers!” So hoist the Jolly Roger and set a course for smooth sailing with CI/CD!”
Top comments (0)