Qualities of an Agile Build Process
In his article, “Benefits of the Build” [Knoernschild], Kirk Knoernschild discusses the importance of the build process to Extreme Programming environments. Even outside of an XP environment, reliable, reproducible builds can help you to be more effective.
A developer should be able to:
- Easily create a sandbox with the appropriate artifacts for any version of the application
- Build the application using a script (and perhaps with an IDE if appropriate)
- Where applicable, deploy and configure the application to a workspace environment
There are a number of ways that you can achieve these goals.
- To create a workspace:
- Check everything out from a repository location
- Run a script with a target
- To build (and deploy) the application:
- Run a script target
That should pretty much be it. It should be a simple process. There are details in how to get there and we will examine the various Workspace patterns in detail in future articles.
While automating the process steps is important, there is a certain amount of bootstrapping involved. If you can create a workspace, complete with build scripts from your version management system, you still need to tell people what to get out of the version management system. While making the wisdom of how to build the application an oral tradition has a certain amount of quaintness to it, it really isn’t an effective communications tool. One mechanism that has worked for us is to post some basic project setup information in a common place. While a project bulletin board could serve the purpose, an internal web site, or wiki works better. (And you have other information that you need to share that you would post on an intranet anyway right?) This document should contain the essential information to get started, such as:
- Where to find the installer for the version management tool client
- Connection information for the version management server for your project
- The locations of other tools you need to install manually, such as a build tool
- The name of the target to run to set up the client
This should be a short document with only essential information. This document should be in an easy to find place; a URL like: intranet.company.com/ should contain a link to this document.
You may be saying to yourself, “this sounds grand, but I’m a developer and this is a job for release engineers.” Or you may be a release engineer and think that developers needs to responsible for build scripts. While there is some merit to having different roles, we hope that you all realize that you are working on a project, and for it to succeed the goals of all people on the team need to be aligned. So, who’s responsible? You are. Yes, you, the reader of this article. If you are a developer, the build needs to work for you. The build also needs to work for release engineers. If organizational constraints divide ownership of the build scripts in a way that makes change difficult, get everyone who has a role in this in a room and figure out how to make the scripts work better for everyone. In some cases you may need support from management to bootstrap the adoption of a new process.
Even if think that you can get needed management support, you will need to put some effort into explaining the value of this process. You may need to develop a strawman build script yourself to demonstrate the difference. Perhaps you can encourage your management to create a workspace a deploy the application on their computers to understand the pain of the current process, and the value of the proposed new ones. A useful viewpoint to have is: “Do or Do Not, there is no try.” [StarWars] If you have a problem to solve, you need to decide to solve it, or decide not to solve it. Just complaining won’t make things better.