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.
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 a tagged version
Select a tagged version of your code base from the repository associated with your stack to deploy.
Deploy a specific SHA
Select a specific git revision from your code base from the repository associated with your stack to deploy.
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.
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:firstname.lastname@example.org/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.
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.
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.