Some of our projects are using feature branches. The problem is that this tends to break the dependency management as soon a feature branch in one repository starts depending on feature branch in another repository.
Let me provide a quick example:
- assume that the
masterbranch is supposed to be stable and releasable - assume that all user stories are captured in an issue tracker, and for the delivery of each one we create a feature branch
- assume (for simplicity) that all stories are merged in a single go, when they are fully developed and tested
- assume we have a project
applicationin its own Git repo, depending on a projectlibraryin its own repo
When we start a new feature for application, we create a new branch named like ABC-123. It will start out the same as master branch, which in this case means that it would depend on 'com.acme:library:1.0.2-SNAPSHOT'. The continuous build will pick up the application branch and build it after every commit. Life is good.
Then we realize in order to deliver ABC-123 we need a change in library, so we branch the library from its master, add few lines of code and publish. Easy, peasy.
Then our colleague, finds a bug in library, adds a NPE check and publishes from master. Oops… the application/ABC-123 no longer builds as the library snapshot now points back to master. Time to go to StackOverflow…
After some searching, we find a lot of dubious advice and the most credible suggestion seems to encode the branch in the version of the component. After some head-scratching and beard stroking, we agree that if you tilt your head and squint, this solution actually reflects the domain, so we start changing our versions when we branch, and changing all dependencies when we branch another repo.
We just introduced a number of manual steps, each one resulting in non-obvious, difficult to troubleshoot bugs if one forgets to do it or takes it wrong. Furthermore, you no longer can just merge a pull request, because you need to unmanagle all the versions manually.
Then you try to read the branch from Git and mangle the versions accordingly. Congratulations - you just coupled your build to your VCS and made it irreproducible if you switch version controls in the future. It will also break if yo don’t branch all dependencies every time with the main project.
The described scenario is the simple one. There can be a lot more complications.
Typical one is when you have a simple multi-level branching - i.e. you would have a development branch, where you would want to put all changes that haven’t been fully vetted yet. In that case, we should look for feature-branch artifact first, then a development artifact and then master.
This is where we are. I searched and I read, and I scratched my head - I can’t find a good solution on the internet.
I have a hunch that the Component Selection Rules are supposed to solve this problem, but I am just not smart enough to use them without example. In particular, how would these work with Maven descriptors? Can we take advantage of Artifactory matrix parameters?
Any pointers (or consolatory war stories) would be appreciated.
cheers,
Dimitar