I am looking for a specific strategy / convention that works for concurrent development with Feature branches and a database deployment tool such as DbUp, DbDeploy, ReadyRoll, etc.
We run multiple feature branches for concurrent project development.
Each branch has a dedicated development, QA and UAT environment which is deployed via Octopus deploy.
I am trying to tackle automatic database deployment with Octopus using a tool that will handle the changes applied in each of the branches.
Database changes will occur in all of the branches (including the release branch).
Most of the tools that I have seen thus far use a sequenced based approach of scripts that are checked into the VCS and deployed by the tool. The tool for the most part applies the script in an ascending filename order and most that I have seen specify to follow an approach of 1, 2, 3, etc.
This works fine for one branch.
My issue will be when feature A has 1 and Feature B has 1 - both get merged into the main branch. I now have two #1 scripts. Making it even more fun - our path to production is to merge one more time which may also have a 1. So now we have 3 #1 scripts.
There is also the problem of backward merging. Once a project is done - merge the release branch back into main and then merge again to the feature branch to reset it for the next project. In this scenario - I have two additional #1 scripts that have not been applied to the target feature branch database.
My initial solution to this is to use a julian date as the leading prefix for the sql filenames that are checked into source. I was also thinking of applying the branch name to the file along with the work item. So the sql file would follow a convention of {XXXXX_Y_ZZZZZZ.sql} where xxxxx is the julian date, y is the branch and zzzzzz is the work item from TFS.
I am looking for a specific solution to this problem. Has anyone else solved this? What did you do? What are the drawbacks? What tools did you use?
Have you looked into Readyroll's semantic versioning?
We are implementing Readyroll now, we are a small team in which it's easy to communicate and confine changes between feature branches.
We integrate to a development branch and detect conflicting changes early on and basically rewrite earlier migration scripts if necessary (which requires have a baseline of your database project to which you can revert)
On the Redgate website there is some more information about working with branches but doesn't cover your scenario exactly, switch branches with readyroll.
When looking in to tools I basically came to the conclusion it a choice between a state based approach or a migration based approach. I like readyroll's take on it, which offers a mix.
I very curious what you end up with!