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.
Please sign in to leave a 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