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 hi@slashdeploy.io.
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).
/deploy acme-inc/api
To deploy the default ref (master) to a different environment.
/deploy acme-inc/api on staging
To deploy a branch (or git sha, or git tag) to the default environment.
/deploy acme-inc/api@branch
By default, all GitHub commit statuses will be checked before creating a deployment, you can disable this check by using the !
flag.
/deploy acme-inc/api@branch!
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 on 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 required_contexts
.
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 prod
.
required_contexts
was defined which need to move into the success
state in order to continue. For some reason, after about 1 hour of waiting, at least one of these required_contexts
are stuck in the pending
state instead of transitioning to success
, failure
, or error
. If you fix this issue your deployment will likely continue.