home / work
Work
Client and employer names stay private. These are real systems designed and run end to end, described without the names. Each one can be built fresh for your team, in your accounts.
// problem → after
01-ci-platform.md+3 −3
- Every repo had its own pipeline.
- Every repo calls one shared, versioned workflow engine.
- “Link a ticket” and “bump the version” depended on people remembering.
- PR rules are checked automatically on every pull request.
- A full product build meant triggering components one by one, in order.
- One YAML plan builds every component in dependency order.
// what was built
- A central library of versioned reusable GitHub Actions workflows covering PR checks, build, security scans and release
- Onboarding templates, so a new repo needs only a few small files
- Automatic PR governance: Jira keys in titles and branches, Jira status checks, branch rules, version bumps, CODEOWNERS, drift detection
- Automated semantic versioning, release-please changelogs and Jira build tags
- A dependency-ordered build chain across components, in stages, from one YAML plan, with a summary report
// outcome
- Every repo on one shared pipeline
- A pipeline fix ships once, not once per repo
- New repos onboarded from a handful of template files
// problem → after
02-signed-releases.md+3 −3
- Customer drops were assembled by hand.
- Drops are assembled from versioned artifacts, including patch drops.
- Customers wanted signed images, SBOMs and scan reports.
- Every image and file is scanned, signed and shipped with an SBOM.
- Some customers could only receive files through a chain of machines.
- A packaged transfer path covers each hop, with checks at every step.
// what was built
- Release drops assembled from versioned artifacts, including patch drops
- Vulnerability scans, SBOMs (CycloneDX/SPDX) and keyless Cosign signing for every image and file
- ORAS push to customer OCI registries (Zot), with a transfer path for restricted networks (Windows to VM to destination)
- An auto-generated install README for every drop, an audit trail in Confluence, and Teams and email notifications
// outcome
- Every drop traceable to exact versions, scans and signatures
- Install guides that are never out of date
- A clear answer to “what did we send, and when?”
// problem → after
03-runners-artifactory.md+3 −3
- Runners were managed by hand and fell behind GitHub’s version rules.
- An Ansible-managed fleet upgrades itself, round-robin, with idle checks.
- Artifactory storage grew every month.
- Retention rules and storage reports keep it in check.
- Nobody trusted cleanup not to delete something a release needed.
- Latest builds and release artifacts are always protected.
// what was built
- An Ansible-managed fleet of self-hosted runners: register, rotate, and rolling upgrades round-robin across groups with idle checks and failure blocking
- Build-host preparation playbooks, nightly runner cleanup and Podman storage cleanup
- Artifactory retention rules, a “keep the latest build per component” policy, a protect list for release artifacts, and storage reports
- Build and commit metrics in InfluxDB and Grafana, plus scheduled repo, PR-age and uptime reports
// outcome
- Runners kept inside GitHub’s 30-day version rule without manual upgrades
- Artifactory storage reclaimed without risking a release
- Build health visible in dashboards instead of guesswork
Want something like this for your team?
Send me your repo or CI file for a free 15-minute review, or book a call.