As SlashDeploy is still in beta, the documentation here is subject to change and some parts may be incomplete. If you have feedback, please send it to firstname.lastname@example.org.
The easiest way to install SlashDeploy is to use our Add to Slack button:
This allows us to automatically install the
/deploy command as well as a
@slashdeploy bot user, which is used to send you notifications when deployments start and end.
Once SlashDeploy is installed into your Slack team, you'll have access to the
/deploy command. The first time you type
/deploy you'll be asked to authenticate with GitHub so that SlashDeploy can create GitHub Deployments on your behalf.
To deploy the default ref (master) to the default environment (production).
To deploy the default ref (master) to a different environment.
/deploy acme-inc/api to staging
To deploy a branch (or git sha, or git tag) to the default environment.
By default, all GitHub commit statuses will be checked before creating a deployment, you can disable this check by using the
To find out what environments you can deploy the repo to.
/deploy where acme-inc/api
SlashDeploy also allows you to "lock" environments. If for example, I wanted to test a migration on the staging environment, I can lock it with a message.
/deploy lock staging on acme-inc/api: I'm testing a migration
If any of my other team members try to deploy to the staging environment, they'll see the lock message.
/deploy acme-inc/api to staging
When I'm done testing my changes, I can unlock the environment so others can deploy to it again.
/deploy unlock staging on acme-inc/api
When I'm done for the day, I can release all my locks.
/deploy unlock all
You may configure SlashDeploy for your project by putting a .slashdeploy.yml file in the root of your git repository.
Here is a heavily commented .slashdeploy.yml example:
--- # teach SlashDeploy which environment is default. optional. # used when environment is not passed to a `/deploy` command. default_environment: production # a document of available environments for this repository. environments: # an environment named "production". production: # an optional list of aliases used to refer to the "production" environment. aliases: - prod # another environment named "stage". stage: aliases: - staging
You can configure SlashDeploy to automatically deploy a branch to an environment when you push code to GitHub.
If you utilize Github "Branch Protection Rules", you should likely use the same set of "Require status checks" under
This example .slashdeploy.yml file will automatically deploy the
master branch to the
production environment, once tests are passing on CircleCI:
--- environments: production: # Enable continuous delivery for this environment. continuous_delivery: # Specify any git "ref" (tag, branch, etc) to auto deploy when pushed to. ref: refs/heads/master # To deploy only after a set of GitHub commit statuses pass, # configure required_contexts (optional). required_contexts: - ci/circleci
Here we have some debugging information about the common issues and how to resolve them.
production, however the provided environment in the deployment event was
required_contextswas defined which need to move into the
successstate in order to continue. For some reason, after about 1 hour of waiting, at least one of these
required_contextsare stuck in the
pendingstate instead of transitioning to
error. If you fix this issue your deployment will likely continue.