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 dashboard database, they are only used for the life-cycle of the request to retrieve the package. The package is stored on the dashboard 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 snapshot 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.
Force full deployment
Forces a full deployment where a code-only deployment would have occured.
Force code-only deployment
Forces a code-only deployment where a full deployment would have occured.
Force rebuild of codebase
When a SHA, branch or tag is deployed, the codebase is built by running a number of commands (i.e.
composer install). This built codebase is stored and reused each time the same SHA is deployed. This option forces the build process to occur again, rather than using the existing built version of the codebase. This can be useful if the build process succeeded but with an anomaly.