Search The Blog
My Books

New:

My Songs

 

The Art of Unit Testing

Buy PDF or Print book at Manning

Buy on Amazon

Latest Posts
from 5whys.com
Twitter: @RoyOsherove
About this site

TDD in .NET Online Course

TDD and BDD in Ruby Online Course

 

Subscribe!

This site aims to connect all the dots of my online activities - from tools, books blogs and twitter accounts, to upcoming conferences, engagements and user group talks.

« Build Pattern: Gated Commit | Main | Build Pattern: Fill In the Blanks »
Sunday
Jan202013

Build Pattern: Extract Script

This is a variation of Fill in the blanks and will become part of the Builds Book.

Symptoms:

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”).

Problem:

Your build scripts are breaking the DRY rule. Don’t repeat yourself.

Solution

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.

Example:

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:

  • loop
  • 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.

PrintView Printer Friendly Version

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Web Analytics