The Branch Concept – Powerful Tool To Control Your Product Lifecycle and Not Just Your Code
April 11th, 2016 Rami Azulay in Tip of the Week, QPack
This week’s tip expounds on the GitHub concept of branching, and ORCANOS | ALM. While working on a project, you will undoubtedly have a number of different features or ideas in progress at any particular time – Some of which are ready to go, while others are not. Branching allows you to better manage this workflow.
The life span of the R&D activity vs. the other parts of the product lifecycle have the same technical work style, but in different magnitudes. So as we discuss product definition, we conduct similar experiments as we do with our R&D activity. However, since it is less detailed and more functional, there are less daily activities than in R&D. Yet we need the same ability as the R&D to differentiate one release content from the next one to come out. GitHub does that extremely well by way of the Branch mechanism.
When you create a branch in your project, you are creating an environment in which you are free to try out new ideas. Changes you make on a branch do not affect the master branch, so you are free to experiment and commit changes, safe in the knowledge that your branch changes will not be merged until it is ready to be reviewed by someone you are collaborating with.
What this means, is that , when you are working on a product release, you firstly need a place where you can evaluate your content against the market needs, and secondly, against the possible implementation by the R&D. This ofcourse is an advantage of ORCANOS | ALM. It provides benefits that are lacking in the GitHub. This deficit causes a backlog of items in the pool area.
When a decision needs to be made about the content of your release, the ORCANOS | ALM branch mechanism should be considered. It gives you the option to create separate views (branches) for each release, and you are able to move/split/remove content from each view as needed. At the end of the day your view contains only the requirement, design, test, defects and so on, of that specific view.
Open a Pool Request
Pool Requests facilitates discussion about your new idea, while keeping design ideas in a pool. Because pool requests are tightly integrated within the underlying ORCANOS | ALM repository, anyone can see suggested changes, and how they would be merged, should they be approved.
You can open a Pool Request at any point during the development process: Whether you have few ideas or a single line description of your requirement, same can be shared as screenshots or general ideas.This approach is useful when you are stuck and need help or advice, or when you are ready for someone to review your work. By using ORCANOS | ALM @discussion system in your Pool Request message, you can ask for feedback from specific people or teams, whether they’re down the hall or ten time zones away.
Discuss and review your change request
Once a Pool Request has been submitted, the person or team reviewing your request for changes, may have questions or comments. Perhaps the requirement template style does not match project guidelines, the change is missing test data, or maybe everything looks great and commendations are in order – Pool Requests are designed to encourage and capture these productive conversations.
In ORCANOS | ALM you can also continue to push to your view/branch in light of discussion and feedback about your changes. If someone comments that you forgot to do something or if there is a logical bug in the requirement, design or test, you can fix it in your branch and push up the change. Similarly, the GitHub shows your new commits and any additional feedback you may receive in the unified Pool Request view.
The following flowchart demonstrates the basic concept of using the ORCANOS | ALM branch mechanism, in order to increase control of content delivery and quality.
