The great part of a CI/CD pipeline is the headache which can be removed from deployments. Manual deployments are painful, but deployments as a whole don't need to be. Automating deployments is a great way to avoid human error, and to be able to deploy with consistent results.
The trouble is, what works on one project might not translate fully to another. Even with only a small change to the tech stack.
Being a bit of a dinosaur, I started a new project lifting and shifting the Gulp task runner from one project to another to save time. If it ain't broke, don't fix it! But I never checked the full Gulp task ahead of it running as part of the deployment - when it failed!
The lesson I took from this was simple. Check each task which will run later at a non-critical point. I'd rather know early on that the deployment will fail than have my lunch or sleep interrupted by a failed deployment and system down notifications.
Placement of this job in the CI/CD pipeline is a tricky one to work out. How critical is it compared to others? That's a judgement call for each project I think. Personally I put this checking task ahead of all of the long jobs, as I have limited pipeline minutes (on the free Gitlab plan), and would rather fail fast through the jobs than know everything is fine with the code, just to fail at a pre-deployment check.
This article was originally posted on my blog at https://www.garybell.co.uk/test-your-deployment-tasks/ on 8th January 2020
Top comments (0)