Patterns of Enterprise Deployment: Deploy From Source Control

This is part of the Patterns of Enterprise Deployment series.


DeployFromSourceControl is used when you are wish to create deployed packages only from source controlled code. Normally the pattern will be implemented by a system that will ensure that a known version of the source is obtained – often the latest – and then build into a deployable package. Many levels of sophistication are employed from batch scripts to full-blown event-driven service centres with web front-ends and deep integration with work-tracking project management systems that produce full audit trails.


Medium up to a full life’s work


  • Repeatable
  • if it isn’t in source control then it won’t get built so there is no danger of losing changes when you re-deploy
  • you will, with varying levels of effort, be able to reconstruct any package that you build by examining source control timestamps


  • a fair amount of upfront work
  • slow to react to changes to the architecture of the system; you need to make a second change to the deployment package builder
  • can be slow; developers must check in then wait for the changes to be build from source control

Use when

  • building the deployment package from source control is almost always essential on a serious enterprise project. In any case, this is valuable intellectual property; check it in!

Don’t use

  • When your project is changing so rapidly that you don’t know what it will produce

My experiences

This is a crucial one for any project, but don’t feel that you need to be constrained by the hoary old “build script”. As long as you are only building your deployment packages from something that is in source control you can do anything you like.  One nice twist that I’ve always wanted to try is to use a continous integration system – like CruiseControl.Net – to provide the built artefacts. You know that the stuff is in source control, just that it is a little fresher than normal! If you don’t like this and think that it is too unstable for releasing then you can run the CI build on a very stable branch that you only check into by merging in from the development brnaches.

If you can get a dedicated system for this then when you start integrating with the rest of your development process tools then things really start to look sweet. If you can get the whole TFS stack running well, then Team Build provides a huge amount of integration with work items and changesets/checkins and produces reports for each build in the staging area and means of tagging the build that is ready for deployment.

See also


2 thoughts on “Patterns of Enterprise Deployment: Deploy From Source Control”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s