I am working on designing build and test systems for several projects using TeamCity, but I am a newbie as far as TeamCity goes (book on order still).
I have two general design questions, i.e., what is the best way to implement, rather than is this the only way to implement? Or at least, what are the trade-offs in making design choices along the lines described below?
Q1: On the test side, I have two "build steps" one of which is best performed on the Linux side (configuring the web server gateway) and the other on the Windows side (running SOAP queries). Of course, I could use a single agent and multiple build steps and then launch sub-processes on different O/Ses. However, I am thinking that it will be better to have the Linux processes launched using a Linux TC agent and the Windows processes launched using a Windows TC agent. It appears the agent specification is tied to the project/sub-project rather than to the build step. If so, I am assuming I will need to create two projects or at least one project with two sub-projects, and then trigger one sub-project from the completion of the other sub-project; rather than implement this a dependent build steps of a single project/sub-project.
My question is: Is this correct, or am I missing a configuration option?
Q2: Between the build and the test stages, there will be multiple build events which can trigger test runs. For example, the build/relase of a test suite initiating test runs against a set of releases of the web server and/or underlying databases. In addition, a new build of the web server could also initiate runs of the latest test suite against some set of databases. An additional wrinkle might be needing to run an earlier release of the test suite rather than the latest one (hopefully we can avoid this by having the latest test suite be aware of all older APIs but this is still TBD).
My questions are: Does TeamCity allow direct implementation of project A triggering a run of project B on the same TC server and/or project A on TC server B triggering project C on TC server D? Or will I have to implement some intermediate mechanism for these triggers? If the latter, what is the best external mechanism to use in these cases?
Of course, the answer to Q2 may be different depending upon whether one or two TC servers are used. However, I may be forced to use one TC servers for some projects and two TC servers for other projects, because of IT issues and team locations, so I am looking for answers in both cases.
Any advice before I start designing and implementing these systems will be greatly appreciated.