How to boost your CI/CD pipeline
When developing a web app, continuous integration and deployment services are here to make our lives easier. Normally the pipeline would run your automated tests and if they are successful, create the build and deploy it to the world 🚢.
This is beautiful and works like a charm when your application is really small, but for monoliths with a mixed stack, it’s… not ideal. Think about waiting 40 minutes running tests for a hotfix—this is not a good practice at all. 👎
“Ok, so are you saying I should stop writing tests?” 🙅
Don’t even think about that! There are some ways that we can improve the CI/CD pipeline time while maintaining amazing coverage for the code base 💯.
At Thinkific, our main web app has Jest, RSpec and Cucumber tests running and we use SemaphoreCI as our CI/CD service. Every time we developed something, it used to run all the tests — no matter if you simply changed a bit of Javascript code — and took about 15 minutes to run all the test suites in parallel with an allocated 7 boxes per build.
To improve that, we put a script in place to only run certain test suites considering the extension of the files in the feature branch compared to master:
Semaphore CI has an environment variable called $SEMAPHORE_TRIGGER_SOURCE to indicate the source of the build—that’s pretty handy for playing with scenarios! For context, in our environment when it’s manually triggered, we assume that something went wrong so it runs all the tests.
This can be implemented in any CI/CD service with a few adjustments. If you are using Semaphore, add it in the Configuration Files of your project, call it at the beginning of every job and check the variable to decide if you should run the test, like in the example below:
As result of these changes we implemented, React changes now take 2 minutes to complete the build (as it only runs jest) and also frees up 6 boxes instantly so we’re not blocking other builds. 🚀
Hope you’ve liked this article—don’t forget the 👏.
