1

Our company currently uses TFS for source control and build server. Most of our projects are written in C/C++, but we also have some .NET projects and wouldn't want to be limited if we need to use other languages in the future.

We'd like to use Git for our source control and we're trying to understand what would be the best choice for a build server. We have started looking into TeamCity, but there are some issues we're having trouble with which will probably be relevant regardless of our choice of build server:

  1. Build dependencies - We'd like to be able to control the build dependencies for each <project, branch>. For example, have <MyProj, feature_branch> depend on <InfraProj1, feature_branch> and <InfraProj2, master>. From what we’ve seen, to do that we might need to use Gradle or something similar to build our projects instead of plain MSBuild. Is this correct? Are there simpler ways of achieving this?
  2. Local builds - Obviously we'd like to be able to build projects locally as well. This becomes somewhat of a problem when project dependencies are introduced, as we need a way to reference these resources or copy them locally for the build to succeed. How is this usually solved?

I'd appreciate any input, but a sample setup which covers these issues will also be a great help.

Adi Lester
  • 24,731
  • 12
  • 95
  • 110

1 Answers1

1

IMHO both issues you mention fall really in the config management category, thus, as you say, unrelated to the build server choice.

A workspace for a project build (doesn't matter if centralized or local) should really contain all necessary resources for the build.

How can you achieve that? Have a project "metadata" git repo with a "content" file containing all your project components and their dependencies (each with its own git/other repo) and their exact versions - effectively tying them together coherently (you may find it useful to store other metadata in this component down the road as well, like component specific SCM info if using a mix of SCMs across the workspace).

A workspace pull wrapper script would first pull this metadata git repo, parse the content file and then pull all the other project components and their dependencies according with the content file info. Any build in such workspace would have all the parts it needs.

When time comes to modify either the code in a project component or the version of one of the dependencies you'll need to also update this content file in the metadata git repo to reflect the update and commit it - this is how your project makes progress coherently, as a whole.

Of course, actually managing dependencies is another matter. Tons of opinions out there, some even conflicting.

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • Thank you very much for your answer. This looks like the direction I will go to, but it really surprises me that there's no standard way to do this. Does anyone who has dependencies define their own metadata file and custom script to resolve them? Hasn't anyone done this before and shared his solution somewhere? – Adi Lester May 30 '15 at 10:04