Agile in small steps #3: The one step release build

Posted on April 19th, 2007 in Agile, Agile in small steps by siddharta || No Comment

This post is part of the Agile in small steps series. For a complete list of posts in this series, click here.

Is this how you currently make a release?

  1. Check out code from version control
  2. Execute the build script for each module
  3. Execute a script to integrate all the modules
  4. Execute a program to create an installer
  5. Execute a script to create a CD image/Package the files into an exe/jar/war/…
  6. Copy the built code to another machine/Hand over the built code to QA
  7. Install/Deploy the application
  8. Test the application
  9. Release the application

Wouldn’t it be better if you could do something like this instead:

  1. Execute release script

Impossible? Not so. The technique is to take it one step at a time.

Start out with a script that just checks out code from version control. Most build tool like ant have support for a variety of version control systems. Most version control systems have a command line interface, so even if your build tool does not have version control integration, you can write a script to execute the appropriate command. For instance, I use a python script to perform my builds.

Once that is done, add each step one by one. So the next step would be to create a script that will build your code base. Then add a line in your main build script to call this build script.

Next, make your unit tests execute from the command line. Then add that into your main build.

Keep going like this one step at a time and pretty soon you will have a one step release build.

If you are working on a standard platform, like Java for instance, you can use tools like ant which will integrate with a whole lot of standard build components like JUnit, other ant scripts and the like. Sometimes you are not working on such a system in which case you will need to do a bit more work to integrate everything.

Here is what my build system for Silver Catalyst does:

  1. Copies the python application data, template files, javascript files to the appropriate locations
  2. Compresses the javascript files to be smaller
  3. Compiles the plugin code and copies the compiled plugin code to the plugin folder
  4. Copies the default database and license keys
  5. Runs the python unit tests and generates a coverage report
  6. Runs the javascript unit tests
  7. Combines the application module, framework module, embedded server and database into a single executable
  8. Runs the install program to package everything into a single installer

It is still not complete. On the To do list:

  1. Check out fresh code from the repository at the start
  2. Accept the version number as a parameter and replace it in all the documents, code and installer
  3. After the build is done, tag the repository

The advantages of a one step release build are

  1. Easy to make releases: If you are going to be making frequent releases, then this is very important. You do not want to be spending two days on a release when you are on a two week (10 day) release cycle.
  2. Less chance of human error: This is again very common. Before automating the release, there were always situations where you forgot to put in the documentation or missed a configuration file. An automated release eliminates this error.
  3. You can make a release from the command line: I’ll talk about continuous integration in a future post where this point will play an important role

Further reading

  1. The daily build
  2. The ten minute build

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

Leave a Reply