GitHub pull request flow

GitHub’s code review tools include:

• Inline commenting on code, making reviews easier to follow, and sharing feedback more directly.
• More control over deployments to production. Code is deployed right after merging, so developers have control over staging changes and deploying whenever they are ready.
• Rollbacks/reversions with the GitHub one-click method to revert pull requests.

GitHub flow is a branch-based workflow that streamlines reviews and deployment. This is a what a typical flow looks like for a production environment tracking the production branch:

1. To work on a bug fix or new feature, create and switch to a new branch locally.
2. Develop, make changes, commit, and as desired push up the branch.
3. When the branch is ready for code review, open a pull request (PR) against the production branch.
4. All Pull Requests to the production branch will be automatically scanned by the VIP Code Analysis Bot against VIP Coding Standards. Customers with Application Support can optionally add the [VIP] Review Request label to request manual VIP code review. VIP Code review is optional and not required for merging to a production branch.
5. Once all issues reported by the VIP Code Analysis Bot or changes requested by the VIP team have been addressed and approved, the branch may merge to the production branch at the customer’s convenience. Merging to the production branch triggers an automatic deployment to the production site. GitHub has documentation on how to merge a pull request.

GitHub allows any number of approvals against a pull request, so teams can also utilize this approvals workflow if desired. Note, however, that GitHub will allow users to merge a pull request to the deployment branch once the pull request has any approval from either the customers or the VIP team.

If there are any issues with the deployment, GitHub provides a one-click option to “revert” pull requests.

Occasionally, a pull request may be blocked from merging into the destination branch, even after a VIP Support team member has approved the pull request’s changes. If that happens, check to see if there are previous stale reviews that should be dismissed using Github’s web interface. Github documentation has information about how to dismiss a pull request review.

GitHub workflow for non-production environments

Non-production site(s) and workflow(s) remains as-is. For example, merges to the develop branch deploy automatically to the develop site without VIP involvement.

It’s up to your team to decide how best to integrate your VIP environments into your workflow, but we highly recommend following the above GitHub Flow for non-production environments as well. An example workflow with a develop environment could look something like:

1. Create local feature branch (add/new-feature).
2. Develop, test, commit changes.
3. Push up changes to new remote branch.
4. Create a PR from the remote add/new-feature branch against the develop branch.
5. (Optional and recommended) Internal team code review.
6. Merge PR and test on develop environment.
7. If everything looks good, create a PR from the remote add/new-feature branch to the production branch.