GitHub Pull Request workflow

GitHub’s code review tools are excellent. There are many benefits to your team and to VIP in using GitHub directly for code review, including:

• Inline commenting on code, making reviews easier to follow, and sharing feedback more directly.
• More control over deployments to production. You can choose to merge when you’re ready for the code to be deployed, allowing you to stage changes and deploy when your team is ready.
• Simplified rollbacks/reversions with the GitHub one-click method to revert Pull Requests.

GitHub Flow is a branch-based workflow that streamlines reviews and deployment. The diagram above describes the workflow:

1. When you want 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 your branch is ready for code review, open a Pull Request (PR) against the master branch (for production sites).
4. All Pull Requests to master 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 your 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, you may merge to master at your convenience. Merging to master 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 your team can also utilize this approvals workflow if desired. Please note, however, that GitHub will allow you to merge your PR to master once the PR has any approval from either the client or the VIP team.

If there are any issues with the deployment, GitHub provides an easy, 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. The Github documentation has information about how to dismiss a pull request review.

GitHub Workflow for non-production environments

Your 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 to develop.
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 master.