CI/CD and Artifact Platform Cluster Services
Your pipeline is production infrastructure now. It gets the same availability design, backup and monitoring as anything customer-facing.
What this usually looks like
The build system started as a convenience and became the thing that stops every team at once when it is slow, full, or down.
- Builds queue from mid-morning and the queue is treated as a fact of life rather than a capacity problem.
- The artifact registry is a single instance with local disk, and nobody has restored it.
- Pipeline credentials are long-lived tokens stored in project settings.
- Nobody knows how long a build takes at the 95th percentile, only that it "feels slow".
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- Pipeline performance baseline: queue time, duration and failure rate
- Runner capacity and class analysis against actual demand
- Registry and artifact storage review, including restore status
- Pipeline credential inventory and exposure assessment
Build
One-off delivery: design, code, hardening, handover
- Autoscaling runner fleet with per-team quotas so one team cannot starve others
- Artifact and container registry made highly available, with garbage collection policy
- Pipeline secrets moved to short-lived credentials issued by a secrets system
- Shared build cache on object storage to cut repeat build time
- Pipeline health metrics on a dashboard teams actually look at
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Runner capacity managed against demand, with queue-depth alerting
- Registry storage growth, garbage collection and replication maintained
- Pipeline instrumentation reviewed monthly with the platform team
- Upgrade management for the CI control plane on an agreed cadence
- Restore tested for the registry and the CI configuration repository
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
Runners & executors
- GitLab Runner (Kubernetes + Docker executors)
- Jenkins agents
- Buildkite agents
- ARC (Actions Runner Controller)
- class-based autoscaling
Control planes
- GitLab (self-managed)
- Jenkins (HA controller)
- Tekton
- Argo Workflows
Registries & artifacts
- Harbor (HA, S3-backed)
- distribution + object storage
- Nexus
- Artifactory
- replication policy
Secrets & supply chain
- Vault (dynamic credentials)
- OIDC workload identity
- cosign signing
- SBOM generation
- SLSA provenance
Build infrastructure
- shared build cache (S3)
- Bazel remote cache
- Docker-in-Docker vs. BuildKit
- multi-arch build nodes
Delivery
- Argo CD / Flux
- Argo Rollouts
- environment promotion
- preview environments
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- No build waits more than an agreed threshold at peak hour, proven by queue-depth metrics.
- Community registry outage survivable: the registry is HA and a restore has been timed.
- Zero long-lived static credentials in pipeline configuration.
- Median and p95 build duration are measured, published, and improving against a target.
- A new project gets a working pipeline from a template without platform-team involvement.
What we would build, and where the weak point is
The registry is the dependency nobody lists. If it is a single instance with local disk, every team is one disk failure away from not being able to deploy anything — including the fix.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Requires partner
Source control hosting and repository governance
We operate self-managed source control and integrate with hosted providers. Repository policy and branching model are your engineering standards.
- Out of scope
Application test strategy and test code
We make the pipeline fast and reliable. Writing the tests that run in it is your engineering team’s work.
- Out of scope
Developer laptop tooling and local environment support
Desktop support is a different discipline. We will document how to run your stack locally, then step back.
- Out of scope
Commercial CI vendor contract negotiation and seat licensing
We will model the cost of options against your usage. The contract is yours to negotiate.
What it looked like last time
A software company running 3,400 pipelines a day on one Jenkins server with local executors: runners moved onto Kubernetes with class-based autoscaling and per-team quotas, Harbor made highly available and replicated to object storage, pipeline secrets moved to short-lived Vault credentials, and pipeline health put on a dashboard the teams watch themselves.
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the platform engineer about your ci/cd & artifact platforms
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a platform engineer: botonwa@gmail.com · +86 130 5181 3099