2.7 KiB
ADR-0001: Single Shared Library Consumed by All Services
Status: Accepted Category: PATTERN Date decided: Project inception Date documented: 2026-05-12
Context
Meesho runs 100+ microservices across multiple teams. Each service needs CI/CD: build, test, sonar analysis, Docker image push, and ArgoCD deployment. Before devops-lib, teams owned their own Jenkinsfiles and copy-pasted pipeline definitions from each other, resulting in drift, inconsistent policy enforcement, and no central control over who could bypass sonar gates or deploy directly to production.
Decision
All Meesho microservices consume a single Jenkins Shared Library — devops-lib — via @Library('devops-lib@main') in their Jenkinsfile. The library exposes a single entry point (eksCICD) that handles the full CI/CD lifecycle. Service teams do not write pipeline logic; they only provide a config.yaml.
Alternatives Considered
- Per-team Jenkinsfiles: Rejected because teams were already copy-pasting pipelines and the resulting drift made it impossible to enforce sonar gates, whitelist checks, or deployment policies uniformly.
- Per-language pipeline templates: Rejected in favour of a single entry point that dispatches to language-specific stages internally — cross-cutting concerns (sonar, notifications, ArgoCD) remain in one place.
Consequences
Positive:
- Policy enforcement (sonar gates, whitelist checks, Ringmaster gating) is applied uniformly to every service on every build — no team can accidentally opt out.
- Infrastructure changes (new deploy strategy, new ArgoCD step, new policy) roll out to all 100+ services by merging one PR to devops-lib.
- New service onboarding is reduced to writing a
config.yaml— no pipeline expertise needed from the service team.
Negative:
- The library becomes a dependency for every service build — a broken devops-lib main branch blocks all CI/CD.
- Teams needing custom pipeline behaviour have limited escape hatches; they must go through the DevOps Platform team.
Neutral:
- devops-lib must support all build types (Maven, Go, Node, Python, Gradle, PHP, Rust) internally, increasing the library's surface area.
Constraints
Meesho's scale (100+ services) made per-service pipeline ownership operationally unsustainable. The decision was also driven by a need for auditable deployment policy — the DevOps team needed a single control plane for all CI/CD.
Current Assessment
Still appropriate — no changes needed.
Notes
- Key files:
vars/eksCICD.groovy(entry point),src/com/meesho/stages/buildObjHelper.groovy(language dispatch) - Consumer services call the library with a single line:
@Library('devops-lib@main') _