Deploys

Hosted on HM Cloud Hosted on HM Cloud

For projects hosted on the HM Platform, all deployment is handled internally, and developers have the ability to self-deploy when necessary.

Deployments are created from Vantage, and follow the HM Cloud deployment process. This allows build tools to be integrated into the .build-script, so generated files (minified JS, etc) should not be committed into the repository.

While code does not have to pass through multiple levels of review like the VIP deployment process, all code must be reviewed before merge to ensure code quality in any case.

Hosted on WordPress.com VIP Hosted on WordPress.com VIP

VIP projects follow an entirely different deployment process. This is slightly different between VIP Classic and VIP Go, but mostly follows the same process.

Code pushed into master is pushed into a “deploy queue” internally, and the VIP team reviews this typically within a day (potentially faster depending on the SLA for the project). After review, VIP will then deploy this code at their discretion.

Deploys can be scheduled if necessary, but should typically be avoided.

Deploying is a multi-step process, as code needs to be submitted from our Git repository to the VIP SVN (for VIP Classic) or Git (for VIP Go) repository for the site. ZenDesk should also be monitored for post-deploy messages from the VIP team, which may note warnings that should be fixed, but which aren’t blockers.

VIP Go VIP Go

During development, other environments can be used to set up development or staging sites. With these secondary environments, code is automatically deployed upon pushing code.

Keep an eye out for changes on the Go repository from the WordPress.com VIP team that may need to be applied to the canonical internal repository. This may appear unexpectedly in the diff when synchronising code across, and will require porting across to the main repository before deploy.

If you need the ability to deploy built code (such as JS/CSS bundles), it’s best to use the VIP Go Builder tool. This avoids needing to commit the built code, and ensures these files don’t constantly cause merge conflicts.