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 "Applicatio n", so while the code was frozen for the "Release" the code is still changing in "Applicatio n", 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 "Applicatio n" 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 "Applicatio n" is developed, and we want it also in "Applicatio n2", 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 "Applicatio n2", "Applicatio n" 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 "Applicatio n" and "Applicatio n2".
What we're doing now is developing "Applicatio n" and "Applicatio n2" 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 "Applicatio n2" was branched out of "Applicatio n".
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!
(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 "Applicatio n", so while the code was frozen for the "Release" the code is still changing in "Applicatio n", 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 "Applicatio n" 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 "Applicatio n" is developed, and we want it also in "Applicatio n2", 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 "Applicatio n2", "Applicatio n" 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 "Applicatio n" and "Applicatio n2".
What we're doing now is developing "Applicatio n" and "Applicatio n2" 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 "Applicatio n2" was branched out of "Applicatio n".
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!
Comment