For more details about the product vision for Fulfillment, see our Fulfillment page.
Fulfillment manages several product categories:
|Licensing (license.gitlab.com)||Covers all aspects of our licensing model, from how we count seats and conduct true-up to how we count active seats and keep the customer informed on their seat utilization.|
|Transactions (customers.gitlab.com)||How customers pay for GitLab. Licensing is about how we package GitLab as an offering, whereas Transactions is about how we fulfill those business relationships and how we make doing business with GitLab a great experience for both self-managed and GitLab.com.|
|James Lopez||Backend Engineering Manager, Fulfillment|
|Rubén Dávila||Backend Engineer, Fulfillment|
|Mark Chao||Backend Engineer, Fulfillment|
|Amparo Luna||Backend Engineer, Fulfillment|
|Corinna Wiesner||Backend Engineer, Fulfillment|
|Tyler Amos||Senior Backend Engineer, Fulfillment|
|Vladlena Shumilo||Backend Engineer, Fulfillment|
|Vitaly Slobodin||Senior Frontend Engineer, Fulfillment|
|Dhiraj Bodicherla||Senior Frontend Engineer, Fulfillment|
|Reuben Pereira||Backend Engineer, Fulfillment|
|Ryan Cobb||Backend Engineer, Fulfillment|
|Kirstie Cook||Backend Engineer, Fulfillment|
|Chris Baus||Engineering Manager, Fulfillment|
|Shreyas Agarwal||Senior Backend Engineer, Fulfillment|
|Ragnar Hardarson||Senior Frontend Engineer, Fulfillment|
|Ammar Alakkad||Frontend Engineer, Fulfillment|
|Andrei Stoicescu||Frontend Engineer, Fulfillment|
|Chloe Liu||Senior Software Engineer in Test, Fulfillment|
We plan in monthly cycles in accordance with our Product Development Timeline.
Release scope for an upcoming release should be finalized by the
On or around the
26th: Product meets with Engineering Managers for a preliminary issue review. Issues are tagged with a milestone and are estimated initially.
Points of weight delivered by the team on the last milestones. This allows for more accurate estimation of what we can deliver in future milestones. Full chart here.
Engineers can find and open the milestone board for Fulfillment
and begin working first on those with the
It's possible for engineers to pick any of the remaining issues for the milestone once the deliverables are done. If the engineer has no preference, they can choose the next available issue from the top.
The following table will be used as a guideline for scheduling work within the milestone:
|Type||% of Milestone||Description|
|Deliverable||40%||business priorities (compliance, IACV, efficiency initiatives)|
|Bug||16%||non-critical bug fixes|
|Other||20%||engineer picks, critical security/data/availability/regression, urgent business priorities|
An issue will have at least 4 stages, and they should be moved accordingly using the Fulfillment workflow board
Every Friday, each engineer is expected to provide a quick async issue update by commenting on their assigned issues using the following template:
<!--- Please be sure to update the workflow labels of your issue to one of the following (that best describes the status)" - ~"workflow::In dev" - ~"workflow::In review" - ~"workflow::verification" - ~"workflow::blocked" --> ### Async issue update 1. Please provide a quick summary of the current status (one sentence). 1. When do you predict this feature to be ready for maintainer review? 1. Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
We do this to encourage our team to be more async in collaboration and to allow the community and other team members to know the progress of issues that we are actively working on.
Deliverable proposal issue moves into
workflow::planning breakdown, SETs owns the completion of the
Availability and Testing section in the Feature Proposal to complete the definition of done. As we grow to reach our desired ratio, we will only have the quad approach in groups where we have an assigned SET in place.
quad-planning::readywhen the feature is reviewed by the team and is ready to be implemented.
Availability and Testingsection, ensuring that the strategy accounts for all test levels and facilitating discussions and feedback with the group.
quad-planning::complete-actionif they have are recommendations (e.g. running regression job, writing additional tests, etc.).
quad-planning::complete-no-actionif there is no additional actions needed.
Quad Planning Dashboard showcases the total Planned issues for Quad Planning vs the actual ones for each milestone.
The Subscriptions App has different types of tests running:
We also have a flag
VCR that mocks external calls to Zuora by default. We have a daily pipeline that runs at 9AM UTC with the flag set so the API calls hit the Zuora sandbox and we are notified of any failure (due to potential API changes).
Any test failure is notified to #g_fulfillment_status including a link to the pipeline. Pipeline failures will prevent deployments to staging and production.
We use CD (Continuous Deployment) for the Subscriptions App and a MR goes through the following stages once it gets merged into the
If something goes wrong at the
Verification stage, we could create an issue with the label
production::blocker, which will prevent deployment to production. The issue cannot be confidential.
For MRs with significant changes, we should consider using feature flags or create an issue with the
production::blocker label to pause deployment and a allow for longer testing.
We use an automatic deployment to staging, but manual deployment to production for the license app.
Maintainers of the application need to trigger a manual action on the
master branch in order to deploy to production.
In most cases an MR should follow the standard process of review, maintainer review, merge, and deployment as outlined above. When production is broken:
In these cases please ensure:
The feature freeze for Fulfillment occurs at the same time as the rest of the company, normally around the 18th.
|App||Feature freeze (*)||Milestone ends|
|GitLab.com||~18th-22nd||Same as the freeze|
|Customers/License||~18th-22nd||Same as the freeze|
(*) feature freeze may vary according to the auto-deploy document.
Any issues not merged on the current milestone post feature freeze, will need to be moved to the next one (priority may also change for those).
One of our main engineering metrics is throughput which is the total number of MRs that are completed and in production in a given period of time. We use throughput to encourage small MRs and to practice our values of iteration. Read more about why we adoped this model.
We aim for 12 MRs per engineer per month which is tracked using our throughput metrics dashboard.
We also have a general quality dashboard for the whole Fulfillment team.
We optionally join the Growth sync meetings on Wednesdays. See the agenda.
We hold optional synchronous social meetings weeekly, every Wednesday at 03:30pm UTC. In these meetings we chat about anything outside work.
8th, the Fulfillment team conducts an asynchronous retrospective. You can find current and past retrospectives for Fulfillment in https://gitlab.com/gl-retrospectives/fulfillment/issues/.