Discussion: Review how the Delivery group domain splits between Delivery teams
In Scaling the Delivery team (#2369 - closed) we defined the new delivery teams. Now as we try to plan work for Q3, and set up for the future we can improve this definition.
Updated - 2022-10-05: Taking the suggestions from the comments, and adding in the release manager view gives us a better view of the team domains.
Updated - 2022-10-14: Added Release Publishing as a ~"team::System" responsibility. Screenshot below, but this update is from the slide deck in case anyone wants to edit.
Explanatory notes:
Release Managers
- Release Managers are members of the Delivery group but during their time as release managers they're wearing a different hat. The primary customer is GitLab users
- Auto-deploys: Release Managers operate the auto-deploy process. Largely this will make use of capabilities provided by the Orchestration team, but the Orchestration tools will be making use of the System team capabilities. Environment health checks are an example of a System capability that will be integral to the process and tools the release managers use
- Self-managed releases: Release Managers operate the release processes (patch and security) using the capabilities provided by the Orchestration team
- Post-deploy migrations: Release Managers operate the PDM process using the capabilities provided by the Orchestration team
- Hot patch process: Release Managers, working with EOCs, will manage the hot patch process. Hot patch capabilities are provided by the Orchestration team with heavy dependence on System capabilities due to the shortened process and therefore reduced pipeline jobs
- Deployment blockers: Release Managers are responsible for identifying, and reporting on deployment blockers in order to provide Orchestration and System with data needed to plan improvements
- Release Manager dashboards: Release Managers own https://dashboards.gitlab.net/d/delivery-release_management/delivery-release-management?orgId=1 plus have the freedom to create any additional dashboards that they think would be useful for release management. The data needed for dashboards will be made available from a centralized place, owned by System (see point 18)
Delivery:Orchestration
- Deployment changelock: Orchetsration will make sure that all deployments observe planned and ad-hoc changelocks. Examples include PCLs, S1/S2 incidents, CRs etc
- Pipeline visibility: Providing visibility of pipeline set up, status, and outcome
- Deployment change management tooling: Providing the ability for changes to be included, or excluded from deployments
- Release change management tooling: Providing the ability for changes to be included, or excluded from releases to Self-Managed users
- Deployment execution log: Ensuring that an accurate log of deployments is maintained
- Deployment & release metadata: Tracking component versions and dependencies to allow for quality gates to be accurate, and to ensure we have predictable releases
- QA test execution & results visibility: Ensuring that all deployments and releases pass the required testing. Orchestration will be particularly concerned with timing of test execution and making sure that the correct dependencies are in place for reliable results
- Deployment dashboards: Orchestraction will own a set of dashboards to guide the team's work on designing effective deployment and release processes. Dashboards, or templates, will also be needed to evaluate the effectiveness of individual deployment and release pipelines
Delivery:System
- Environment changelock: System will make sure that environments can be locked to schedule, or on an ad-hoc basis if required by planned maintenance or poor environment health. Guaranteeing that changes are rolled out in a predictable way will also be a System responsibility
- Environment health: Ensuring that environment health is assessed and available to guide deployment decisions
- Release & deployment metrics: Provding A centralized store for metrics related to deployments & releases. System will primarily be concerned with providing a metrics capability to allow all deployment and release pipelines to record metrics in a useful way to fuel all required dashboards
- Application rollout: System will be responsible for applying changes to the required clusters and environments. Rollout strategies, e.g., canary, blue/green, with gradual traffic increase etc, will be capabilities provided by System.
- Release Publishing: publishing packages to various distribution sites (e.g., packages.gitlab.com, Docker Hub, etc.), publishing tooling, and guaranteeing a reliable publishing process.
- Rollout dashboards: System will own a set of dashboards to guide the team's work on managing effective rollouts to all environments. Examples could include timing of changes applied to individual servers and visibility into environment use
- Canary environments: System will own the rollout capability of the canary environments. They'll work closely with Reliability to ensure full environment management
- Deployment and release test environments: Pre, Staging, Release: System will own the rollout capability of the test environments. They'll work closely with Reliability to ensure full environment management
- Deployment and release production environment: System will own the rollout capability of the Production environment. They'll work closely with Reliability to ensure full environment management
Edited by Michele Bursi