GitLab Documentation

Deploy Boards

Introduced in GitLab Enterprise Edition Premium 9.0.

GitLab's Deploy Boards offer a consolidated view of the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes.

Overview

With Deploy Boards you can gain more insight into deploys with benefits such as:

Here's an example of a Deploy Board of the production environment.

Deploy Boards landing page

The squares represent pods in your Kubernetes cluster that are associated with the given environment. Hovering above each square you can see the state of a deploy rolling out. The percentage is the percent of the pods that are updated to the latest release.

Since Deploy Boards are tightly coupled with Kubernetes, there is some required knowledge. In particular you should be familiar with:

Use cases

Since the Deploy Board is a visual representation of the Kubernetes pods for a specific environment, there are lot of uses cases. To name a few:

Enabling Deploy Boards

To display the Deploy Boards for a specific environment you should:

  1. Have a Kubernetes cluster up and running.
  2. Configure GitLab Runner with the Docker or Kubernetes executor.
  3. Configure the Kubernetes service in your project for the cluster. The Kubernetes namespace is of particular note as you will need it for your deployment scripts (exposed by the KUBE_NAMESPACE env variable).
  4. Ensure a Kubernetes label of app: $CI_ENVIRONMENT_SLUG is applied to the deployments, replica sets, and pods, where $CI_ENVIRONMENT_SLUG the value of the CI variable. This is so we can lookup the proper environment in a cluster/namespace which may have more than one. These resources should be contained in the namespace defined in the Kubernetes service setting. You can use an Autodeploy .gitlab-ci.yml template which has predefined stages and commands to use, and automatically applies the labeling. Each project will need to have a unique namespace in Kubernetes as well. The image below demonstrates how this is shown inside Kubernetes.

    Deploy Boards Kubernetes Label

Once all of the above are set up and the pipeline has run at least once, navigate to the environments page under Pipelines > Environments.

Deploy Boards are visible by default. You can explicitly click the triangle next to their respective environment name in order to hide them. GitLab will then query Kubernetes for the state of each node (e.g., waiting, deploying, finished, unknown), and the Deploy Board status will finally appear.

GitLab will only display a Deploy Board for top-level environments. Foldered environments like review/* (usually used for Review Apps) won't have a Deploy Board attached to them.

Canary Deployments

A popular CI strategy, where a small portion of the fleet is updated to the new version of your application.

Read more about Canary Deployments.

Further reading