Evaluating Team City

I currently use Jenkins as my CI tool and would like to evaluate TeamCity.  Granted that Jenkins is a free tool so I'm more interested in the TeamCity Professional version which is free.  Now in Jenkins I have one Master server and a couple of slaves machines.  I have UnitTest Server and an IntegrationTest Server as slaves the main compile runs in the Master.

Note: I have a total of 2 Master Servers (one for a Main trunk and one for a Branch), two UnitTest Servers and two IntegrationTestServers.

For TeamCity I read it comes with 3 build agents, I assume the build agents are the ones that checks for any changes in code but I could be wrong.  Can someone please tell me if this is an equivalent of a slave in Jenkins?  Meaning do I need to have a build agent on my UnitTest Server and another on my IntegrationTest Server?  The UnitTest Server and IntegrationTest servers purpose is just to run the Unit Test using Dotcover and the Integration test using dotcover as well.

I attached a diagram to show what I currently have.


Master - produces the artifacts
Slaves - consumes the artifacts and runs the test.



Attachment(s):
MyContinuousIntegrationDiagram.pdf
5 comments
Comment actions Permalink

TeamCity build agent is not exact equivalent of Jenkins slave. Build agent is a worker waiting for commands from the server. It's main purpose to obtain source code (either from TeamCity server, so called server side checkout, or from VCS repository - agent side checkout) run a build script or a series of build scripts. While build is running, agent watches for results and sends them to the TeamCity server. Results can be different - tests, build process output, artifacts, code analysis reports, etc.

It is important to understand that TeamCity server orchestrates agents activity, without TeamCity server agents won't do anything (except some background cleanup tasks). Also it's a server who watches for changes in version control and triggers a task on agent.

0
Comment actions Permalink

Thank you for the reply Pavel, so for me to accomplish what I want (which is to just run the Unit Test and Integration Test on separate servers) I will need to have a build agent on both servers and then have it communicate to the Main Team City server to run the test.

I was hoping that I only need one build agent where it will check the repository for any changes, run the compile and then send those artifacts into two separate servers for processing (run the tests) and then sends it back to post the results to Team City.

Maybe I'm missing something here but is there a way to accomplish what I want using Team City?

0
Comment actions Permalink

Note: I do not work for Jetbrains and I'm not double-checking my response against their license rules.

For the basic setup you depict, you can use one Professional server as the master, and install 1 agent (remember, it comes with 3) on each of the master server machine, the Unit Test server and the Integration Test server.  So far as having a complete setup for each branch, if it's truly necessary you could potentially download a second Professional server and do it all again (but see my note about "I didn't look at the license restrictions"), but I'd suggest evaluating TC first to see if you really need to do that... you may be able to accommodate everything in a single setup.  Comments are my own.

0
Comment actions Permalink

I'd add to Mark's comment that you could restrict the build configs that you define to specific servers (either by name or parameters). So one for compilation, one for unit tests and one for integration tests. Seems like Professional should do the job in this case.

I'm a happy JetBrains customer. :-)

0
Comment actions Permalink

Thank you both for the replies, I will use your suggestions and see what happens.

0

Please sign in to leave a comment.