[WIP] [Meta] Operating GitLab
Customers consume GitLab in one of two ways: GitLab.com or self-hosted. Our packages, containers, and charts are used in both scenarios.
- For GitLab.com, we want to ensure our SaaS service uses the same tools and deployment methods as our customers. This ensures we test our own software, and that our customers can scale as high as they need. This often means working hand in hand with the GitLab.com team, to ensure their requirements and needs are considered.
- Self-hosted customers are responsible for the full life cycle: installation, configuration, maintenance, and upgrades. This means they have direct interaction with all of our packaging assets, initially and on-going.
In both cases, our build assets form a critical foundation for the rest of the product. When thinking about our goals for 2018, we want to support these needs in a few different ways.
Enterprise class Kubernetes deployment
GitLab wants to be the best development tool for cloud native development, and we believe the right platform for that is Kubernetes. GitLab is investing heavily on the product side to help customers work with and deploy into Kubernetes, and we need to ensure it is possible to easily run GitLab inside of Kubernetes as well.
- Cloud Native containers/charts (https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2420)
- Requirements for large enterprise (https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2400)
Simplify installation
It is critical for customers to be able to easily get started with GitLab. By making this easier, more users and companies will become familiar with Community Edition and we also reduce the level of investment required to embrace Enterprise Edition. This is particularly
While getting started with the core SCM features is fairy easy, we want to ensure a complete installation is equally easy as well as achieving all best practices like HTTPS. Part of making this easier, also depends upon how and where a user wants to run GitLab, and ensuring we have a high quality method to support it.
Reducing the installation burden, as well as the on-going maintenance noted below, is particularly important when someone is comparing GitLab to a SaaS solution.
- Let's Encrypt
- AWS Quickstart
- GCP? (GKE, Cloud SQL, NFS?)
Reduce maintenance costs
On-going maintenance costs should always be reduced, and GitLab is generally set and forget for the most part. However with increasing adoption of SaaS services, it is even more important to ensure that the time and effort required to maintain a self-hosted GitLab instance is as low as possible.
We should consider automating as much as we can, and generating alerts or other notifications in the event attention is required.
- Web based admin portal (https://gitlab.com/gitlab-org/gitlab-ce/issues/37674)
- Auto updates (https://gitlab.com/gitlab-org/gitlab-ce/issues/22560)
- Improved logging/error reporting
- GitLab Service Alerts (https://gitlab.com/gitlab-org/gitlab-ce/issues/27495)
- Metrics available to Support (https://gitlab.com/gitlab-org/gitlab-ce/issues/37491)
Support GitLab.com team, as they move onto our packages/containers/charts
- Cloud Native containers/charts (https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2420)
- 3 different Redis queues