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.

 

Pattern: Shipping Skeleton

other names: “Hello World”, Walking Skeleton (based on XP), Tracer Bullet Build,

Problem:

Remember when you had a working product, but you could not ship it, or shipping and deploying it took a long time, or could not be estimated?. By that time, however, your product was too big and your free time was too short to start creating a working automated build and deploy process. As time went on, shipping became even more and more of a nightmarish manual task, and automating it became more and more of a problem.

Now you're at the start of a new project, and you want to avoid all that pain in your new project.

Forces:

You want to avoid the pain of automating the build and deploy cycle. But you also don’t want to spend too much time working on it.

Solution:

Before starting development on the new product, start with a shipping skeleton -- An empty solution with nothing but a “hello world” output, that has the basic automated build and deploy cycle working. You should be able to ship this empty hello world project with the click of a button, in a matter of minutes.

once the shipping skeleton is in place, you can start filling out the product with features, and growing the build scripts in small increments alongside the product.

Basic Shipping Skeleton:

1) A Build script (in source control) for compiling the current source

2) A Continuous Integration Server that has a “CI” build configuration, triggered by code check-in, that invokes build script from the previous bullet (also see Build Script injection for more on this pattern)

3) Another build configuration on the CI server for “Deploy”. This can be either deploy to test, or deploy to production. Usually you want at least a “deploy to test” succeeding before having a “deploy to production” CI build Configuration. This “Deploy to test” gets invoked automatically upon “CI” configuration passing. Later on, as the build process matures, you can change this, but for now, knowing that the product is deployable as soon as possible, while it changes so much, is important for quick feedback cycles.

4) If there isn’t a “Deploy to production”, create it. This deploys the product to a production machine. If it is a web site, it deploys the website to a web server. if it is an installer, it deploys and runs the installer on a machine that will act as a “production” machine. either mimicking a user machine, or or an enterprise machine where the product will be installed. for web servers, make them as real as possible, all the way, even by making them public (although possibly password protected). This gives you the chance to make the web server become real production by the switch of a dns setting.

Summary

By starting with a shipping skeleton, you give yourself several benefits:

• You can ship at will
• Adding features to the build and deploy cycle is a continuous action that takes a few minutes each day, if at all.
• You can receive very quick feedback on features or mockup-features you are building into your product.

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