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:password@my.site.com/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.

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 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.