Deploy Boards in GitLab

At first reading up on GitLab deploy boards I was quite impressed. I liked how it seemed to integrate with Kubernetes (k8s) seamlessly, the tracking and monitoring features that seemed to come with it, and canary builds. However, after setting their stuff up for a demo cluster, I was unimpressed. Here’s how you set up deploy boards and what they enable.

What does this really do?

Deploy boards essentially let you view how many pods are spun up for a given k8s environment. It lets you view logs on a per pod basis, and it has ways of differentiating canary pods. That’s about it. The deploy boards functionality is attached to the Environments page. So to use deploy boards you have to have an environment configured. Here’s an example:

The deploy board itself is the bottom, darker grey spot with the green blocks; each one is a pod associated with the “production” environment in this case.

Environments

Configuring environments is pretty simple. You use the “environment” job with a “script” block in your .gitlab-ci.yml to indicate that an environment exists and was just deployed to. When you run a deploy like this, your Environments page in GitLab will update with a new entry. It won’t set up the “deploy boards” element yet, though...

Deploy boards setup

If you installed a GitLab runner on your cluster, and your respective k8s pods, replicasets, and deployments have a matching “app:env_name” label, then GitLab will pick this up and associate those with the given “env_name” in your Environments page. This is how it shows a display of how many pods are spun up. If you add extra labels for your canaries, with “track:canary”, then GitLab will pick up that this deploy is a canary version, and will show it on the frontend. Otherwise, that’s it. It’s incredibly simple. Don’t get caught up on a quick issue I had forgetting to label your pods with “app:env_name” as well in addition to your deployment.

Overall opinion

Overall, I think it’s a lukewarm feature. Not really impressive, not really all that useful. Just a neat thing to show off. I guess it’s most useful for devs connecting to and tracking their merge request environments and changeset movements through internal pipelines. The price jump to silver tier on GitLab, however, is not worth the $16 hike from $4 per user per month to $20 for this feature on its own.