tl;dr

Deploy a branch called 'staging' to a server called 'staging' with a Slack slash command:

/gitlab deploy staging to staging

Overview

If you're using GitLab as your CI build system, and Slack for your team communications, you can invoke deployment commands directly from Slack.

Deploys are defined as jobs in specific environments in GitLab, so that different branches (or tags) can be deployed to different servers.

The format of the command is slightly clumsy, because of the way that the GitLab integrations work - and only a small number of commands are supported, 'deploy' being one of them. (See others here).

Define deploy jobs for branches

The deploy stage for a GitLab build is defined in the '.gitlab-ci.yml' file. The file might look something like this (simplified):

stages:
  - test
  - deploy

test:
  stage: test
  environment: $CI_COMMIT_REF_NAME
  script:
    - ./bin/test.sh

deploy:
  stage: deploy
  environment: $CI_COMMIT_REF_NAME
  when: manual
  script:
    - ./bin/deploy_to_server.sh $CI_COMMIT_REF_NAME

Note that the stages both have an environment defined - this is what GitLab uses to create entries in the environments list for the project, which is where it keeps track of which commits have been deployed to which targets.

The environments here are named with the $CI_COMMIT_REF_NAME variable, which is set to the name of the branch that is building - so the build will create an environment for every branch, with jobs called 'test' and 'deploy'.

You can see all the environments for a project - go to 'CI/CD' -> 'Environments'.

The 'test' job will run automatically during the build, but the 'deploy' task won't, because it's labelled as 'manual'. You could run the 'deploy' task from the GitLab UI (a button labelled 'Manual' on the Jobs page) once a successful 'test' job has finished.

That 'deploy' job is the one that we're going to invoke from Slack.

More about invoking deploys

The format for invoking a deploy remotely will be

deploy <source-environment> to <target-environment>

The way that GitLab invokes a deploy is slightly convoluted - when triggered, GitLab will look for the 'source-environment' name in the environments which has had a successful build, and identify a manual deploy step in that same build with environment 'target-environment' - which it then invokes.

Setup GitLab/Slack integration

Now that the build has a deploy job that can be manually invoked, you can set up the integration with Slack.

Starting in GitLab, go to the 'Slack slack commands' integration page (Settings->Integrations->Slack slash commands).

That will give you instructions for configuring the slash command over in Slack, and a link to take you to the setup page in Slack:

You won't have a 'Token' yet - that will be supplied by Slack once you've setup the slash command.

Keep this page open, ready to paste in the Token.

Click the "Add a slash command" link to go to the Slack setup page, and choose a name for the slash command (e.g. '/gitlab'):

After clicking 'Add Slash Command Integration', you'll get the configuration page - paste in the URL for the command, taken from the page of instructions in GitLab:

Keep this page open, but take the 'Token' from here, and paste it into the 'Token' field on the configuration page for the integration, back in GitLab, and save the settings there.

Back in the Slash command setup, give it some Autocomplete Help Text, which will appear in Slack when someone starts typing with a '/'. Save the integration.

Make sure that your build has run successfully at least once for any branch that you're trying to deploy, otherwise the environment won't have been created yet, and the deploy job won't be found.

Note

This is similar to my previous post about deploying using Jenkins.

In this case, though, GitLab provides more integrated support for Slack slash commands which trigger deploys, so the integration method is different..