Dogfooding Serverless
GitLab has a value of Dogfooding their products. There are many benefits of this such as:
- Gaining domain expertise
- Reducing risk of building features that aren't useful
- Gaining empathy for users
- Catching regressions in your product before your users
I believe, since we're investing a lot in Serverless, we should also invest a little in dogfooding this. There are many applications at GitLab that could benefit from the Serverless approach such as:
- Bots that automate things in GitLab (comments on MRs, issues, change labels). A lot of this is done by triage ops team and perhaps we should work with them to turn their tools into GitLab Serverless tools
- Slack bots
I think the Serverless team should invest a little time early on in the team to get some tooling built using our Knative integration as the early we start dogfooding the more value we get from it. We've seen challenges dogfooding our own tools very late (eg. Auto DevOps) and we can avoid these challenges by just doing it from day 1.
We should pick a simple first use case for this and just set it up. Considering we believe what we're building should make this straightforward to set up for users then it should not be a very big investment for the team.