Traceable branch isolation of planned work

[qodfathr]

When new content creation work is assigned (e.g. code a new feature or design a UI mockup), there are differing schools of thought on how to best address branching in the context of distributed version control. These include differing practices such as continuous integration, promiscuous integration, feature branches, feature toggles and branch by abstraction to name just 5. None of these practices is perfect; each handle certain situations well and introduce complexities when facing other situations.

As a best practice, there is a healthy compromise which involves aspects from many of these individual practices.

Experience

In the Planner, work to be done has been created as work items and assigned to an individual. This work is typically a Feature, Requirement or User Story, depending upon the Space template used to create the Space. These are all Requirements-level work item types in the Planner's guided type navigation system.

When the assigned user is looking at one of these items, they should be able to indicate that they would now like to start working on it. This goes beyond simply changing the work item state to be one of the in progress states, but instead should be a more definitive action such as pushing a button or making a selection from a context menu. This action should be available in the backlog view, the work item details view, and and board view. UXD to specify the precise experience This has been previously referred to as the Do it button

When the user indicates that they are starting to work on the feature, the service presents them with the option to create a new branch for their work. There will be a traceable link between the work item and the branch, such that a user many easily navigate between the two. If a user returns to the work item at a later date, they should be able to easily return to the context of the branch.

Once the user has made their branch selection (either creating a new branch or perhaps reusing an existing branch -- including master), they are immediately launched into an appropriate editing experience. Today, the only choice is Eclipse Che, but in the future this should be more customizable and context aware (e.g. perhaps a web-based UX design tool or even a desktop IDE). More importantly, that editing experience should now be aware of the selected branch context. For example, if sent to Eclipse Che, the Che workspace should be cloned off of the selected branch rather than blindly using master.

UXD help needed here
Branching will have an impact on several other areas of the service.

• Codebases: how are branches represented for a codebase, and which actions are permissible?
• Workspaces: how are branches represented for a workspace, and which actions are permissible?
• Pipelines: does creating a new branch also create a new pipeline? If yes, how is the pipeline template selected? May it be changed? To where does it deploy? Does the deployed app have a special name or signature which connects it back to the work item?
• Deployments: if I have an app myapp deployed, and I also am working on isolation for work item # 646, do I see on the deployments screen the various deployments of my app, even if in the same environment? e.g., does Stage contain both myapp and myapp-646?
• Is there a generic way for a user to create branches without starting with a work item? If yes, how are all of the above listed items impacted?

From a traceability standpoint, there should be an easy to navigate path between all of these interrelated artifacts. For instance, it should be easy to look at a work item I and say "Misha is assigned to I. In fact, she's already working on it. Her code is here in branch B. Oh and she's deployed out the current version of her work as an app -- and here's a URL if you want to look at the running version of her work in progress."

Overall, this probably looks and feels like Feature Branching. There is nothing here that prohibits either Continuous Integration or Promiscuous Integration, provided that the service also does not impede (and ideally simplifies) the ability for a user to merge between selected branches. Moreover, if, when starting the work, rather than creating a new branch, master is selected, this is effectively a purist version of Continuous Integration. Lastly, making use of Feature Flags is essentially orthogonal to the branching strategy.

Implementing Features

Parent Scenario

#2169 Development teams desire to adopt best practices

[qodfathr]

@catrobson lots of UXD help needed on this one. This is basically the do it button.

[qodfathr]

cc: @slemeur

[AdamJ]

InVision Link for UXD Design: https://redhat.invisionapp.com/share/YKGNREEH8VZ

[qodfathr]

Moved to OpenShift.io: https://openshift.io/openshiftio/openshiftio/plan/detail/1982