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 wpcomvip 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

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.

The deploying branch of a production environment can incorporate a GitHub Pull Request workflow review stage for 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.

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.

Logs for an environment’s builds and deploys are available in the VIP Dashboard.

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: August 01, 2022