Shared Resources in TeamCity

It’s a common requirement that a set of your tests depends on some resources. It might be a database or an Azure Storage account. It’s possible that instead of providing TeamCity with an administrator account (giving a subscription access for Azure) you’d prefer to have a limited preexisting set or resources like databases or Azure Storage accounts that are leased for a build time by a particular agent. As soon as build is finished the resource would go back to the pool to be leased for another build.

Fortunately TeamCity has a built in ability for this purpose called Shared Resources. This can be defined on any project level and used as a parameter of any build configuration below. Shared Resources feature provides you with all the capabilities mentioned before, removing all the burden of managing a resource pool. In the same way a build leases an agent, an agent leases a shared resource. Nice, simple, easy.

3 thoughts on “Shared Resources in TeamCity

  1. I completely agree that Shared Resources are pretty useful and we can easily find numerous use cases for that!

    What I wanted to say is that db and storage are not ideal examples as they can/should be configured at the environment level.
    I think you can easily provision database each time deployment is executed, you can also seed initial values or import data-tier application in bacpac.

    At the end of a day, it always depends on your needs and requirements.

  2. Cool feature I wasn’t aware of, possibly because I haven’t been using TC for a long time now.

    I think resources like database or Azure Storage mentioned in this post should be environment specific, not shared across build infrastructure. You build the app, deploy it to the target environment with preconfigured resources and test it, no need to use administrator credentials.
    In the cloud world you could also use PhoenixServer as a part of your CD process.

    • Sometimes you neef your db for tests, as emulators may provide wrong results. In finances, you could consider a limited number of mainframe instances. This is the way to address it.
      You can’t ‘phoenix’ your database though, can you? 😉

Comments are closed.