GitLab is an open-core project that has both open-source and source-available code. The likely type of buyer determines which tier a feature goes into. If the buyer for a feature is an individual contributor, we promise to open-source it.
We don't always get this classification right. When something that is already open source should be source-available, we leave it open source — and when something should be open-source, we fix it.
The latter is the case for GitLab ChatOps. ChatOps lets you run commands from chat (right now Slack and Mattermost are supported). Running these commands in a channel allow everyone to be on the same page about what happened. We use it in production, for example to publish and deploy GitLab and to run database queries:
We discovered that the people that care most about this feature are individual contributors, so we'll open source this feature in GitLab 11.9.
The ChatOps market has not taken off the way that many of us (including myself) predicted. The first ChatOps client was Hubot and its popularity has dwindled since 2015. I was really excited for the next generation of ChatOps provided by the Cog project, but the company behind this initiative had to wind down.
In talking with industry experts, I think there are five ingredients needed to make ChatOps successful:
- Monitoring: ChatOps is great for troubleshooting together, so it should be easy to show a graph.
- Queryability: allow a parameter, for example a SQL command to run, or to show a graph of a specific server.
- Permissions: People should have different levels of access, preferably Role Based Access Control (RBAC).
- Zero-config: You should have access to a lot of functionality without any setup required.
- Consistency: ChatOps should work the same throughout the organization.
I think monitoring and queryability were innovations in Hubot. In Hubot anyone with access could do anything, this was fixed when Cog added permissions. GitLab adds zero-config and consistency so that everything works out of the box. Things are able to work out of the box in GitLab because it is a single application for the entire DevOps lifecycle. GitLab knows how to deploy an application with Auto DevOps. In GitLab you have monitoring with metrics and tracing.
Currently the functionality in ChatOps doesn't have commands for deployments and metrics by default. We hope that open-sourcing the functionality will enourage more use of ChatOps and more contributions to it.
The wider community has become more active this year, with more than 150 contributions to all different parts of GitLab in the last release.
For this we are most grateful. Happy holidays!
