How should I support and continue development on a forked application?

Question

We have a large application that runs at roughly 5 locations. None of these locations are running the same version of the application. This makes patching and updating very complicated.

Try to follow this example: We'll call the application I'm talking about "application A". Now we want to roll out an application B to one of these locations and it must implement application A. We'll have to modify A to accept B's requirements. However, our development version of A (the version that eventually each location will have) must have support for B as well. This means we have to rollback to the state of the software running on the site requiring B as well as make these changes to our development version of A. This also means that the 4 other locations are implementing a version of A without B support.

So one can see where it gets frustrating to control the versioning. If we want to support sites 2-5 we can't use our development version of the source, we have to rollback to the specific version on that site. What's the best way to do this? Keep in mind we're using Visual Studio 2008 and Team Foundation Server.

Answer 1

The first thing I would recommend is to refactor your app to all use the same version of the core product.

Try to logically break out specific functionality into their own modules and access that functionality through an adapter type pattern.

Answer 2

John points out a crucial first step. Nothing good can happen until your code base is internally stable.

But even after you split your app into reusable components with well-defined interfaces, you will likely still have to maintain multiple versions ("forks") of many/all those components and develop their releases in parallel. That's where branching comes in.

I highly recommend reading the new TFS Branching Guidance papers cover-to-cover. I was quite critical of earlier revisions, but the documentation team has really improved their offering here. (thanks in part to additional feedback as TFS finds broader adoption...but in equal part to finally paying attention to established SDLC norms that far predate Microsoft's entry to the marketplace)