Skip to content

How-to Guides

Technical References

VIP Codebase /

Developing in the GitHub repo

How does the code get deployed?

Each VIP Go site or environment tracks a specific branch of your repository. For example, the production environment will track the master branch; if you have requested other sites they will each have a specific branch they are tracking.

If you have a child environment, the branch will always auto-deploy. For the production environment, the master branch may be enabled with a GitHub Pull Request workflow which incorporates a review stage on pull requests. Merged pull requests and direct pushes are then deployed.

Build and deploy

Code committed to your environment branches should contain all needed assets. On deploy, no additional building is done except for submodule includes. So if you are using composer, for example, you should commit code only after running composer install, or consider using CI/CD automation to do that.

If you are using VIP’s available CI/CD (built branches) your changes in master (once merged) will first be built in Travis or CircleCI and then pushed directly from there to your master-built branch. Then that will be deployed automatically.

Plugins on VIP Go

See our separate document on installing and activating plugins on VIP Go.


See the separate document sunrise.php on VIP Go.

Developing from another repository

If you choose to develop in a separate repo before pushing to the VIP repo, here are a few things to consider:

  • The VIP team may occasionally need to push security/performance related hotfixes to your wpcomvip repo. (We usually do these through PRs for greater visibility.) It’s important that you have a process in place that merges the changes back to your main development repo.
  • It’s probably a good idea to have your development repo mirror the structure of your wpcomvip repo directly to minimize complexities when pushing/pulling between them. Similarly, it’s a good idea to sync all commits as well (instead of doing large batched commits).
  • When syncing with pull requests, be sure to review these in GitHub for automated code scanning comments added by our automation that may be flagging possible PHPCS issues.
  • For external dependencies (e.g. plugins), you can use submodules or subtrees (although, note that private submodules are not supported, and public submodules you do not control are discouraged).

Last updated: October 07, 2020