How I Tuned My CI/CD Pipeline To Be Done in 60 Seconds
A CI/CD Pipeline is one of the key tools software engineers have to produce high quality software. It stands for Continuous Integration (CI) and Continuous Delivery (CD). The idea being that instead of making a bunch of changes to your software and then pulling it all together to test it at the end, you should continuously integrate (test) and release (deploy) your software to find bugs faster.
Like many people, I store my software source code on GitHub. A few years ago I set up a simple CI/CD pipeline in GitHub to build, analyze, and test my web app/web services. It worked fine and since it was the first time I had set up a CI/CD pipeline in GitHub I kept it simple with essentially only one step.
Over time, though, I found myself shying away from making changes to my software. As a developer with ADHD, I sometimes find that I have issues getting things done when there are multiple hurdles involved, and I realized that one of the things that was causing me problems was the fact that my CI/CD pipeline took 5 minutes to run. Every time I wanted to make a change, I would have to code it up and then go make a cup of coffee while I waited for the pipeline to test and deploy the code. I wouldn’t always make it back. Often times I would get distracted.
My first attempt at parallel jobs went a little overboard. I decided to take every step in my Makefile and separate it out into it’s own job. Linting the github yaml? Let’s put it in it’s own job. Linting my CSS for the web site? Yep, let’s put that in it’s own job. Etc. etc.
