Multiple small project builds vs a monolithic build

I've been using Luntbuild for a while on my build server.  I'd really like to move into something more modern like TeamCity, but I'm not entirely sure how I'd handle a couple of things.

We have a few products which share a lot of components.  In the past, we built a single product as one huge build-- it'd check out the product source and all the components, build everything each time, and produce an installer.  But this took a long time for each build-- 40 minutes or more.  With TeamCity I'm thinking about breaking up the builds so we're not rebuilding every component every time.

But I'm not sure how to handle "releases", and especially going back to build a new version of a previous release.  With Luntbuild I'd branch off everything in SVN, then copy the luntbuild project with the copy pointing to the branch in SVN.  Then I'd update the main project so that it used the next version number.  So we'd release build 7.2.0.522 as our "7.2.0" version and start working on 7.2.1.  If we needed to do an emergency update of 7.2.0, we could do so in the SVN branch and still build it with the monolithic project in luntbuild.

But now that I've broken things up into so many separate builds, it doesn't see feasible to copy off all 12 little projects and make them each point to the SVN branch for an older release.  Is this just a danger of separating the projects like this?  Am I missing a simpler solution?

5 comments

Hello,



But I'm not sure how to handle "releases", and especially going back to build a new version of a previous release. With Luntbuild I'd branch off everything in SVN, then copy the luntbuild project with the copy pointing to the branch in SVN. Then I'd update the main project so that it used the next version number. So we'd release build 7.2.0.522 as our "7.2.0" version and start working on 7.2.1. If we needed to do an emergency update of 7.2.0, we could do so in the SVN branch and still build it with the monolithic project in luntbuild.


With TeamCity we are making branches in basically the same manner. We have a project with a number of build configurations. Usually all of these build configurations use the same VCS root (but in TeamCity you can have own VCS root per each build configuration with own checkout settings). When we make a branch we copy the whole project (there is a separate action for this in TeamCity UI). Then we reconfigure VCS roots of the project copy to point to the branch. And finally we modify build numbers of the original project. So after that procedure our original project still points to the trunk (and thus it preserves the whole statistics and history) while the project copy points to a branch (BTW we have a feature request to automate the branch procedure).


But now that I've broken things up into so many separate builds, it doesn't see feasible to copy off all 12 little projects and make them each point to the SVN branch for an older release. Is this just a danger of separating the projects like this? Am I missing a simpler solution?


I am not sure why do you need 12 separate projects, probably it would be better in your case to have separate build configurations combined in one project. Or if you can't combine these projects, consider using a shared VCS root. You can configure one VCS root for a branch, share it and then use this VCS root in all of the 12 projects.

--
Pavel Sher

0

Thank you for your reply. It looks like I have some more reorganization to figure out. It amazes me how complex the problem can be. Thank you for such a great product-- it's making the tedious process a bit more fun.

0

Just to clarify one other thing-- with the procedure you've described every release would add X more build configurations, right? So it would require an enterprise license to maintain more than one release?

0

There is a limit of 20 build configurations for professional version. If build configurations limit exceeded TeamCity will just stop running builds until excess build configurations removed.

If there are inactive projects you can move them manually out of TeamCity data directory (server restart is not required). This is not very convenient because these projects history will be cleaned up, but at least it allows you to keep their settings. Then you will be able to restore projects if you move them to the data directory (again server will bring them automatically without restart). However if you choose to do so keep in mind that every upgrade may apply some converters to project config files, so to keep these projects settings correct you will need to restore them every time before upgrade.

--
Pavel Sher

0

Thank you. It's good to know you can move inactive projects in and out of the system.

0

Please sign in to leave a comment.