Exploring using GitLab Environment Toolkit for deploying GitLab.com
Overview
GitLab Environment Toolkit is becoming an increasingly large part of our deployment story.
- We are consolidating other automation tooling within GitLab, and standardizing on GET. For example within Geo, Distribution, and soon PS.
- We plan to use this as the basis for all future instances we deploy and manage here at GitLab
- It is being utilized for JiHu to deploy their own SaaS instance
- Planning to make it the recommended deployment option for "cloud native" for the near term
Based on this trend, we should consider whether GitLab.com should maintain it's own set of automation, or if it should shift to utilize GET.
Proposed next steps
- Discuss here whether this makes sense directionally
- List the gaps between GET and current automation, for example multi-regional k8s clusters or any other specialised configurations that wouldn't apply to other environments
- Determine whether each gap should be added to GET, or whether GitLab.com can solve that in a more standard way
- Determine whether GET can add support for these needs without becoming difficult to maintain
Directionally - should GitLab.com be deployed with our standardized automation (GET)
Gaps between GET and current .com needs
Maintainability of GET
Edited by Grant Young