4
votes

I am starting work with a new codebase that has the automated builds in TeamCity. The dependencies are defined in TeamCity configuration which takes parts of build artifacts from other builds and extracts them to a "lib" subdirectory of the project being built.

How do developers reproduce a local build when the dependencies are defined in TeamCity? Is there a way to fetch the dependencies of a TeamCity build to update the dependencies locally?

Looking at documentation for TeamCity, the configuration of this project seems to be the expected way to setup dependent projects (a feature of TeamCity). However, the output of the project is an MSI. Is this normally broken up into two separate builds (one the creates the build output which includes the build dependencies and the output of the build and a second that takes these artifacts and generates an MSI)?

What I want to do is correctly updates my build area of my local machine to have the correct dependencies. What is the expected way to do this? If the "rules" are defined in TeamCity, how do I use them locally?

Update: I am considering using TeamCity as a nuget server and have the local builds install the dependent libraries using nuget client. It would be nice if the dependencies in TeamCity and the Project were defined in one place (DRY).

1

1 Answers

0
votes

My advice is: don't.

Avoid unnecessarily coupling yourself to TeamCity unless it offers real value for that specific task. If you are building genuine software packages i.e. independent, reusable libraries of code, then you are better off just building them as separate build configurations, and uploading them to a Nuget server (TC can function as a simple one). Then your local builds are going to be the same as CI builds, as its using nugets infrastructure.

TC dependencies are a useful tool, but can also be misused and overused. Remember TC functions a CI server for many platforms, some of which don't have packages (or didn't historically).