You have multiple build scripts that contain parts that execute the same set of complicated actions, differing only by path names, files names or other values used in the script. Changing these actions among many scripts is a big hassle (a.k.a “Shotgun Surgery”).
Your build scripts are breaking the DRY rule. Don’t repeat yourself.
Extract the common set of actions into a new short build script, that receives as parameters, or environment variables the values that different between the various scripts. Then have the other scripts call the new script with the correct parameter values.
In one of my projects, as part of the deployment of a site, I also wanted to add a set of actions that makes sure the initial web page of the site was up after deploy. if not, the build should fail. It turns out that sometimes it takes the server a few seconds after reset or file change to get back to working shape, and meanwhile it returns various different codes like 403. So the script had to do the following:
- get the web page or response and write it to a file
- read the file result into a variable
- if result was 404 or unknown to break the build
- if the result was 403 then continue looping
- wait one second
- if the result contained the right text $text_to_find then build passes
This set of actions was needed when deploying to the test server, staging server, and production server.
I extracted only these actions to a new script named “check"_site” and made the deploy scripts (there were different deploy scripts for production and test) execute the check_site script as part of their work.
Possible Side Effects
you might end up with many small scripts, without knowing in which order they are supposed to be executed. To mitigate this you might want to only have one MAIN script call all the other scripts, instead of various small sub scripts calling other sub scripts. If only one main script is in charge of sub script call flow, the build can be readable by looking at the main build script.