Two teams working on a single project with a shared application base

[eshedz]

Hello everyone,

(if this is not the correct forum please direct me to the right place)
(we work with TFS)
(the names in bold are just examples)

My team has been working on a project that is separated into two parts:
* A Common branch that is rarely changed and is the very base of our application.
* An Application branch that is under development and is constantly changing because of feature development or bug fixes.

Whenever we prepare to release a new version we branch both parts as a new branch called Release which we release to the QA team for testing. The "Release" branch is created along side the development of "Application", so while the code was frozen for the "Release" the code is still changing in "Application", due to the continuation of the development.

So, when the QA team discovers bugs we fix the code in "Release" and then "merging-back" the code to the "Application" branch, which is as I said before constantly changing. That way, we make sure the bug is fixed in both versions without doing the work twice.

If that's the right way to work or not is not the discussion here, but this is:

Recently we started working on a parallel project called Application2 with the same structure (based on "Common") that was branched-out from Application. So now we need to work simultaneously on two projects that are constantly changing with a shared "Common", both have similar features that require synchronization but are not under the same development scale and are released and tested on different dates and paces.

We now have an unideal situation: Whenever a new feature in "Application" is developed, and we want it also in "Application2", we'll have to merge the two projects and continue from there. And, if we fix or alter a critical part of the system in "Application2", "Application" also needs that change so we merge again but the other way around.

We can't take out more parts of the software to "Common" because it's an integral part of both "Application" and "Application2".

What we're doing now is developing "Application" and "Application2" separately until we need to merge certain features or changes, in which cases we work for days merging everything because the two projects were dramatically altered since "Application2" was branched out of "Application".

Aside from the massive headache we have performing that merge every now and then, this really feels like the wrong way to work.

Can someone think of a good way to solve our problem or a smarter way to develop?
"Starting over" is not an option.

Thanks!

[RedSon]

It sounds like your common base has effectively become a "vendor branch" it releases its common code to two separate projects. No longer will your common tree release in lockstep with your application, since it has another "customer" to worry about.

We are facing this same issue on my project. Where we have one common tree that is used by several related projects. My solution was to use an external pointer to the common code and pull it into the project source. The common code would never have any release because it is not a complete component. It needs to be put into a project to be used. Each project would use the latest development tip of the common code.

Another way to do this is for the common tree to "release" binaries to each project. And make the project responsible for integrating it into their code base. This is a common "vendor" style interaction. I don't like that because I prefer to use all the source code all the time. I would rather build the common code myself than have someone build it for me and hand me a dll.

It is a tough decision to make. Because you also have to consider how to test your common code independently of your applications.