Pipeline platform

Twenty services each shipped their own bitbucket-pipelines.yml. Same rough shape — build, test, scan, push, deploy — but each one slightly different. A change in the build pattern meant a PR to twenty repos.

A 1000-line bash pipeline reporter lived in the base image and posted to Teams at every stage. It worked. Nobody wanted to touch it.

Tests ran inside the pipeline, before pods were healthy. They were flaky and most failures weren't real.

Jira gates, Veracode and SourceClear were copy-pasted into every yaml.

The pipeline lives in two repos now: java-shared-pipeline and node-shared-pipeline. Each exports a set of Bitbucket selectors using Bitbucket's Shared Pipelines Configuration. Service repos import them by tag.

Per-service config is one file. Name, runtime, dockerfile, image repo, build commands. That's all a service author has to know about CI.

service:
  name: payments-api
  type: java           # java | node
  dockerfile: Dockerfile
  image:
    repository: payments-api
build:
  java:
    maven_cmd: "mvn -B -ntp test"
gitops:
  repo: platform/gitops-apps
  base_branch: main
  app_path: apps/payments-api
  strategy: kustomize

pipelines:
  pull-requests:
    '**':
      import: java-shared-pipeline:1.4.0:feature-java
  branches:
    main:
      import: java-shared-pipeline:1.4.0:main-java

Optional gates — Veracode SAST, SourceClear SCA, Jira Fix Version validation — are env-gated in the same library. One library handles services that need them and services that don't. The difference is an env var on the import, not a fork of the pipeline.

The library is semver-tagged. Services adopt a new version on their own schedule by bumping the tag. Old tags stay around as long as anyone is still on them.

Test infra is its own repo now. The pipeline builds and pushes the image, then stops. A separate ArgoCD PostSync hook runs the test job after the deploy is actually healthy, so the tests run against the real running thing rather than half a pod.

Allure reports per run. Pass/fail published to a result store. Sentry — a small dashboard I built on top — is where you go to ask "is the fleet green?".

sentry — fleet

Eleven services green, four red. Platform Foundation across the top — cluster, Kafka, databases, secrets — lives separately from per-service test health, because "the cluster is broken" and "Data Flow has a flaky test" are different conversations. POSTSYNC and CONTINUOUS triggers are tagged so it's obvious what kind of run produced the result.

sentry — per service

Drilldown for a single service. The full Allure report is one click away; the recent runs table on the bottom makes regressions obvious without anyone having to dig into a pipeline.

The bash reporter is gone. The bits worth keeping moved into a shared-scripts repo. The rest retired when ArgoCD's Notifications controller took over deploy reporting.

Promotion is decoupled from build. The pipeline emits .ci/out/build.json — commit, image, digest, tags, build url — and stops. ArgoCD Image Updater watches ECR and opens the GitOps bump itself when it sees a new tag.

Build does one thing. Promote does another. The pipeline doesn't know which environment its image will land in.

Four layers, top to bottom: a service repo and the shared libraries it imports; a Bitbucket run that produces an image and a metadata file; an Image-Updater-driven promotion that ends in a Kubernetes deploy; and a PostSync hook that closes the loop with a test result in Sentry.

The change I care about most isn't in the table. Onboarding a new service used to mean copy-pasting somebody else's yaml and quietly hoping. Now it's a builds.yaml and a tag. The diff between two services' CI is small, readable and intentional.