Deployment options

When deploying you can choose a number of different options, such as to promote from UAT or deploy a specific tagged version from your code repo.

Standard options

These are the most commonly used deployment options.

Deploy the latest version of a branch

Select a branch from the repository associated with your stack and deploy the latest version of it.

Deploy the latest version of a branch

Deploy a tagged version

Select a tagged version of your code base from the repository associated with your stack to deploy.

Deploy a tagged version

Deploy a specific SHA

Select a specific git revision from your code base from the repository associated with your stack to deploy.

Deploy a specific SHA

Redeploy the current version on this environment

Redeploy the git revision currently deployed to the stack. This is often used for full deployments if you only want to change a whitelist, env vars etc but not the code base.

Redeploy the current version on this environment

Advanced options

More fine-grained control over the deployment process.

Deploy a tar.gz package

Provide a URL of a hosted tar.gz package which you wish to be deployed. You can enter HTTP auth or GET parameters at this stage, so your packages don’t need to be publicly hosted. i.e. https://username:[email protected]/path/to/my/package.tar.gz or my.site.com/path/to/my/package.tar.gz?secret-token=12345abcd. Note that HTTP auth or GET parameters entered are not stored in the Silverstripe Cloud database, they are only used for the life-cycle of the request to retrieve the package. The package is stored on Silverstripe Cloud but cannot be guaranteed to be stored there indefinitely.

Deploy a tar.gz package

When using this option the regular build scripts are skipped and the package is deployed directly to your stack as-is but a dev/build is still run.

Deploy a previously used tar.gz package

Select a previously deployed package you deployed by using “Deploy a tar.gz package” to redeploy.

Deploy a previously used tar.gz package

Backup database before deploying

This is enabled by default on production deployments. When enabled this takes a of the current database. This is helpful to ensure you can always fully rollback your releases on the off-chance a database breaking issue is caused.

Was this answer helpful? Yes No

Sorry we couldn't be helpful. Help us improve this article with your feedback.