Sitecore deployments - Part 2 Team City

Automate Everything...

...and generally these days most people are. We use Team City as our continuous integration platform and as usual all our projects are setup in different ways.

Here's a typical example.

The Setup

Here we have a a few projects. The first two in Development are for QA and UAT. These are on demand deployments. Team City prompts for the Url of the code branch to be deployed. Alternatively you can just set a default and Team City will always deploy from that which is a bit less flexible.

The Release project is geared around releases to live. We don't allow direct deployments to the live environments (content management & various content delivery). Instead we merge into an integration branch which is automatically deployed to an integration environment. Tests are run and when we are happy we can promote the release (note promote means the very same code package) to UAT and then Live.

During the release process if version 1.4.5.600 is released to Live then Uat and Dev would also have the same version deployed to them beforehand. This can be relaxed in emergency situations. i.e we have a system in place for a urgent live bug fix.

Build steps

Some projects can have many many many build steps, but let's keep it simple with the following setup which covers most bases:

First team City will pull the solution from source control.

Please note this does not include the Sitecore runtimes. These should not be in source control. More on this in part 3.

Team City will update nuget packages, build and then create a nuget package of the solution ready to deploy to the environment specified in tthe Build and Package configuration. This happens via OctoPack - make sure the OctoPack nuget package is referenced.

An alternative for MsDeploy users would be to execute a MsBuild script to execute various build tasks (i.e transform configs), create a zip of the solution and then deploy this (via MsDeploy) to the servers of your choice.

Unit tests and Selenium integration tests are then run deploy the nuget package is handed to Octopus which deals with deployments, config transforms etc.

See this blog post for why we use the NoDefaultExcludes command line parameter.

Octopus

Below is our configuration to tell Octopus we want to deploy the package we just built. This needs to be configured after Octopus has been set up. This will be covered in Part 3. (Coming soon)

A couple of notes here. We update release version regardless of deployment environment using %autoinc%. This means if we deploy 1.0.0.100 to QA and then decide to kick off a live release - which is a different Team City project - the version deployed to Live will be 1.0.0.101. This is patched to all the assemblies. (You can do this using the AssemblyInfoPatcher in build features).

The --package command argument is to let Octopus know the name of our generated nuget package which includes the version number.

Sitecore

So far in Team City we've done nothing special for Sitecore.. (this is a good thing)

Also what about deploying Sitecore content?

thats all handled next in Part 3 - Octopus >>