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: Shipping Skeleton | Main | When they tell me I have to use MSBuild to automate our CI Process »
Sunday
Dec302012

Build Patterns: Script Injection

I am slowly realizing that perhaps my concepts for the build book could be better serving as reusable patterns for creating builds, solving specific problems.

This is a test to see how well this idea holds up in reality. If you like it, and especially if you do NOT like it, please let me know in the comments why, and how you would change it.

I think this is a topic that can be of great use to many people. If we frame it right, it can be more easily distributed and understood.

I am not even sure if the sections below are what I would “need” for a pattern of sorts.

Pattern: Script Injection

Problem:

You have a continuous integration process running nicely, but sometimes you need to be able to build older versions of your product. Unfortunately, in older versions of your product in source control, the structure of files is different than the one that your build actions are set up to use. For example, a set of directories that exists in the latest version in source control, and is used in deployment, does not exist in the source control version from 3 months ago. So your build fails because it expects certain files or directories to be there, which did not exist in that source control version.

Forces:

You want the set of automated actions in your build to match exactly the current version and structure of your product files in source control.

Solution:

Separate your build script actions into two parts:

  • The CI side script, which lives in the continuous integration system.
  • The source control side script.

 

Source control side script

one or more script files that are inside the file structure of your product in source control. These scripts change based on the current product version. It is important that this is the same branch that is used within the CI system to build the product, so that the CI side scripts have access to the source control side scripts.

Developers should have full access to the source control side scripts.

Source Control side scripts contain the knowledge about the current structure of the files, and which actions are relevant for the current product version. So they get to be changed with every product version. They will usually use relative path because they will be executed by CI side scripts on a remote build server.

CI Side Scripts/Actions

These actions act as very simple “dumb” agents. They get the latest version of the source control scripts (and possibly all other product files if needed), and trigger the build scripts as a command line action.

 

Summary

By separating the version aware knowledge to a script inside source control, and triggering it via a CI side script that contains only parameters and other “context” data to invoke the source control scripts correctly, we “inject” the version aware knowledge of what the build script should do, into a higher level CI process trigger, that does not care about product file structure, but still gives us the advantages with had before with a CI process.

 

Thoughts? Comments? Does this make sense to you? is it the stupidest thing ever?

Does the fact that I now wear glasses help in any way?

PrintView Printer Friendly Version

Reader Comments (1)

Your build scripts should always be in your VCS as they are obviusly tighty coupled. You must be able to invoke the same scripts to build locally as your CI system does or you're not building the same thing that you're deploying. This also means that debugging the build process is the same as any other sort of debugging - the only difference is the actor invoking the script.

What I don't get is what "injection" is going on. Your CI process (which could just be a scheduled task) just runs a script in a fixed location within a view/working copy. If your CI service can also create the view on-the-fly that's better, but I still don't see any "injection" going on.

January 8, 2013 | Unregistered CommenterChris Oldwood

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