# 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') _`