Running One CI/CD Standard Across a Dozen Client Codebases

Before you write a single workflow file, settle whether the client's code will live in your organization or theirs, because that decides which CI platform you're using. If a client already runs GitLab internally and wants the work to land in their group when the engagement ends, building on GitLab CI from the start avoids a painful migration at handoff. If the repository lives in your own GitHub organization for the length of the build, GitHub Actions is the natural default.

Write this decision down in the project's kickoff notes. Nothing wastes more agency engineering time than a mid-project argument about which CI platform a nearly finished project should have used from day one.

GitHub Actions' reusable workflows and GitLab CI's include keyword both let you define a standard pipeline once, in a template repository, and have every client project call it with a few project-specific inputs. That template should cover linting, running tests, and building a deployable artifact, with the deploy step parameterized by environment.

Without this, every new engineer who joins a project copies the last project's YAML file and tweaks it, and six months later no two client pipelines look alike. A shared template is the difference between a setup that takes an afternoon per new engagement and one that takes a day.

Client work carries a specific risk: the person approving a production deploy is often not the person who wrote the code, and clients expect a paper trail showing who signed off. Use required reviewers on a protected environment, GitHub Actions environments or GitLab's protected environments and approval rules, so a deploy to the client's production system needs an explicit approval from a lead, not just a passing test suite.

This also protects you contractually. When a client asks who approved a change that broke something, you want an answer in the pipeline's audit log, not in someone's memory.

Client-facing engagements eventually end, and the pipeline has to keep running without you. Document the workflow file, the required secrets, and who at the client needs write access to the CI configuration, and do it at kickoff rather than in the final week. A pipeline that only your team understands isn't a deliverable, it's a liability you're handing the client along with the code.

DevOps spend for a private software company typically runs to a few percent of ARR¹. If a client's pipeline still depends on your firm after handoff, that budgeted spend keeps flowing to you instead of becoming a line item they can plan around, which is a conversation worth having openly before the engagement ends.

When scoping a new project, a few quick checks save you from underquoting the DevOps portion of the work:

• Does the client already have a CI platform preference, and does it match yours?
• Will the client need a staging environment with its own approval gate, or just a single production deploy?
• Who on the client side will own the pipeline after handoff, and do they know YAML?
• Does the project involve any regulated data that changes how build artifacts need to be retained or logged?

Getting these answers during scoping, not during week six, is what keeps a CI/CD standard from becoming a different improvisation on every engagement.

A reusable pipeline template only pays off if every engineer who touches a client project actually understands it, rather than treating it as a black box they copy without reading. Walk new hires through the template during onboarding, specifically the parts that differ from a typical solo project: the required-reviewer gate, the artifact promotion step, and how secrets get scoped per client.

An engineer who's only ever worked from the template without understanding it will eventually improvise around it under deadline pressure, usually by skipping the review gate or hardcoding a credential to get a demo working. Catching that in code review, and explaining why the template does things the way it does, is cheaper than fixing the same mistake across three different client projects later.