Documentation VIP Go VIP Go environments

VIP Go environments

Overview #

Each instance of a VIP Go site in referred to as an environment.

All sites also have a production environment, where your visitors access the site and a develop environment where you check code before deploying to production. When your environments are running on VIP Go they will be using the same infrastructure as each other, so the caching control for a VIP Go develop environment is the same as for your VIP Go production environment.

All VIP Go developers should have a local environment on their machines for development and testing of bug fixes and new features. Note that your local development environment is separate from the VIP Go infrastructure, but should share the application code.

↑ Top ↑

Environments #

develop #

Any code pushed to the develop branch will immediately be deployed here.

↑ Top ↑

preprod #

This is meant as an additional QA environment and can be optionally requested for VIP Go sites. Any code pushed to the preprod branch will immediately be deployed here. (For some older sites, the preprod site tracks the master branch.)

↑ Top ↑

production #

  • Prior to your initial theme review, any code pushed to master branch will be immediately deployed here. More on the theme review process here.
  • Once the theme review is complete, the site is switched over to deploy reviews and any code pushed to master branch will be deployed by the VIP team after VIP code review.

↑ Top ↑

Deployment Workflow #

It’s up to your team to decide how best to integrate these environments into your workflow. One suggested workflow is as follows:

  1. Jane switches to the develop branch in their local environment.
  2. Jane writes code to build a new feature in their local environment.
  3. When ready, Jane git pushes up the their changes to the remote develop branch.
  4. Jayne tests the new feature in the develop environment.
  5. Everything looks good, so Jayne pushes the changes to a new (temporary) branch (add/new-feature) and creates a PR against master.
  6. Lee reviews the PR and works with Jane to fix up any remaining issues.
  7. Jane merges the PR to master.
  8. The new code shows up in VIP’s Review Queue, is reviewed, and then deployed.

      ↑ Top ↑

      Using VIP_GO_ENV to differentiate environments #

      We provide the VIP_GO_ENV constant, which is populated with the name of the environment. This allows you to conditionally load code on a particular environment, or to avoid a particular environment.

      Here’s an example of preventing code from running on production.

      $disallowed_debug_envs = array(
      if ( ! in_array( VIP_GO_ENV, $disallowed_debug_envs, true ) ) {
          error_log( 'Some debugging information can go here and will never run on production or staging' );

      Alternatively you can have code which only runs on production:

      if ( 'production' === VIP_GO_ENV ) {
          // This code only runs on production, perhaps 
          // configuration for a live service
      } else {
          // This code runs everywhere except production

      For your local development environment, you may wish to set the VIP_GO_ENV constant in wp-config.php. If the VIP_GO_ENV constant is not set explicitly, the value will default to `false`.

      The value of VIP_GO_ENV matches that in the site domain and also the branch tracked by that environment, e.g. the environment tracks the develop branch in Git, and has the environment name develop, therefore VIP_GO_ENV contains the string develop.

Documentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.