This is a best practices question for release management of an app. But this scenario is a bit different than what I've been able to find myself.
Essentially my company maintains a fork of its own app. There are two versions of the app that will have different configurations of bug fixes / features. These fixes and features come from a common pool of what's completed. The reason for the two configurations is that there are two main testing environments with different goals.
Let me explain that a bit more with a scenario:
- We have features 1, 2, & 3 and bug fixes 1, 3, & 3 being worked on at the same time by different devs.
- For the upcomming releases to QC, Config-1 of the app wants to include feature 1, and bug fixes 1 & 2, and Config-2 wants to include features 2 & 4.
- For subsequent releases to QC, certain features may get rejected as being incomplete, buggy, no longer needed, etc. And same with the bug fixes.
#3 is important because not all features get removed or synced between the two configurations. This means that the two configurations diverge slightly over time. But only in the short term for what's in active development. Over the long term, the code base is in sync with what's in production.
So, as a diagram, the builds could look like this over time (with some added features / bugs from the bulleted scenario above):
Basically a normal development life cycle, but with twin timelines. There's the main app, and a fork of it that's derived merely by a different combination of the available patches. Patch queues would work well but we use a build server to produce the builds which requires us to publicly push committed changes (as far as I can figure out) to a remote repo.
My question is really about what the easiest way to manage this is, at the actual source control level. What we've done in the past is (using Mercurial) maintain two repositories (one per configuration) and all features / bugs would get imported as needed as patches. Removing items would be done using a variety of ways, backouts probably being the most common. The problem with this is that the two repos ended up wildly different from each other with different items being applied at different times. So the entire changeset stack would be a different order.
What we're thinking about doing, is still maintain two separate repos, but every effort (features, bugs) would be developed as a branch and that branch gets pushed to the repo it's needed in. Within a given repo, if the branch is wanted in the upcoming build, it gets merged in the build branch which is monitored by our Jenkins server and produces the builds.
Is there a better way? An ironed out best practice that prevents messy build branches as a result of backing out items, and possibly even other issues that we don't know about yet?
