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.
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.
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.
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.
By default, all repositories are set up with basic GitHub branch protection rules. The rules are intended to prevent unapproved changes from deploying to a production environment. Only GitHub users with
admin permissions have the ability to modify the branch protections rules.
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.