The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Last updated: 2022-12-22
The Fulfillment Platform group provides foundational GitLab Order-To-Cash solutions. These solutions enable other fulfillment groups and contributors to ship with confidence, speed and efficiency, while ensuring that GitLab's fulfillment systems remain robust and performant.
The Fulfillment Platform group owns, maintains and evolves the underlying architecture and orchestration for GitlLab’s order-to-cash flow (OTC).
We refer to the architecture and orchestration of GitLab's order-to-cash flow as Fulfillment infrastructure.
In order to enable other groups, contributors, and stakeholders, we are focusing on 3 key areas of the Fulfillment infrastructure:
| Key area | Principle | How | Performance Indicator |
|---|---|---|---|
| System reliability | Provide fulfillment infrastructure with best in class reliability and availability. | CustomersDot has a 99.95% target availability and must stay within allowed error budgets. |
General availability and Customer Journey Error Rate(s) |
| Developer productivity | Provide a great experience for every developer that contributes to fulfillment solutions. | Make code contribution easier by maintaining the underlying architecture, keeping it performant, observable and decrease complexity through abstractions at the platform level. | Mean time to recovery |
| Fulfillment architecture | Make fulfillment architecture and processes simple and digestible. | Abstract integration complexity with Zuora and improve the architecture and orchestration of CustomersDot to better align with the order-to-cash systems. | Data integrity |
CustomersDot is the central application for the Fulfillment Platform group.
The group is responsible for the following areas of CustomersDot:
We use performance indicators (PI) to track our progress. The current understanding of our group's northstart metric is the general availability of our services. We aim to have at least 1 leading PI per key area (outlined above) that helps us stay on track with our group's mission.
The status of these PI's is reviewed monthly with product leadership. For the latest metrics, see our GitLab Internal Handbook section.
As our responsibilities mostly span backend and architectural work, our direct target audience is GitLab internally focused:
We improve the experience of all of our customers (self-service, sales-assisted, and reseller customers) by improving fulfillment systems' process flows and subscription data accuracy.
Within the next 12 months we want to strengthen the foundation of the fulfillment platform. Our main focus is to improve our order-to-cash systems and underlying data architecture, which will help us scale as GitLab continues to grow.
Projects for key areas:
Roadmap:
Fulfillment Roadmap by Group slide deck (Not Public), that internal team members can reference for executive reviews.As one of our key areas spans developer productivity we work on performance, scalability, and observability efforts with help from the Infrastructure department.
We want to increase the level maturity of CustomersDot and continue improving our availability and observability through the following projects:
| What | Why | When |
|---|---|---|
| Improve redundancy between CustomersDot and Zuora | Adds a better caching layer to have no downtime due to frequent Zuora outages | Next (3-6 milestones) |
| Iteratively migrate CustomersDot to a HA environment | Move CustomersDot services/components to high availability in order to improve reliability | Next (3-6 milestones) |
| Implement auto-rollback on error | Minimize disruption if an outage occurs after a deployment | Later (6-12 milestones) |
| Alerting of failed jobs for critical SaaS and SM metrics | Move away from noisy Sentry alerts to critical alerts for accurate SaaS and SM billing | Later (6-12 milestones) |
| Alerting over a threshold of payment failures | Encounter payment problems as they occur | Later (6-12 milestones) |
The further we move along with our current key projects for foundational strength, we will identify new areas of opportunity that focus on systems reliability, developer productivity and Fulfillment process efficiency.
This can entail: