Build Automation: LocalBuild #1

I’ve been thinking more about build automation. It needs doing.

In a previous post, I outlined my idea for architecture; splitting monitoring of source control from the piece that actually does the work of building. So there is a piece which automates syncing repositories to your local filesystem (call this RepoSync), and a separate piece which performs builds based on code on the local filesystem, and might do that automatically based on changes detected on the local filesystem (call this LocalBuild).

I’m one guy, so I have to make things like this slowly in my spare time. An iterative approach is really the only feasible route (and how I like to work in any case). Thinking about these two pieces, I think LocalBuild is more useful on its own; in any case, I can simulate RepoSync with CruiseControl.net, which makes it not urgent.

I don’t want to build something abstract, I’d rather pick one of the projects suggested by the use cases in the previous article. I like the look of the tool for consistent building in the development environment. Let’s call it DevBuilder.

DevBuilder Description: The idea is to be able to configure building all projects in a single place, then have a tool that will show you what, if anything, needs building, and which allows you to execute those builds. Automatically firing off builds in the dev environment is probably a very bad idea (seeing as editing files will cause a build to start, no no no).

To configure the local build, you’ll need an editor of some kind. Note: I don’t want a giant hand editted xml file like cruisecontrol.net requires, I want a nice gui editor, which works with a file that might be xml, but need never be hand editted. Anyway, this editor will be needed for all variations of these tools.

To tell you when projects need rebuilding, you need to have some kind of monitoring app running. On reflection a system tray app is a good way to go; it allows there to be a running app, but only when the user is logged in, and running in the context of the current user, which is want you want in development.

The monitoring app will show a red light / green light kind of display. It will contain active monitoring software to monitor the filesystem as defined in the configuration. The monitoring must be persistent; ie: it can’t just tell you when changes are detected as it runs, it must also notice, when started, if changes happened while it wasn’t running. It must then keep track of the changes, showing which projects need building. When the user chooses to build, it must perform the build. It must be able to show the results of the build, and remember whether the previous build was successful or not for the red light / green light display.

The first interesting thing here is the persistent change monitoring.

Thinking ahead, the persistent change monitoring need not just be for filesystems. There’d be a lot of uses if it were pluggable, allowing persistent monitoring of, well, whatever needs monitoring.

Let’s look at the plugin framework for change monitoring this way:
A plugin requires a config (created in editor), and it requires state (initially null).
void Start(state): this looks at the config, the state, the environment (eg: filesystem), and decides whether there is some difference between the environment and the previous environment represented by the state. It then begins active monitoring to detect any subsequent changes.
state Stop(): this stops active monitoring, and returns a state, representing the last observed environmental state (this will be input to the start() method in the future).
bool ChangesOutstanding(): returns whether there have been changes detected
object ChangeDetails(): returns plugin specific information on the actual changes which have occurred.
state UpdateState(): Updates the state in the plugin to what is correct for now, and returns that state. This is how you register that changes have been noticed. (is this needed?)

The persistent filesystem monitor would need a mechanism for looking at the filesystem and creating a table of hashes or some such, which is the state. It needs to be able to compare two states and figure out what has changed. It will use the FileSystemWatcher in .net to notice changes in an active manner.

urgh I’ve run out of steam tonight. This will continue.

About these ads