Need advice in project and configurations structure

Hi All,

We use TeamCity extensively, for both build & test, but also automated repeatable deployments.  Looking at the admin page tells me "You have 31 active projects             with 350 build configurations."

Our most common structure would be:

Compile Project A

  • Compile Release 2010.Jul
  • Compile Release 2010.Aug
  • Compile Release 2010.Sep
  • Duplicate Finder 2010.Jul
  • Duplicate Finder 2010.Aug
  • Duplicate Finder 2010.Sep
  • Unit Test 2010.Jul
  • Unit Test 2010.Aug
  • Unit Test 2010.Sep
  • Wet Test 2010.Jul
  • Wet Test 2010.Aug
  • Wet Test 2010.Sep


Deploy 2010.Jul Env X

  • Deploy Project A Component I
  • Deploy Project A Component II
  • Deploy Project B Component III
  • Deploy Project C Component IV
  • etc


Deploy 2010.Jul Env Y

  • Deploy Project A Component I
  • Deploy Project A Component II
  • Deploy Project B Component III
  • Deploy Project C Component IV
  • etc


Deploy 2010.Aug Env X

  • Deploy Project A Component I
  • Deploy Project A Component II
  • Deploy Project B Component III
  • Deploy Project C Component IV
  • etc



Our repositories are all in SVN, most with the structure /branches/release/2010.XXX . Due to our branching methodology, we end up with many VCS roots eg: Component_X_2010.Aug, Component_X_2010.Sep.  The usual historical stuff that just breaks the rules to work around.

When setting up the next release as a deployment project, there is significant rework to be done, even if cloning an existing project.  We've been caught before by artifact dependencies being wrong, or a VCS not being updated correctly.

In the example above, the deploy projects are very similar, but point to a different set of servers.  The difference may be the source (release) or the destination (environment - set of servers).

How do I leverage the new config templates? I'd like to templatise including the vcs root and parameters

I would really like the new configuration parameters to be able to be set at the project level, and be available to all the configurations. Is this a possible forthcoming feature?

I read that you can use check_out_rules with the new parameters, but wouldn't that dramatically slow down subversion?  (ie: need to check it all out before applying rule)

Basically just looking for some advice, and maybe some validation.

1 comment

Luke,

It seems you can minimize VCS roots number and use checkout rules more. You can also use references to properties in checkout rules (thus, you can adjust the SVN path in a build configuration using a template).
As to performance, moving to less VCS roots and more variance with checkout rules tend to slow down each single checking for changes a bit, but reduce the number of checking for changes requests and thus increasing overall performance. I'd suggest you try the approach and see how it works for your case.

> How do I leverage the new config templates? I'd like to templatise including the vcs root and parameters

It's very specific, but probably you can try to start with the following tamplates:
Compile Release
Duplicate Finder
Unit Test
Wet Test

You can also have a template per deploy configuration and redefine the source build configuration for artifact dependency in each configuration using a template.

> I would really like the new configuration parameters to be able to be set at the project level, and be available to all the configurations. Is this a possible forthcoming feature?

Please vote for the feature request: TW-4612

0

Please sign in to leave a comment.