Continuous Testing

I’ve done a lot of setup and administration of continuous integration servers — cruise control (including variations cruisecontrol.rb and, luntbuild, hudson, jenkins, bamboo, TFS, go. I have my favorites (and not so favorites.)

I’ve seen them used well and abused for continuous delivery and deployment as well.

Ironically, the ones that seem to work best seem to have lots of shell scripts written in text boxes. These are a nightmare to maintain, and impossible to recover from.

They often look like this:

  1. Set a bunch of environment variables in the CI tool
  2. Have a bunch of environment variables set (or overridden) within the job script
  3. Take a few more environment variables as user selected configuration parameters for the job
  4. Do some environment cleanup
  5. And then run the “build script” – a shell script that calls a python script that does a bunch more of the same stuff – and then eventually calls maven or rake
ENV_VAR1=$DEFAULT ENV_VAR2=$FRAMEWORK_DEFAULT /usr/local/bin/custom_shell -ex $OPTION1 $OPTION2

export ENV_VAR3; export ENV_VAR4; export ENV_VAR5</pre>
/usr/bin/python $OPTION1 "hard_coded_value"</pre>

One of the first things I do when starting on a new project is pull these scripts (and their associated environment variable settings) into version control.

And then I delete the jobs and never think about them again. I wish.

But I put them under version control because I don’t want to lose them.

And then I start refactoring.  And then I start trying to rebuild the functionality from scratch.  And then I congratulate the build engineer (who’s probably a developer trying to get work done on a completely different project) on his job security.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s