Define deployment SLO
Via MTTP we measure the elapsed time from code being in master to the same code being on GitLab.com .
This number fluctuates based on events that might or might not be in the control of the Delivery team who owns the metric.
We should start thinking about the composition of the MTTP number, and start setting some targets for each of the discrete components. Something like this has been previously investigated with #773 (closed) , so we can use the information there as our starting point.
Illustrative example
Let's say that our MTTP measure consists of:
- Build time - time that it takes for the code to be built and ready for deployment
- Deployment time - time that it takes for deployments to complete for each of the environments
- QA time - time that it takes for automated QA to give a green light to subsequent deployments
In this case, Deployment time is something that the Delivery team has the direct influence over; The tooling runtime is something that we directly control.
In #773 (closed), it was mentioned that 13.17% of the time in the 90 day period is used by tasks related to the environment rollout. We should agree on a definition of deployment time, and then define the SLO target for it in order to understand what kind of investments we need to do ourselves. After that, we can define the Build/QA time and work with other departments to setup SLOs.
Definition
Deployment SLO will measure deployment pipeline duration. This will be the elapsed time between a starting on Staging through to the completion of the deployment on Production.
Work to document and measure the introduction of the Deployment SLO is being tracked in &461 (closed)