DevOps2026
Build-Once CI/CD Platform for Integration Apps
Rebuilt an enterprise integration CI/CD estate around one centralised reusable workflow — build-once artifact promotion, enforced branch strategy, automated version bumps, chat notifications on every step, and auto-raised reconcile PRs for off-path deploys.
A rebuild of the CI/CD estate for a portfolio of enterprise integration applications and shared libraries, replacing a per-repo pipeline that had drifted into inconsistency.
The core change is build-once promotion. Previously every deployment rebuilt from source, so the thing tested was never quite the thing released. Now the lower environment publishes a dated snapshot for fast feedback, promotion to the test branch republishes a stable semantic version from that same tested commit, and the higher environments fetch and deploy that exact artifact from the registry. Production never rebuilds.
Every repository is thin. Apps and libraries hold only small caller workflows that invoke one centralised reusable workflow, pinned to its main branch, which carries the build logic, the shared Maven settings, the helper scripts and the caller templates. Improving the pipeline is a single PR against that repo rather than a change replicated across every application.
Governance is enforced rather than documented. Promotion happens only through reviewed pull requests, a guard workflow rejects merges that skip the path, unit tests run both on the PR and on the merged head, and version bumps derive automatically from the branch type. A dedicated bot identity owns the version-bump commits and release tags, so pipeline writes are distinguishable from human ones.
Because a strict path needs an escape hatch, an emergency deploy can push a branch straight to any environment — reviewer-gated on the higher ones — while automatically recording a deviation tag, a non-latest release, and a reconcile pull request back to the mainline. The fix goes live immediately, and the reconciliation stays visible as a human decision rather than being forgotten.
Rollback deploys a previous build tag, with a lineage check so only genuinely promoted builds can reach the higher environments. Adaptive cards post to the team chat channel on every pull request, deployment and library publish, and release notes are generated with ticket links instead of being maintained by hand.
Onboarding a repository is a single init script that seeds its caller workflows and reads credentials from the vault directly, so secret values never pass through a command line or shell history.
Outcomes
What the platform unlocked once it landed in production. Each one is a measured behaviour change, not a feature promise.
- 01
Build once, promote the same artifact
The lower environment runs a snapshot for fast feedback; promotion publishes one stable artifact from that same tested commit, and every higher environment deploys that exact artifact. Nothing rebuilds on the way to production.
- 02
One shared workflow, thin repos
Each app and library repo holds only small caller workflows that invoke a central reusable workflow pinned at main. A pipeline improvement reaches every repo at once instead of needing dozens of copy-paste updates.
- 03
Branch strategy actually enforced
Promotion runs through reviewed PRs only, with a guard workflow that rejects out-of-order merges. Separate lower and higher environment branches finally give release managers and developers distinct lanes.
- 04
Tests gate every merge
Unit tests run on each PR and again on the merged head, which catches the case two independently-green PRs conflict once combined. Version bumps happen automatically on merge — minor for features, patch for fixes.
- 05
Visibility in the team chat
Adaptive cards post to a Teams channel on every PR, deploy and publish, so releases stopped being invisible. Release notes and ticket links are generated rather than hand-maintained.
- 06
Off-path deploys stay tracked
An emergency deploy straight from a branch is reviewer-gated on higher environments and automatically records a deviation tag, a non-latest release, and a reconcile PR back to the mainline — so urgent fixes never quietly diverge.
- 07
Rollback with lineage checks
Any previous build tag can be redeployed, but a tag is only accepted for a higher environment if it genuinely travelled the full promotion path. You cannot roll production back to something that was never released.
- 08
Warm caches, faster runs
A dependency cache keyed by a version-stable hash means a version bump no longer invalidates it — only real dependency changes do. A second delta cache captures the plugins that only resolve at publish time.
Architecture
Want the longer story behind this one? Get in touch.