0

How can Project X be released (merged to Master) without Project Y's changes?

Moving forward, should Solution A, B and C all be separate repositories moving forward (despite them relating at a business level)?

Scenario

We have a single repository which contains:

  • Solution A
  • Solution B
  • Solution C (Shared components)

Solution A and B both 'plug-in' to our overall System which connects them all together via common components. Solution A and B rely on shared components within Solution C.

Project X requires changes to Solutions A and C. These changes are done in feature branches, merged back into dev and continuously deployed into our Staging environment.

Project Y requires changes to Solutions B only. Again in feature branches, merged back into dev and continuously deployed to Staging.

Git History

At this point, our Git history looks like this (earliest to latest):

--> ProjectX --> ProjectY

The business requirement

The business no longer want Project X to go in to production, as Project Y is now 'priority 1'. No changes from Project X can be released.

Branching strategy

We follow the below strategy: enter image description here

Release strategy

We deploy full product packages, not differential.

On merging into Dev, Team Foundation Server deploys to Staging.

On merging into Master, Team Foundation Server supplies a formatted deployment package per build definition.

Community
  • 1
  • 1
ManxJason
  • 878
  • 10
  • 28

2 Answers2

2

I see you are referencing the standard 'git flow' branching strategy, as introduced with http://nvie.com/posts/a-successful-git-branching-model/ and is present in some form or another in many large projects.

Of note is the passage about the 'develop' branch:

[The develop branch] always reflects a state with the latest delivered development changes for the next release

and the passage about the feature branches:

The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).

Changes should not appear in the 'develop' branch until such time as they are confirmed for release. If your Project X has not got the go-ahead for release, it should not be present in the develop branch, and therefore you would have no issue releasing just Project Y.

So, in answer to your questions,

1) You could cherry pick your Project Y commits to apply to master. I don't recommend this as master is supposed to be a known stable state, and you won't have been testing an environment with Project Y but not Project X in it to confirm this. Instead, I would revert the Project X changes from develop (leaving them in the feature branch), retest and then merge develop into master.

Be careful reapplying the changes from the Project X feature branch into develop, as they will still have a merge history and it becomes non-trivial to reapply them - see here for an old discussion.

2) I believe separate repositories will not help you, if the projects will still span multiple repositories. In general practice, you should be fine with the structure as you have already. If the described scenario (last minute release block for a feature already in develop) occurs frequently, then your issue is with the approval process for changes into develop. Features with an uncertain future should be staged in their feature branches until release is confirmed. The cost (both time and risk) of backing out changes after confirming them must be made clear to the business.

practual
  • 2,197
  • 2
  • 9
  • 12
1

in my point of view you should seperate a, b and c into three seperate repos / projects. a and b should reference c as dependency.

project x will have a as direct dependency and c "via" a. project y will have b as direct dependency and c "via" b.

you ca continue developing new features for project y and solution b without any impact to project x. unless you make changes to solution c which may change impl of solution a and/or solution b.

ps: i know this answer is not a real "solution". but maybe a kind of "confirmation" what you already know. or an "encouragement" to do things you ever wanted to change. :-)

Christoph-Tobias Schenke
  • 2,962
  • 1
  • 9
  • 17