TeamCity Pro Tip: Why you should separate your deployment code from your application code

This post is really one of those “summary of best practices” articles that I’ve learned by using TeamCity build server from JetBrains for quite some time now.

In Theory

Below is an image that might be pretty common.

  1. We have an application.
  2. We have some deployment scripts.
  3. We would like to push the application to a destination environment with the help of the deployment scripts.
  4. The application and deployment “teams” work independently and will push code separately.

image

In theory we would like the build configuration (1) to push the latest successful output of (A) to the test environment via the build scripts produced by (B).

In Reality (a.k.a TeamCity)

Below is the same view as I “wished” for in the previous section but with TeamCity.

image

We have implemented three build configurations (A, B, and 1) with the build artifacts they produce shown. The only thing left to-do now is to stitch them all together is the way we wished for.
I’m briefly going to mention some important aspects of build configurations A and B before looking into build configuration 1.

A – Application

The “application” build configuration is the…wait for it…application (a website in this situation) and the tests associated with the application. It will output the web application as a package (zip) as its artifact, which I’ve covered how to setup in a previous post.
note: I’m not going into detail about the build steps in this post. (I’ll leave that for a future post perhaps)

Version Control Settings

image

The application code is basically everything except two folders, source control vice, which I’ve illustrated in the image above.
By default the entire source control tree is included which I don’t want.

image

So, I’ve configured the GIT VC setting to exclude those two folders in question (-:[path] is the syntax).
That also has the benefit of not triggering any new builds for this configuration when code is updated inside the deployment and environment folders.

Build Triggers

image

Speaking if build triggers,  build configuration A uses an OOB VCS trigger which is set to start whenever a change in the VCS is detected (except for those two folders mentioned above).

B – Deployment

The “deployment” build configuration is basically just a couple of deployment scripts inside a folder (deployment). It will simply output is those scripts as its artifacts.

Version Control Settings

image

I’ve configured the VC setting to include only the deployment folder (+:[path] is the syntax). In contrast to excluding folders, –:[path], including folders will limit itself to only that path.

note: see the =>. syntax? That means map to the root of the destination (TC working dir). If I didn’t use that syntax it would map to same path on destination. I only want the files and not the full folder structure. Like this:

image

It kind of “flattens” the structure. You can get more details right here.

Build Triggers

In combination with an OOB VCS trigger (same as A) this has the benefit of “spitting” out new deployment scripts whenever those appear…totally separate from the application itself. That being the actual purpose of this post.

 

1 – Deploy => Test Environment

The “deploy to TEST” build configuration is the first real workflow step (hence the trailing number 1 instead of a letter) that our TeamCity server will execute.
It will use the artifacts of build configurations A+B in correlation with some environment specific configuration to deploy the application to a test environment.

A quick word about the Build Number

image

I’ve covered this in a previous post but just bare in mind that I’m using the same build number as build configuration A. All-in-all I am deploying the application and would like to see that reflected on the dashboard.

Version Control Settings

image

The test environment configuration is stored as three xml-based files that our build script uses (I’ve covered this in a previous post). They live in a folder called Environments and a sub-folder called Test.

image

I’ve configured the VC setting to include only that folder (+:[path] is the syntax) with the same =>. syntax as explained previously.

Build Triggers

image

Here we a couple of options:

  1. Manual Triggering (if the testers want total control when we push)
  2. Automatic when we change the environment configuration (VCS trigger)
  3. Automatic whenever a successful build of A is detected (Finish Build Trigger). Push new application versions to test by default.

I’ve used a combination of 2 & 3 (and 1 of course is always possible).

Artifact Dependencies

image

We need the artifacts (output) of build configurations A+B to be able to push to the test environment. I’ve used the last successful build but there are other choices available.

Deploying to the test environment (finally)

image

Above is a quick look at the TeamCity working directory for this build configuration. You can see that I’ve got all the files I need in the same directory with a combination of incoming artifacts (—>) and files from source control.

image

I’ve covered the PowerShell deployment script previously but above is just a view of all the files included and how they work together.

, ,

  1. SpecFlow: using environment specific settings (part 2) | Johan Leino

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this: