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 new project was a greenfield project, with performance being a requirement of it. I wanted to make use of the readability and performance which can be gained from using ES6 JavaScript. Everything worked during the development and early testing phases of each release cycle, but not so much when the deployment to staging took place. Receiving an e-mail stating "Pipeline failed" at a deployment stage seemed crazy. Issues which had never been seen by me before were suddenly in the code base. What was happening?!

It turned out to be really simple, the deployment to staging ran the "release" gulp job, which did minification of the JavaScript to improve performance. Minification using the gulp-minify module doesn't work with ES6. It either needs to be run through a babel to translate it, or not be ES6. This had not been noticed before as the release build had always worked on the other project, where no ES6 code existed.

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.

If the checks take place after the unit tests, then the JavaScript unit tests may pass as individual files, but they may fail when they are combined in a single file. All these things need to be considered as part of the pipeline, and order of running.

This article was originally posted on my blog at https://www.garybell.co.uk/test-your-deployment-tasks/ on 8th January 2020