Set north star metric for core CI/CD groups
Moved to #860 (closed)
From the product group call (full context: https://docs.google.com/document/d/1feF46WvqBuWJ-bYnA-BuCD4gq_J5UagupNHJYTBtII8/edit#bookmark=id.bw0rgiwddxl):
@sfwgitlab: I would like every group to have a single “north star metric” that your group is trying to move with your development activities. In most cases this will be AMAU/SMAU, but I’m open to other north star metrics. Once you align on the metric, then we need to baseline it, and set a quarterly goal for it. Then we’ll have regular reviews to track performance against the metric, and review activities underway to move it further. We will use this data to inform future investment decisions, so it’s important to lean in on this.
For the core CI/CD groups lets set a metric and target. Beyond this, I'd like to add the metric to the direction pages (probably in the maturity plan section). In the metric section below, please also link to where the metric can be viewed, or your issue to get it implemented.
Group Metric Q1 Target Reasoning/other details Package (@trizzi) Track the total number of packages pushed and pulled on GitLab.com Rolling 7 day average > 22k events per day(120% increase from Feb. 1 - May 1)The Package stage has the opportunity to replace 3rd party vendors like Artifactory and Nexus. Artifactory has moved its container registry to its community edition. We will compete and be evaluated on the strength of our Package Registry offering. We can use the number of packages pushed and pulled to measure growth rate and adoption of the feature. We can break this down further by measuring the adoption rate of new formats over time. NOTE: Our current tracking utilizes snowplow, which is limited to GitLab.com. In future quarters, we will need to add tracking to the usage ping, so we can track self-managed, opted-in instances as well. Continuous Integration (@thaoyeager) Progressive Delivery (@ogolowinski) Usage of Auto Deploy or other cloud deploy templates (not yet measurable) Baseline TBD This can be tricky to monitor but we are giving it some thought. We are thinking of measuring the number of times the template/containers are accessed and called on (if this is cached on the client side this will skew the numbers) and the number of times auto deploy is used Runner (@DarrenEastman)