Branching strategies with maven, teamcity and TFS

Question

I have been tasked with updating our build process right now to be more efficient and I have spent a week reading best practices and strategies but I still have not found a solution for our current problem.

Background

Currently we have one monolithic build/application that really needs to be split apart into at least 4 applications with some shared libraries. We currently do not branch unless we absolutely have to. We have a teamcity build that builds on each check-in to TFS. When we are ready for a release we have a code freeze and only check-in fixes for bugs found in QA. Obviously this is a terrible practice and we have finally gotten approval to change it.

Proposed Solutions

The proposed solution will be to split up the application and have different release cycles for each application, move from ant to maven and branch per release.

Branching - Right now we just have a main trunk in source control. I think we want to branch off the trunk when we are ready for a release, and update the branch for bugs found in QA. When the build is ready to be released, merge the branch changes back into the trunk.

Here is how I was planning on setting up TFS.

+Apps
    +App1
        +Components
            +Core
            +Web
        +Branches
    +App2
        +Components
            +Core
            +Web
        +Branches
    +Libraries
        +Lib1
        +Lib2
        +Branches

Thinking about managing all of the POMs and versions in the POMs seems WAY too difficult right now. I've read up on the maven release plugin, but I'm not sure if it can branch in the way I'm thinking we want to.

Next problem is getting teamcity working. I was thinking of having 3 teamcity projects for each app. A dev project that always points at the trunks, a QA project for testing the QA build and a production project to build changes for hotfixes. Each time a new release comes to QA I would have to update the QA teamcity project to point at the new release branch and update the release build number in teamcity. When that release passes QA I would have to update the production teamcity project to point that the branch that just passed QA and update the build number to the build number that just passed QA.

Surely there is a better strategy that this.

Questions

Where should I be putting these branch folders?

Should QA builds be snapshots still until the build goes to pre-production?

How do you configure teamcity to pick up these branches without changing the sources path for every release?

Should there be parent POMs for each app that the developers use to make sure all of their dependencies are compiled and up to date?

Check out my post regarding TFS branching strategies. It might help answer part of your questions. stackoverflow.com/questions/5720661/… — Daniel

KevinS KevinS · Accepted Answer · 2012-01-17T17:28:10

I just want to question your thinking that your applications should be on different release cycles. Modularization is a good thing for code quality but if your modules are on separate release cycles you introduce a lot of overhead. In particular, version management becomes quite a burden and if you get it wrong you can introduce runtime bugs.

How do these separate applications relate to each other? Is there any dependency between them (maybe via a shared library)? Do they communicate with each other? Are they deployed together?

If it is not necessary that they be on separate release cycles then you're probably better off keeping them together.

Branching strategies with maven, teamcity and TFS

1 Answers