After you’ve created a site, you’ll need to deploy it somehow. The process for this differs between projects hosted on the HM Platform, and projects hosted on WordPress.com VIP.
Hosted on the HM Platform
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 Platform 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
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.
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.