VIP Go environments

VIP Go platform specific

This document is for sites running on VIP Go.

Learn more

Overview #

Each instance of a VIP Go site is 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 and preprod environments allow you to test code changes and other functionality prior to deploying them on your site. Please note that we do not recommend making content or data changes in these environments as a part of your editorial workflow. Instead, we recommend using WordPress draft and preview features for content changes to your site.

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 approved by the VIP team after completing VIP code review. The code is available for your team to deploy after approval.
  • Data from production can be synced to the develop and preprod child environments.

↑ 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 uses git push to send the changes to the remote develop branch.
  4. Jane tests the new feature in the develop environment.
  5. Everything looks good, so Jane pushes the changes to a new (temporary) branch (add/new-feature).
  6. Jane creates a PR against master.
  7. The new code shows up in VIP’s Review Queue, is reviewed, and then approved.
  8. Jane merges the PR to master.

↑ Top ↑

Multi-environment architecture #

  • Each environment is running the same WordPress application under the hood
  • Each environment has its own database. That is required so that if something breaks in a preprod environment, it doesn’t affect the production environment. These environments are containerized in that way so it’s a separate entity
  • For files, we use a service called UnionFS that makes everything in the uploads directory on production available to the child sites. This means that clients don’t have to port their entire upload directory to all of their child environments.

↑ Top ↑

Differentiating environments in code #

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 pre-production' );

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.

Ready to get started?

Drop us a note.

No matter where you are in the planning process, we’re happy to help, and we’re actual humans here on the other side of the form. 👋 We’re here to discuss your challenges and plans, evaluate your existing resources or a potential partner, or even make some initial recommendations. And, of course, we’re here to help any time you’re in the market for some robust WordPress awesomeness.