TeamCity system architectual and configuration questions

Hi,

We  are a company with number of dev teams globally. IT is working to setup an enterprise instance of TC to support multiple teams, the normal pattern is that IT setup the instance and own the server/services/apps and support. However one (big) team now asked to change the pattern and would like to has it's own TC instance and want IT only provide HW/backup/license, and leave all other parts to the team itself. The reason they want this is that this will give big freedom to the dev team and totally avoid IT restrictions/delays. From IT side, we see that we will need to spin multiple instances for different teams, which could be a big waste of license cost. Another problem is that IT will have to handle different teams differently - some teams handle more on TC themselves, others don't.

So, I would like to get some epxert inputs here to the two patterns, better pros/cons for each of the patterns. We are working on the enterprise tool now and would like it to be efficient and less trouble for both users and owners (no matter IT or dev teams), so would like to have expert visions on both patterns.

Also we would like to know what's the max build configurations a TC instance can host? Is it a normal practice to host heterogeneous products in one instance or in different instances?

Thanks in advance for any inputs/suggestions,
PB 

5 comments
Comment actions Permalink

Hi Peter,

The recommended approach is to use one TeamCity instance. There are many drawbacks of using multiple TeamCity instances. For example:

  1. You'll have to buy several TeamCity licenses
  2. Administrator have to monitor several instances (configure backup/authentication/notifications, monitor memory and space usage and so on)
  3. No centralized artifacts storage (you won't be able to easily configure artifact dependency if needed)
  4. For developers who need access to many projects it will be more convenient to have only one TeamCity account

I guess you can face with more problems in practice.
The only case when we suggest customers to use several TeamCity servers is UI slowdown. However before you start using the second instance we will be interested in investigating the problem.
In JetBrains we use one TeamCity instance for all projects. It works with more then 100 build agents, having 1000 of build configurations together in all the projects. Please find more example based on our experience in this documentation entry.
Also we published the related blog post a week ago.

0
Comment actions Permalink

Thank you Alina!

If we have projects based on different languages/frameworks, say java and .net, the builds are mounted into different agents so that the the build dependencies (Jre vs .net) can be installed on separate agent systems, but TC server will not need to deal with the complexity on the server systsem itself. Is this correct?

Are there any docs or blogs for best practices of TC?

0
Comment actions Permalink

Yes, you are right. Builds are running on different agents and it won't affect the server complexity. Here is the list of useful links: 
Official TeamCity blog http://blog.jetbrains.com/teamcity/
TeamCity Documentation https://confluence.jetbrains.com/display/TCD9/TeamCity+Documentation
User Guide https://www.jetbrains.com/teamcity/documentation/userguide.jsp
Other docs and demos: https://www.jetbrains.com/teamcity/documentation/
You are welcome to post your questions in the forum!

0
Comment actions Permalink

Hi Alina,

Thanks again for the info and links.

While working with enterprise TeamCity system setup, we would like to get input on best practice (or documents) of how to draw the line between IT (support) and dev team (users), from perspective of RACI and R&R (resourc & responsibilities). I know this is not a normal TeamCity application question, but setting proper ground in system design will make the best usage and efficiency for TC.

We really appreciate your help, and definitely desire to talk with you (or anyone proper for this) if feasible.


Thanks!

0
Comment actions Permalink

Hi Peter,

The usual approach is to grant System Administrator role for one or several persons who will configure the TeamCity server. They can create and manage users' accounts, authorize build agents and set up projects and build configurations, edit the TeamCity server settings and etc. Find more info in Administration Guide.
For developers the appropriate roles are Project Administrator or Project developer.
Please find description of the default roles in TeamCity in this section: https://confluence.jetbrains.com/display/TCD9/Role+and+Permission.

Does it ansewr you question? If not, could you please provide some more detail about what you had in mind?
0

Please sign in to leave a comment.