We are not a software shop, we are a development team supporting a business. As a result of this the best branching strategy for us is, in my opinion, a branch by release architecture.
I envisage having a TFS branch structure something like so:
- Code: Select all
. next major version
. BAU maintenance
And I envisage having a development process like so:
1) Developer works in either the next version branch or the BAU branch as appropriate.
2) Forward integrate (merge) from production regularly to resolve incompatabilities that may be coming from the opposite side of the trunk. This is particularly important for "future release" branches. At minimum, forward integration from the trunk is *mandatory* prior to reverse integrating your changes back into the trunk.
3) Prepare UAT/RC releases from your branch (?) and hand off to the DBA (me) and/or the infrastructure team for deployment.
4) Reverse integrate your changes into the trunk in preparation for the production release. Build and deploy from the trunk for the production release.
One of the problems I am facing isn't really a SQL Source Control problem, but I will mention it anyway: I'm not certain about the origin of UAT or RC builds. The advantage of having them come from a dev branch is that the trunk is always clean, current "production" code. Nobody has to worry about changesets or labels. On the other hand, creating releases from somewhere other than the trunk seems slightly icky. Any ideas here would be appreciated.
In any case, moving on to my actual SQL source control issue...
My sticking point is coming from the forward and reverse integration steps. This is where a developer must merge the trunk into their branch prior to building a deployable release candidate, or from their branch back into the trunk prior to a production release. I'm not sure how to accomplish this function using SQL Source Control + SQL Compare.
What I (or rather the developers) need to be able to do during, say, forward integration, is set the production trunk as the source of a diff, and the development branch they are working in as a target. The output generated by the comparison should highlight incompatibilities or inconstencies if they exist. The diff is then resolved and applied to their dev branch / the development database (yes, we use a single shared dev database approach. I don't want to have to go into why or how we do this, although I can if required). This is the forwad integration step.
To do this, I need to be able to set one source control branch as the "source", and a different branch as the "target" of a sql compare operation. Note that I would prefer not to force the devs to use an actual database as the source or target. They should be able to work using the revision control system, that's where merging takes place.
But I don't see a way to do this by right clicking on a database in object explorer and selecting "set as source" (or target). Yes, I can select the "source control" radio button, but I don't see any way of selecting a different branch.
As such, I don't see any way for my developers to be able to perform the required merges using SQLSS and SQL Compare.