GitHub flow on the VIP Platform

The infrastructure of the VIP Platform is built to support a “Code moves up; content moves down” development workflow (e.g. develop → production for code development).

Development teams should confirm in non-production environments that new code is error-free and working as expected before the code is deployed to the production environment.

GitHub flow on non-production environments

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

Read more about the Repository Management panel

Example steps that demonstrate the GitHub flow for developing a new feature on a non-production environment that has a deploying branch named staging:

1. Git clone the application’s GitHub repository to the user’s local machine.
2. Switch to the staging 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 staging 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 to the deploying branch and test the new feature on the non-production environment.

Read more about merging a pull request on GitHub.com

GitHub flow on production environments

After code has been successfully tested and approved on a non-production environment, you can follow these example steps for using the GitHub flow to release a new feature to a 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.

Read more about code deployments on a VIP Platform environment

Rollbacks

If issues occur related to a deployment, GitHub has a one-click option to “revert” a pull request.

A faster alternative to reverting a pull request in GitHub is the rollback option in the VIP Dashboard.

When a rollback is performed, an existing image of the selected, previous code deployment is deployed to the environment. A rollback only deploys the image of the application code’s previous state to the environment. The state of the application’s GitHub repository commit history and the environment’s database remains unchanged after a rollback.

For this reason, the code in the deploying branch that caused the issue must be fixed, committed, then pushed to the environment as soon as possible to prevent the bad code from being re-deployed.

Read more about rollbacks in the VIP Dashboard