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
wpcomviprepo. (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
wpcomviprepo 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).