The GitLab **Platform Readiness Enablement Process (PREP)** encompasses the systematic evaluation of GitLab
features for production readiness across GitLab.com, Dedicated, and Self-Managed
platforms. As GitLab's readiness evaluation capabilities expand to cover additional feature
domains, this framework will evolve to provide a unified assessment experience
for all product teams, preventing process fragmentation while ensuring
comprehensive feature readiness across the entire GitLab ecosystem.
This assessment empowers product teams to self-serve their readiness evaluation
and helps reviewing teams ensure that features are ready for production
deployment.
**PREP** addresses infrastructure concerns that apply to any GitLab feature,
regardless of subject domain. It serves as a communication bridge between product
and infrastructure teams, ensuring features are ultimately ready for production
deployment across all GitLab platforms.
## Vision Statement
One unified and paved path to production: Empowering development teams to own requirements and developers to ship higher-quality features through proactive, AI-informed context and seamless systems integration.
## Why PREP is required
The unique position of GitLab as both a SaaS provider (GitLab.com) and software
vendor (GitLab Self-Managed and GitLab Dedicated) creates critical readiness gaps
that existing processes don't address. GitLab has experienced platform
compatibility failures where features reached general availability (GA) without
validation across GitLab Self-Managed and GitLab Dedicated platforms, causing
customer deployment issues and increased support burden.
The existing Production Readiness Review only covers GitLab.com operational
readiness, leaving no systematic evaluation for GitLab Self-Managed and GitLab
Dedicated platform requirements, or evidence-based validation across different
customer environments. This gap led to reactive problem discovery, with
cross-platform compatibility issues found post-release requiring considerable
engineering work and delayed GA promotions.
PREP fills this critical void by providing a self-service, evidence-based
framework for product teams to systematically evaluate their features' readiness
across the entire GitLab platform ecosystem, ensuring consistent quality for all
customers.
{{% alert title="Note" color="primary" %}}
A completed and approved PREP is **mandatory** for any
feature to reach GA status. Features cannot be promoted
to GA without stakeholder approval of their PREP.
{{% /alert %}}
## When PREP is required
PREP is required when a feature introduces _infrastructure concerns_. Here are a
few examples that can help you to ascertain this:
- Does your feature introduce a new service or component?
If you're adding a completely new service (like GitLab Zoekt) that needs to be
packaged, distributed, and operated independently, you need PREP. If you're
just adding functionality within existing services, you likely don't.
- Does your feature require new infrastructure dependencies?
If your feature needs new databases, external services, storage backends, or
networking components (like the Container Registry metadata database requiring
database HA), you need PREP. Simple API additions within existing frameworks
typically don't.
- Does your feature have significant operational resource requirements?
If your feature introduces new computational, storage, or memory requirements
that could impact deployment sizing, scaling, or resource allocation across
different environments, you need PREP. Lightweight additions to existing services
usually don't.
- Does your feature require new installation, configuration, or deployment steps?
If customers need to perform additional setup, configure new components, or
modify their deployment procedures to use your feature, you need PREP.
- Does your feature behave differently across GitLab.com, GitLab Dedicated, and
GitLab Self-Managed?
If your feature has platform-specific considerations, compatibility requirements,
or performance characteristics that vary by deployment method, you need PREP.
- Does your feature introduce new infrastructure concerns?
If your feature affects security models, monitoring requirements, backup
procedures, upgrade processes, or other operational aspects beyond its core
functionality, you need PREP.
If you answered "yes" to any of these questions, your feature likely introduces
infrastructure concerns or other platform dependencies that require PREP.
## Relationship to Production Readiness Review
Platform Readiness Enablement Process **combines** the existing [Production Readiness Review](/handbook/engineering/infrastructure-platforms/production/readiness) and Operational Readiness Review processes, to focus on ensuring features work correctly across all GitLab deployment pathways and methods.
## Key principles
PREP is built on several core principles that distinguish it from other readiness
processes:
-**Self-Service**: Designed for independent completion by product teams with
clear guidance and stakeholder contact information
-**Progressive**: Answers evolve with feature maturity through the development
lifecycle - not all questions need to be answered simultaneously
-**Evidence-Based**: Every response must be supported by concrete documentation,
implementation details, or tracking issues
-**Collaborative**: Facilitates ongoing collaboration between product teams and
reviewing teams with validation at key gates
## Assessment scope
PREP covers 11 categories of infrastructure concerns, each with specific
The Production Readiness Review is being combined into the Production Readiness Enablement Process - PREP.
To move your feature to production, please create a new [PREP Assessment](https://gitlab.com/gitlab-org/architecture/readiness).
{{% /alert %}}
## Overview
The Production Readiness Review is a process that helps identify the reliability needs of a service, feature, or significant change to infrastructure for GitLab.com.
@@ -26,7 +31,7 @@ The **readiness review issue** is used to coordinate among stakeholders who will
|--------------|-------------|
| [Readiness Planning Board](https://gitlab.com/gitlab-com/gl-infra/readiness/-/boards/7418781) | [Readiness Status Board](https://gitlab.com/gitlab-com/gl-infra/readiness/-/boards/5177836) |
| Readiness currently being prepared. | Readiness actively in review. |
## Criteria for starting a Production Readiness Review
@@ -64,7 +69,7 @@ The Production Readiness process is authored by the DRI of the work that is bein
1.[Create an issue](https://gitlab.com/gitlab-com/gl-infra/readiness/-/issues/new?issuable_template=production_readiness) using the issue template in the [readiness project](https://gitlab.com/gitlab-com/gl-infra/readiness). The title of the issue should be a descriptive name of change.
2. Follow the Readiness Checklist in the template.
[The issue template](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/.gitlab/issue_templates/production_readiness.md?ref_type=heads) will guide you though preparing your merge request and how to use the approriate labels to keep your review moving through the process.
[The issue template](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/.gitlab/issue_templates/production_readiness.md?ref_type=heads) will guide you though preparing your merge request and how to use the appropriate labels to keep your review moving through the process.
The template also contains information about what is expected for Experimental, Beta, and Generally Available features and services.
