GitLab Infrastructure Platforms Review Process
## Problem Statement Gitlab Product Engineering teams are largely unfamiliar with how their features are shipped to all platforms, due to the large degree of automation and delivery services that GitLab Delivery teams are offering. Most of the time it "just works". However, in case new components or services are needed to enable the feature, additional work is required to deliver them to all platforms (GitLab.com, self-managed and Dedicated). These complexities are largely unknown to product engineering teams, leading to ad hoc requests to Delivery teams to include these components. What is missing is a comprehensive delivery readiness process. We need a single entry point for delivery to all platforms, including: * readiness reviews * lists of requirements and necessary deliverables * scope and timelines * responsibilities of requesting teams and Delivery teams in order to provide a transparent process to get a feature shipped. Notably, we should unify the diverse readiness checks in order to keep the process streamlined and avoid excessive bureaucracy. As our development organization continues to grow, our delivery teams have become a bottleneck. The Delivery Framework will also serve to make tasks clear enough to self-serve delivery with guidance of our teams. We need these comprehensive readiness checks for each stage of the delivery lifecycle to ensure reliability, security, and compliance while empowering development teams to deliver high-quality solutions that meet consistent standards with greater speed and confidence. ## **Benefits for Development Teams:** * Reduces context switching and rework by providing clear expectations upfront * Decreases production incidents by catching issues earlier * Automates repetitive compliance and security checks, allowing developers to focus on building features * Improves velocity by standardizing processes and reducing delivery failures * Creates predictable, documented, and potentially automated paths to production that all team members can quickly understand * Enables self-service capabilities by codifying and automating delivery requirements ## **Benefits for Delivery Teams:** * Shifts from implementers to enablers by providing frameworks, guidance, and guardrails rather than doing the work * Allows focus on framework level improvements rather than routine tasks * Reduces repetitive requests and improves scalability as development teams become more self-sufficient * Creates clearer handoffs and responsibilities between development and delivery * Improves visibility into upcoming workloads and deployment requirements at the earliest development stage * Standardizes operational practices across the organization ## Directly Responsible Individuals (DRI) @plu8 @mbruemmer ## Participants @pursultani ## Flowchart * https://www.figma.com/board/EJBC1BhMfbB1PRCHVhkbFb/GitLab-Infrastructure-Platforms-Review-Process?node-id=0-1&p=f&t=eDQbF9b4SPl6ZzFT-0 ## Exit Criteria ### Phase 1 * [ ] Finalize Self Managed feature review process * [ ] Successfully piloted with one feature rollout with Self Managed feature review process * [ ] Engage other stakeholders and confirm their process delivery timeline * [ ] **Stretch**: Identify and create follow-up issue for Self Managed documentation and standards gaps * [ ] https://docs.gitlab.com/development/ * [ ] https://docs.gitlab.com/development/distribution/ ### Phase X **To be reviewed** * [ ] Documented standards across each stage of delivery lifecycle * [ ] Integrated into existing development workflows * [ ] Automation implemented for at least 50% of standards * [ ] Successfully piloted with two engineering teams * [ ] Training materials and documentation completed
epic