Help with migration from TFS CI

Hi Ike,

so, first things first, as also maybe some users might need this clarification, what is what:

-VCS Roots will define your connection from teamcity to the repository. They will define how teamcity can access the files in the remote repository. While you can have as many VCS Roots as you want, and duplicates that work independently, it's usually better to keep them at the minimum required. In order to do that, TeamCity accepts configuration parameters throughout most configuration fields (all of those with a small square right of the field, plus password fields). This parameters can be configured at project or even build configuration level, which means that you can keep even a single VCS Root of each type you need at the root project level and parametrize everything to be defined on projects or build configurations. This might make sense in some cases, while in some others the VCS Roots will be kept themselves at the project level.

-Checkout rules are only applied on build configurations, and they define how the files from the VCS, however they are set up, will be copied into the working directory. Also, a feature of TeamCity is that checkout rules are taken into account when checking for changes. If you have a larger repository but only a handful of directories are being checked out across the different root usages, TeamCity will take those into account and only consider those for changes.

-Triggers react to events starting a build. A VCS Trigger (only one can be applied per build configuration) will trigger on changes on the VCS Root, while many others will react to other different events.

With this concepts in mind, and keeping in mind that the system would be flexible to more options, the approach would be the following:

-Either 1 VCS Root (with SRC at its root) or 3 roots (with API/Apple/Linux at their respective roots), depending on whether you'd like to monitor all the repository as a whole, or the folders independently.

-One build per project. Attach the root(s) to them. Checkout rules should be added to exclude "project2", "project3", etc, or simply to exclude everything, and add explicitly "api/common", "api/projectx", "platform/projectx". Parameters can be used for checkout rules, and while parameters can't be nested, they can be used consecutively (for example, %platform%/%project% is valid, which could ease having a single template for all different projects or platforms and simply set them up at the project level)

-Before triggers, you should consider whether you are setting up one build or multiple. If you want to parallelize tasks for which the runner has no parallel support, you can set up multiple builds with smaller parts, and join them together afterwards by having a build with a snapshot dependency on each of the previous tasks. More information here: https://confluence.jetbrains.com/display/TCD18/Snapshot+Dependencies .

-Triggers would depend on when exactly you want to trigger. Triggers attached to a build will also respect the checkout rules attached to their VCS Roots, so if you set up a VCS Trigger in a build that via checkout rules only uses "project1" (and api), it should only trigger on changes on the required folders. If you are running snapshot dependencies, you would want to put the trigger only on the last build of the chain, as it will automatically trigger all of its dependencies (transitively, of course) and put them ahead on the queue on the proper order.

I think that should cover most of your questions, if you still have something, please feel free to ask.

Thank you very much. This should go a long way to helping me understand the TeamCity structure.