Gerrit option runbook

Gerrit as the change-based review option for Managed Git Server

This is the Gerrit option runbook for Managed Git Server. Gerrit is for teams using change-based review for large repositories, regulated development, multi-repository workflows, or projects where patch-set review and submit rules matter more than pull request conventions.

Gerrit is selected after assessing workflow readiness, identity, plugin needs, hosting location, CI adapter ownership, backup expectations, compliance evidence, and developer onboarding impact.

Use case	Why Gerrit fits
Change-based code review	Review atomic changes with patch sets, labels, and submit requirements
Regulated engineering	Enforce explicit approvals, verification, audit trails, and controlled submit paths
Large multi-repo programs	Support workflows common in Android-style, embedded, platform, and vendor ecosystems
CI-gated submission	Integrate verification results before changes enter protected branches

Managed scope#

Area	Assistance operates
Provisioning	Gerrit installation, sizing, storage, networking, TLS, and secure baseline configuration
Lifecycle	Version upgrades, plugin compatibility checks, maintenance windows, and rollback planning
Reliability	Backups, restore procedures, monitoring, alerting, and incident triage
Identity and access	LDAP, SAML/OIDC, group mapping, permissions review, and admin handoff
CI integration	Event stream integration, verification labels, build feedback, and pipeline connectivity

Gerrit remains a shared workflow decision

Assistance operates the Gerrit platform. Your team owns repository policy, code ownership, reviewer expectations, and product-specific submit rules unless those governance decisions are explicitly included in the engagement.

Deployment models#

Model	When to use it
Dedicated Gerrit instance	Teams that need a private review platform with predictable operations
Gerrit in your cloud account	Organizations with existing cloud networking, identity, or compliance controls
Gerrit on Kubernetes	Teams standardizing delivery platforms on Kubernetes and GitOps workflows
Migration engagement	Move from self-hosted Gerrit, GitLab/GitHub review flows, or legacy SCM tooling into an operated Gerrit model

Operating boundaries#

Responsibility	Assistance	Customer team
Platform runtime	Install, configure, monitor, patch, back up, restore, and operate Gerrit	Consume Gerrit safely from developer workflows
Review model	Configure labels, permissions, submit requirements, and plugins by agreement	Define approval policy, ownership rules, and team workflow expectations
CI/CD	Integrate Gerrit events with agreed pipeline systems	Own build logic, test coverage, and release criteria
Security	Maintain platform hardening, TLS, access controls, and audit support	Manage user lifecycle, repository sensitivity, and internal approval policy

Runner and verification integration#

Gerrit does not select CI capacity with GitLab-style runner tags or Actions-style runs-on labels. Gerrit emits change, patch-set, and review events; Jenkins, Zuul, Tekton, or a custom adapter consumes those events, schedules verification workers, and reports labels or comments back to Gerrit.

Use Managed Runners for the worker capacity, runner monitoring for queue and health signals, and runner troubleshooting when verification jobs are stuck, offline, or unable to reach private systems. The Gerrit runbook should record the event source, adapter owner, verification labels, submit requirements, runner pool, and escalation path.

Onboarding process#

1. Review workflow assessment#

We review your repositories, branch model, reviewer groups, CI expectations, identity provider, and existing Gerrit or code review pain points.

2. Platform design#

We define hosting location, sizing, authentication, backup policy, monitoring, plugin set, and CI integration path.

3. Provision and migrate#

We deploy Gerrit, configure access, migrate projects where needed, connect pipelines, and validate patch-set and submit workflows.

4. Operate and improve#

We run updates, monitor health, review incidents, support plugin changes, and adjust capacity or workflow configuration as usage grows.

Managed Git Server options — Compare GitLab, Gerrit, Gitea, and Forgejo under one managed git server offer
GitLab option runbook — Integrated DevSecOps platform operations when GitLab is the preferred option
Managed Self-Hosted Runners — CI/CD runner capacity that can verify Gerrit changes
Runner troubleshooting — Triage queued, unavailable, or network-blocked verification workers
Managed runners overview — Compare Gerrit verification workers with GitLab tags and Gitea/Forgejo labels
Managed Jenkins and CI/CD support — Pipeline operations around Gerrit-driven delivery
Managed Prometheus — Monitoring and alerting for Gerrit and supporting services

Request a Gerrit assessment. We will review your code review workflow, identity setup, CI integration, repository scale, and operational requirements before proposing a managed Gerrit model.

Request Gerrit assessment →

FAQ#

Can you migrate an existing Gerrit instance? Yes. We can assess your current Gerrit version, plugins, authentication, project configuration, repositories, and backup state before planning a migration or upgrade path.

Can Gerrit integrate with our CI system? Yes. Gerrit commonly integrates with Jenkins, Zuul, Tekton, and custom automation through events, REST APIs, SSH, and verification labels.

Do you manage Gerrit plugins? Yes, within an agreed plugin set. We review compatibility during upgrades and treat plugins as part of the supported operating boundary.

Can Gerrit run in our own cloud account? Yes. We can operate Gerrit in your cloud or private environment when access, networking, backup, and responsibility boundaries are clearly scoped.