This project has moved and is read-only. For the latest updates, please go here.

Rolling Release as a component of a Periodic Release

May 9, 2013 at 3:37 PM
Edited May 9, 2013 at 3:48 PM
First, I'd like to thank you for the excellent documentation. It's proved invaluable lately.

We're responsible for deploying a web application that contains customizations (via a single compiled DLL). That is, many of our customers have very unique business rules which they cannot change, but which we do not wish to directly support in our product due to the added complexity and/or the limited marketability.

Our web application is released about every two months (periodic release), but these customizations are developed, tested, deployed, fixed, tested again, redeployed (etc) as often as ten in one day.

The branch structure we're using is (somewhat simplified):
/Main
-/Source
--/BusinessObjectLayer
--/WebApplication
--/Customizations

We're currently using the standard branching plan in this fashion:
Feature Dev (opt) <- Dev <- Main -> Release
(we will likely add the Service Pack strategy soon)

Each of those branches is a branch of the Main/Source, so each branch contains its own copy of the Customizations project. That means Release1 has its own copy of Customizations, Release2 has its own copy, &c.

This structure is causing some issues.

One issue is that, if a customer is on Release1 and discovers an issue with their customization code, developers are modifying that code IN THE RELEASE1 BRANCH. This isn't a huge deal, since we're a small team and they're responsible enough to not modify anything outside of that project, but I feel that it is only a matter of time before somebody slips up. Note that the Customizations project does NOT undergo QA.

Another issue is the merging problems. If a developer adds a new class file (customizations for our clients are stored in a unique namespace, classes separate the customizable bits by feature) to Release1, that results in a change to Customizations.csproj in that release. If another developer adds a new class file to the Customizations project in Release2, we now have multiple .csproj edits... often further confounded by some of the developers leaving the .csproj checked out for too long. When merging these changes (RI to main, then FI to latest release) Visual Studio often wants to delete items that shouldn't be deleted (I'm not at all sure what the root cause of that is). I think that disabling shared checkout on .csproj might alleviate much of this issue.

Finally, we occasionally make edits (signature changes, etc) to the Customizations project and related objects in the other areas. That essentially ties the Customizations to a minimum version of the entire solution (I'm not certain that makes sense, please let me know if additional clarification is needed). This is not a problem currently (since each branch contains its own copy of the Customizations project), but will be important to consider when suggesting different approaches.

Any thoughts on structuring this differently? Or could this be handled more easily with a bit of developer training and TFS configuration?

[edited for spelling/grammar typos]