Skip to content

Development workflow

An application’s code on the VIP Platform can only be modified using a version-controlled GitHub development workflow. There is no SFTP access to an application’s code or other related assets.

An application is supplied with a GitHub repository within the wpvip GitHub organization. Each of the application’s VIP Platform environments tracks a specific branch of its GitHub repository. 

Due to security concerns, GitHub and OAuth Apps cannot be added to these repositories.

When developing code locally that requires Node.js—such as plugins or themes for a WordPress application—it is recommended that Node.js on the local development is maintained at a Long Term Support (LTS) release version. The resulting artifact from code built locally is then committed to the application’s GitHub repository as static assets. Node.js is not run on VIP WordPress environments.

Code deployment

For the production environment, the deploying branch can be enabled with a GitHub Pull Request workflow to incorporate a review stage on pull requests. Merged pull requests and direct pushes are then deployed.

Additional child environments will each have their own specific GitHub branch they are tracking. Commits made to a branch that deploys to a non-production environment will always auto-deploy.

Deployment typically takes two to five minutes, but this time can vary depending on the size of a codebase and any additional Continuous Integration (CI) tasks that are configured for an environment.

Update the name of the branch deploying to production

By default, the production environment tracks to a branch named master. The name of this branch can be changed by completing each of the following required steps:

  1. Create a new branch from the branch currently deploying to production with the desired name.
    Use the Git CLI or manually create the new branch in the repository.
  2. Create a request with VIP Support to update the branch that tracks to production. Include the desired name of the new branch that should replace the existing branch deploying to production.
  3. Wait for VIP Support to confirm that the branch naming and environment tracking update is complete.
  4. Update the repository’s default branch in Github by following these instructions
  5. The previous branch must be removed by the customer.
    1. Clone the wpvip GitHub repository to a local machine: 
      git clone
    2. Enter the repository on the local machine:
       cd REPO_NAME
    3. Delete the old branch:
      git push origin --delete master
      git branch -d master

Build and deploy

Code that is committed to a WordPress environment’s deploy branch should contain all needed assets. On deploy, no additional building is done except for submodule includes. When using composer, for example, code should be committed to a branch only after running composer install. An alternative to this is to set up an automated build and deploy method.

For branches already set up with automated build and deploy (-built branches), merged changes to a develop branch, for example, will first be built in Travis or CircleCI and then pushed directly from there to the develop-built branch. The built code will then be deployed automatically.

For Node.js environments, there is a build step and certain other requirements. Code changes will only deploy (and replace any existing running code) if that code is successfully built. Review the requirements carefully and test them locally before merging to a production branch.

Last updated: April 22, 2022