SilverStripe Platform may opt to perform different types of deployments depending on a number of factors, some of which you can control directly.
If any non-code changes need to be applied to your environment SilverStripe Platform will automatically force a “full” deployment.
In this scenario the virtual machines are rebuilt from scratch which opens up an opportunity to change the operating system, apply security patches, install packages, update
_ss_environment.php, and restart services.
Full deployment consists of the following actions (order may vary depending on your environment type):
- virtual machine build
- code deployment, running “dev/build”, and flush
- cycling the new machines into running environments
If the only change that needs to be applied to your environment project code change, SilverStripe Platform will elect to do a “code-only” deployment.
This deployment is much faster, as it will only deploy code, run “dev/build”, and flush.
When is a full deployment needed
SilverStripe Platform surfaces the changes made to your .platform.yml as line items in the deployment plan. If anything needs to change other than the “Code version”, a full deployment will be made.
There are situations however when a full deployment will be made even though no changes seem to be needed.
In most cases this will occur because of:
- your request for making changes to the
- your request for other customisations of the environment, such as applying whitelists, installing additional PHP modules or increasing PHP memory limits
- our tweaks to improve stability of your environment, such as changes to search engine robot handling.
If you are unsure why a full deployment is required please contact the Helpdesk.
Failures & rollbacks
In case of failures SilverStripe Platform will attempt to gracefully recover your environment. There are three kinds of failures that can occur during a deployment:
- virtual machine build failure (full deploy only)
- dev/build failure (DB migration problem)
- smoketest failure (site not responding, possibly due to code error)
Initial virtual machine builds are performed in sandboxed environments and failures during that stage will not impact running environments. The faulty machines are terminated and the deployment aborted.
Handling of “dev/build” and smoketest failures during a full deployment depends on your environment size.
On larger, scalable environments, the new machines are put into the target environment tentatively. Only after they report healthy the originals are removed. Failures at this stage will not affect your website as in most cases the new machines can be removed from the environment without affecting the originals.
On non-scalable stacks (such as solo) there is no opportunity to run original and new machines side by side. Failures during the “dev/build” and smoketesting always require a rollback to the previous working version. Outage duration is shortened by preserving the original machines so that the lengthy machine build step can be skipped.
Code-only deployment failures always trigger a rollback to previous code revision.