47 lines
2.7 KiB
Markdown
47 lines
2.7 KiB
Markdown
# 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') _`
|