Parallel development branches, Build Artifact repositories and QA releases

How does parallel development / branching in your VCS effect your build artifact repository setup and releases to QA?

At our company we branch our VCS for parallel development efforts and we often do not have much of a warning of which branch will ship in which order.

For version numbering, I would like to place a branch identifier to show QA which branch the build came from. Any builds from the trunk would have a 'normal' version number with no branch identifier in it:

trunk: 1.1.0
branch: 1.1.0.MyBranch
branch: 1.1.0.AnotherBranch

Originally I thought to have one build artifact repository per branch, and one main repository for the trunk.

But if my version numbering includes the branch, then the version number will be wrong for the product (if I'm building and releasing from the branch).

Is the way around this to only release from the trunk?

Also, at what point should I start shipping the QA team builds from the trunk as opposed to builds from the branch?

My current idea is to convince management to assign a dev team to a release order (say a week out from release) and merge their branch to the trunk. Then QA starts getting trunk builds instead of branch builds, and the dev team whose branch has been merged fixes any bugs directly in the trunk and not the branch.

* UPDATE *

More specifically, I'm using SVN for VCS, and Artifactory for my repository. I'm using Ivy for dependency management.

Looking at the Artifactory help on Repository Layouts (Repository Layouts):

"a sequence of literals that identifies the base revision part of the artifact 
 version, excluding any integration information"
"'1.5.10', or in case of an integration revision '1.2-SNAPSHOT' the base revision
  is '1.2'"

This and the default layouts for Maven and Ivy suggest to me that this is more common:

MyRepo
 MyLib
  1.1.0 (this is the dll from trunk)
   -MyLib.dll
  1.1.0.MyBranch-SNAPSHOT (dev builds from the "MyBranch" branch)
   -MyLib.dll
  1.1.0.AnotherBranch-SNAPSHOT (dev builds from the "AnotherBranch" branch)
   -MyLib.dll

Is this the typical repo layout for using Ivy? I would assume that this would require using Ivy's branch feature to resolve dependencies at build time to the correct branch folder in the repo?

* UPDATE 2 *

Here is my current Artifactory structure:

MySnapshotRepo
 CompanyName
  CompanyName.MyLib
   1.0-SNAPSHOT
    MyLib.dll (snapshot builds from the dev branch)
MyReleaseRepo
 CompanyName
  CompanyName.MyLib
   1.0.0
    MyLib.dll (release builds from the trunk)
   1.0.1
    MyLib.dll (release builds from the trunk)
   1.0.2
    MyLib.dll (release builds from the trunk)

How do I point Ivy at a specific repo at build time? For a release, I need to only pull binaries from the release repo. For a snapshot build, I can pull binaries if they show up in the snapshot repo, if they are missing I can pull them from the release repo. I understand how to chain repositories, I just don't understand how to switch them.

In my IvySettings.xml file I have:

<settings defaultResolver="defaultresolvechain"/>

..but I don't want a default. I'd like to specify which chain of resolvers to resolve to when I call the Ivy resolve command. Something like this:

<ivy:resolve transitive="false" resolveMode="snapshot-resolve" conf="compile,test"/>

Is this the wrong way to switch the repos I need to resolve against?

The publish task has a "resolver" attribute which works perfectly for me in a similar fashion.

Also, in my particular example, I may have multiple SVN branches corresponding to multiple Artifactory snapshot repos. Can I parameterize the way I resolve to which repos? Or is the more correct way to place snapshots from all branches into one repo, and use the Ivy branch feature?

Please let me know if you need any other info to assist.

So you have release builds and feature or development builds. You will get your release builds from trunk and the feature builds from 1.1.0-feature branches. Don't use the trunk for development at all. Do all the development on those feature branches, when they mature and you decide to include them as part of release merge them to trunk. At that point this code appears in QA builds which come from trunk. As you are getting ready to release, you branch from trunk, while you keep working on other feature branches and merging them to trunk.

So QA gets builds from trunk and from stability release branches. You can simplify further by having only one release at a time and always do QA only from trunk and branch or tag just at the time of actual release. This would be possible if there is absolutely no development going to trunk, but all to the feature branches.

Sometimes you will need to be able to pass a development build to QA. Usually before merging the feature branch to trunk, just to be sure you did not break anything. You can tag pre-merge, merge feature branch to trunk and do the QA build from trunk in this case and if there are serious problems, you can revert back to the tag. It will prevent the merging from another feature branch, while this is going on, but if the merges down to trunk are infrequent, this could work.

This way you can have single setup for QA from trunk and you should manage most of what you need to do.

Recommended topics

Hot tags