Geeks With Blogs
Snowflake Design Because in Architecture the Answer is Usually "It Depends"

In this post I'll begin to talk about getting a build process up and going. I'll cover at a high level a build process that I think works for small to medium size teams, talking about some steps you might want your build process to go through. In the next post I will walk through an implementation of a build process using CCNet/MBUnit/FxCop/StyleCop/MSBuild.

Below you will see a diagram that puts the build process in perspective to how the Development, QA and CM groups might work together. Don't get caught up in the details. The goal of the diagram is really to denote where in the code development/build/deployment process your build lives.

Usually, the Development group checks their code into the source code repository, your build process monitors that repo and determines when it should execute a build. One thing to note is that during a build (not necessary every time you build), your build process may run integration tests and if so, those integration tests may reference a DB server. Once the build completes successfully, it gets archived to a build drop location (Really just a folder on a server). From this location, the CM group takes the build output and deploys it to an environment. If it is the QA environment, QA will use the build output to run their tests and record their test results and any issues that may arise. A lot of this is really conceptual and you may not have either a CM group or as many servers as shown. As I mentioned, don't get caught up in the details.

So your build process is really the gateway to getting something into a deployable format. Along the way, you can also take advantage of your build process and use it to do health checks on your codebase. I won't get into the whole theory of continuous integration ( as there are way too many articles/blogs about that subject and yet another one isn't a great value add. What I will get into is how I accomplish these health checks and other steps as part of the build process. So let's assume for now that you've decided that you do want to do continuous integration and have read about what continuous integration is(

As you probably read, a continuous integration build does the following:

- Compile Code
- Run Unit Tests
- Run Static Code Analysis (FxCop, Symian, StyleCop, NDepend)
- Creates a deployable output
However, I add a couple of other responsibilities to my build process, including version number increasal and labeling. I like to split my build process into two distinct pieces, one that is agnostic to which system is being built and the other that is specific to each system. The reason I do this is because it separates the responsibility of knowing how to compile, which assemblies contain unit tests, which assemblies to run through static code analysis and how to create a deployabe package to each individual system while allowing me to reuse the rest of the code since it is generic to all systems. Lets walk through a sequence of steps needed to complete a build:

1) Create a clean build directory
 - Whether this is running a clean of an existing folder or
 - Doing a checkout
2) Increment build version number
3) Check-in new build version number file
4) Create a branch/label *
5) Checkout branch/label just created *
6) Build system (You'll have to decide if you want to build more than one configuration; i.e. Release & Debug or just one or the other)
 - Build Configuration
  - Clean output directory
  - Place compilation output to a specified location
 - Run Unit Tests (Place reports to a specified location)
 - Run Code Analysis (Place reports to a specified location)
  - FxCop
  - StyleCop
  - etc.
7) Copy build output +
8) Update internal references (Say you are building a common library referenced by other projects. You may want those to be automatically updated whenever your common library is built. Note that updating those projects would kickoff a build of those projects; however, I believe this is good since if you have your unit tests in order, doing a build of those projects will let you know whether or not that project still works with the latest version of the common library).
9) Merge project build artificats (Unit tests and Static code analysis reports)

* Only do these steps for a release candidate build (We'll talk about this when we get into branching strategies)
+ Only do this step for a non-continuous integration build (e.g. nightly build)

Some of these steps will depend on your process and tools (e.g. your branching strategy, whether you're building a Silverlight app, etc.). However, at a 10,000 ft level, you need to get the latest code, increment the version, build it, test it and archive the output.

In the next post, I will go ahead and provide some scripts and detail how I go about creating my CI environments.

Posted on Wednesday, October 6, 2010 10:10 PM | Back to top

Copyright © Carlos Santos | Powered by: