Branching Strategy For Dynamic Environment
I am working in a very dynamic environment where several different features and bug fixes are worked on simultaneously by many different developers. The project is a large public facing website that must have bugs resolved quickly and has constantly revolving promotions. We are having a problem deploying changes quickly when some technical features may take weeks to develop while other minor ad campaigns may take only days to develop. So I was thinking that an environment like this would benefit from each developer having a private branch. and then merging in chages to the main branch when a feature was complete. I set up a prototype of this environment and private branches seem very clunky in Team Foundation Server. I have seen many people compare shelving to private branches in subversion but that simply is not the case because a shelvset cannot be versioned. The inability to version a shelveset is why I deceide to try and create an environment with true private branches.
Somethings I determined from the prototype:
- Merging changes from private branch into the main code line works well if there are no conflicts.
- Getting latest of the main code line to a private branch does not work well and can only really be perfromed by a merge from main back to private.
- Inconsistencies start to occur when a merge contain conflicts and sometimes requires several merges back and forth between the main and private branch to get the private branch in sync with the main code line.
My idea was that we would only allow changes to be merged into the main codeline when they were ready to be QA'ed. The problem with this is that some features may take days to QA and if something urgent comes up through QA then they must QA the urgent feature/fix asap and put the other feature on hold. If the urgent fix is approved then deployment usually happens immediately. But the code for the non QA'ed feature is mixed in with the urgent fix.
I thought that we could just rollback the changeset of the feature not ready for deployment. I did this with the TFS Power toys, but it caused major problems with the private branches and they could not longer tell what needed to be merged.
I know this may sound like a crazy deployment cycle, but I know I am not going to be able to change this process right now. So my goal is to try and minimize the possiblility for problems with the current process through effective branching and communication. However I have been unable to come up with a source control strategy that can help me solve my problems.
Does anybody have any pointers or can you help me hash this out?
Thanks,
Jesse
Shelvesets are good for
some things that we previously used private branches for, but they're definitely not a direct replacement. Your system of branches sounds good. Only allowing changes in Main to come from independently coded and QA'd branches is a classic risk management strategy found throughout SCM.
If I understand correctly, your problem is wanting to occasionally merge an important fix from a branch that hasn't been QA'd yet. Have you tried the "merge selected changesets" feature? (on the forum & in blogs you'll probably see us call it "cherry-pick merging") Your scenario is exactly what it's for.
The point about rollback not playing nicely with merges is an important one we need to document somewhere. Rollback isn't a feature of the underlying system -- all the PowerTool does is checkin a new changeset with the old data. Merge sees this changeset as just another candidate to propagate to other branches, while "logically" it should do the opposite: discard the changeset that you rolled back. Maybe we can add this to TFPT.
Hi Richard. Thanks for the reply. Actually I was thinking of merging the changes into the main branch when they were ready to be QA'd. QA would be the gatekeeper and only allow one new feature/bug fix to be in the mainline at a a single point in time. If the feature did not pass QA, it would be rolled back and taken out of the mainline. Or if an urgent update was required, the current feature could be rolled back and the urgent feature could be merged in. This would prevent non QA'd code from accidently getting deployed to the production environment. Since TFS does not provide true rollback capability, I dont think this strategy will work very well.
It sounds like what you are suggesting is that a feature/bug is QA'd directly from the devs private branch. This sounds like a good idea. Maybe a little more work to get the code to be tested onto a QA machine, but Im sure we can get some build scripts together for that.
I initially though that each dev would have a private branch and would be merging back and forth with the main code line to keep thier private version up to date. Do you think it would be better to delete a private branch and create a new branch when a new feature is started as opposed to merging in changes from the mainline to an already existing private branch? Essentially the devs private branch would live forever. Will performance of TFS be hurt by creating tons of branches? Will deleted branches effect performance? I have done testing in the protoype environment and have ran into problems with recreating branches with the same name as deleted branches, such as this error TF14087: Cannot undelete “%0- insert your file name here” because not all of the deletion is being undeleted. Are unique branch names important for the system to work properly ? I read this blog post, http://blogs.msdn.com/mrod/archive/2006/10/10/The-logic-and-reason-behind-error-message-TF14087.aspx, and it seems like the problem has been acknowledged.
Thanks for the Cherry-picking tip. I was not aware of that feature. I think it will come in handy for us at some time in the future.
As for the rollback problem, I had a branch that contained some changes and a renamed file. I merged the changes into the mainline. The changes didnt pass QA so I wanted to rollback the changeset. I did this and it appeared that the main code line was back to its previous state. I then made a fix on the branch and tried to remerge the changes. The merge tool would no longer pick up any of the changes that needed to be merged in, not even the renamed file. The tool kept telling me that both code lines were the same. I can try to reproduce this and provide more information if you need me to.
Yes, I'd recommend you QA directly in a branch. The idea is to keep the quality of the Main branch high so that others can safely build it, deploy it, take forward integrations into their own branches, etc. without having to phone the people who last touched it to see if QA is done. The fact that rollback across branch lines is unintuitive is another good reason. Ideally the only problems you'd need to fix in Main are related to integration -- and if keeping Main stable is a real priority, as it is e.g. in web development where it represents the current production code, then you probably want to create intermediate branches for integration work.
Branches can be private for each developer, but it's more common to group them by feature (or whatever unit you want to merge together). Reusing branches is fine -- once you forward integrate to bring it up to date with Main, it should work identically to a newly created branch. Or you can create new branches. Delete the old ones, or not, doesn't matter. Creating new branches with the same name should work seamlessly but whenever you mess around with >1 item in a given path you're more likely to hit strange scenarios -- either bugs like the one Mario wrote about, or worse, correct behavior that fries your brain.
Performance is only affected by the total # of items in question. TFS v1 has trouble operating on more than ~100k items at a time. If your branches are significantly bigger than that then it's probably easier to reuse them then to write tools to create new ones (since you'd have to do it in batches to avoid hogging the server's resources from everyone else).
If you want to re-merge changes you've already merged once, you need to use the /force option.
