GitHub pull request flow

The GitHub flow is strongly recommended for developing code for new features, bug fixes, and testing. By using the GitHub flow, developer teams can more effectively collaborate and more confidently deploy new code to production environments.

The GitHub flow is a branch-based workflow that requires peer code reviews in a pull request. This provides:

• Inline commenting on code, making it easier for developers to share feedback more directly and follow reviews.
• More control over deployments to environments. Code is deployed right after a pull request is merged, so developers have control over staging changes and deploying whenever they are ready.
• GitHub’s one-click option to “revert” a pull request if issues occur related to a deployment.

In the GitHub flow, a new branch is created and the new code is developed in that branch. When the code is ready for review from other team members, a pull request is created against a branch that deploys to a non-production environment.

The team communicates in the pull request, sharing feedback on the new code and making requests for changes. Once the pull request is approved, it can be merged to the deploying branch. Merged code automatically deploys to the non-production environment, where additional testing and quality assurance (QA) can be performed.

GitHub flow on non-production environments

WPVIP’s infrastructure is built to support a “Code moves up; content moves down” development workflow (e.g. develop → production). Development teams should confirm in non-production environments that new code is error-free and will work as expected before the code is deployed to the production environment.

To reduce potential merge conflicts, create the new branch from the branch that deploys to the non-production environment that will be used for testing. The deploying branch for an environment can be identified—as well as updated—in the Repository Management panel of the VIP Dashboard.

Example steps for feature development using the GitHub flow on a develop environment that has a deploying branch named develop:

1. Git clone the application’s GitHub repository to the user’s local machine.
2. Switch to the develop branch.
3. Create a local feature branch (e.g. add/new-feature).
4. Develop, test, and commit changes to the local branch.
5. Push up the changes to a new remote branch.
6. Create a pull request from the remote add/new-feature branch against the develop branch.
7. Request a code review from other members of the development team. The pull request will also be automatically scanned by the VIP Code Analysis Bot against VIP Coding Standards. Respond to all feedback (from peers and the Bot) by making new commits until the pull request is approved.
8. Merge the pull request and test the new feature on develop environment.

GitHub flow on production environments

Example steps using the GitHub flow for releasing a new feature to a production environment after it has been successfully tested and approved on a non-production environment:

1. Create a pull request from the remote add/new-feature branch to the production branch that deploys to production environment.
2. Request a code review from other members of the development team. The pull request will also be automatically scanned by the VIP Code Analysis Bot against VIP Coding Standards. Respond to all feedback (from peers and the Bot) by making new commits until the pull request is approved.
3. Merge to the production branch to trigger an automatic deployment to the production environment.

If issues occur related to a deployment, a rollback to the image of a previous deployment can be performed in the Deployments panel of the VIP Dashboard for an environment. Performing a rollback in the VIP Dashboard has no effect on repository code. The cause for the issue should be identified and fixed before any further code is pushed to the environment.

Required approvals

GitHub repositories can be configured to require a specific number of approving reviews before a pull request can be merged.

By default, even if branch protection rules require approval(s) for a pull request to be merged, GitHub users with Admin permissions for that repository can override the requirement and merge a pull request at any time.

Deactivated merge button

Branch protection rules can cause the merge button to remain deactivated until all reviews pass or are dismissed. Check if any previous reviews from the VIP Code Analysis Bot (or another reviewer) still needs to be addressed or if a review can be dismissed. Github documentation has instructions for dismissing a pull request review.

Automated code reviews

For WordPress applications, the VIP Code Analysis Bot runs automatically on open pull requests (targeting any branch) when the pull request is opened or following any new commit. Depending on the size of the change, it may take a few minutes for feedback from the Bot to appear. If no issues are detected in the automated scan, no feedback or messages will be added by the Bot.