CODEWITHSUNDEEP
deploymentcontinuous-integrationteamcityenvironment
Shane Callanan
Shane Callanan

Reputation: 2305

Deploying to multiple environments [TeamCity]

We have a complex structure of projects in TeamCity (v. 8.1.5) that we trying to deploy to over 30 environments without user input.

All along, we have been copying projects and using environment variables to identify the environment to deploy to. The main drawback with this approach is the rolling out of updates to builds. If we need to update a single variable in our builds across the board we need to do this in over 30 projects, each of which may contain 20 builds. It all works out to be an incredibly time-consuming process.

How do you manage deployments to multiple environments in your TeamCity setup?

Upvotes: 2

Views: 2163

Answers (1)

Jay Guidos
Jay Guidos

Reputation: 151

We have about 15 environments we deploy to, and about 30 odd builds. We have much the same problem, and we tackle it various ways.

First, as someone already mentioned, we use a lot of templates. In Teamcity, if build templates are not your best friend you are using it wrong.

Second, we take full advantage of the hierarchical organization of projects, and use inherited properties extensively. If your deploy builds can be organized to minimize the number of unique parameter values (pushing common parameters up the project tree) you can save a lot of time and grief. For example, lets say you organize your projects by OS and version:

Deployments
---Windows
------Vista
------W7
------W8
---Linux
------CentOS
---------6.4
---------6.5
------Ubuntu

Then you can group your parameters, for example, by OS (Windows or Linux) and then flavours of each.

Finally, we control a lot of parameter values via VCS roots and/or named files. The right parameters file is selected and then a small build step executed FIRST, that reads the parameters file and loads their values into the current build using TeamCity custom build output syntax.

To select the 'correct' parameters file you can either keep them all in a common location in VCS (i.e. https://svn/deployments/buildParms) and name each file uniquely, or you can parameterize your VCS root to find the place in source control to get the file (i.e. https://svn/deployments/%MY_VERSON%/deploy.properties.

Using combinations of the above approaches allows us to effectively manage 15 deployment environments and seven active code branches, for a total of 105 different deployment configurations.

Hope this helps.

Upvotes: 4

Related Questions