DIY GitHub Actions for Salesforce: what happens when the person who built it leaves

Short answer: nothing happens for about a fortnight. Then a Salesforce release changes an API version, a certificate expires, a runner image drops a dependency, and the deploy fails with an error nobody left behind a note about. A hand-rolled Salesforce pipeline is rarely infrastructure. It is a personal project with a bus factor of one, and the bill arrives roughly eighteen months in.

Why does a DIY Salesforce pipeline feel free at the start?

Because the build genuinely is cheap. The public tutorials are good: JWT auth into a connected app, secrets in the repository, a workflow file per branch, sfdx-git-delta to deploy only what changed, a test run gated at the coverage threshold (Salesforce Ben has a solid walkthrough). A capable engineer gets that running in a couple of weeks, and for the first year it works.

What the tutorials do not cover is who owns it afterwards. Read the comment threads under any of them: deprecated commands, expired auth, a Java version that vanished. Those comments are the maintenance bill in miniature.

Why does the pipeline break about eighteen months in?

Because everything underneath it moves and the YAML does not.

• Three Salesforce releases a year. API versions advance, metadata shapes change, and pinned versions in the workflow quietly fall behind.
• The CLI moves. Commands get renamed and deprecated. Scripts written against the old names keep working right up until they do not.
• Certificates and secrets expire. The self-signed certificate behind the JWT connected app has an expiry date that nobody put in a calendar.
• Runner images change. Hosted runners update their operating system, Node and Java versions on their own schedule, not yours.
• Third-party actions drift. The delta tool, the scanner, the community actions pinned at a tag all have their own release cycles and breaking changes.
• The org grows. The pipeline was designed for two sandboxes and four contributors. It now serves five environments, a package, and people who have never opened a terminal.

None of these is hard on its own. They are hard because they arrive on a Tuesday afternoon, in a release window, in a repository whose author left in March.

What does the maintenance actually cost?

It is a permanent, unbudgeted part-time job. The vendor literature agrees on the shape even if the numbers come from different places: Gearset, citing Harvard Business Review, puts overruns on self-build software projects at 70% (build or buy), and Copado says established DevOps vendors spend 10 to 15% of their development capacity purely on keeping up with Salesforce platform changes (the hidden costs of building your own). Read together, the point is simple: a specialist vendor treats platform compatibility as a full-time engineering programme. Your pipeline gets what is left of one person's Friday.

The costs that never make it into a business case:

• The release blocked while somebody bisects a workflow file they did not write.
• The admin who stopped raising deployments because the pipeline intimidates them, and went back to change sets.
• The second pipeline, built beside the first, because nobody dared touch the original.
• The onboarding tax on every new engineer learning a bespoke system that exists nowhere else.

How do you test your own bus factor?

Five questions. Answer them honestly this week rather than during a resignation.

1. If the pipeline failed right now, how many people could read the log and name the cause?
2. Where is the runbook, and when was it last correct?
3. Who rotates the credentials, and what is the expiry date of the current certificate?
4. Can somebody who is not a developer trigger a deployment and understand the result?
5. If you had to hand this to a contractor tomorrow, how long before they were productive?

If four of those answers are one person's name, you do not have a pipeline. You have a dependency.

When is building your own still the right call?

When the pipeline is treated as a product rather than a favour: a named owner who is not the only one, a second person who has actually fixed it, documentation someone has tested by following it, pinned dependencies, and a line in a budget. Plenty of teams meet that bar, particularly those with a real platform engineering function and requirements no vendor covers.

What does not work is the middle: a bespoke system with no owner, in a team whose actual job is delivering Salesforce features.

What do you do the week they hand in their notice?

1. Break the pipeline on purpose in a sandbox and record how they diagnose it.
2. Inventory every secret, certificate and service account, with its expiry date.
3. Have a second person run a full deployment unaided, while the author watches without touching the keyboard.
4. Write down the three failures that happen most often and the fix for each.
5. Decide, deliberately, whether you are keeping it or replacing it. Drifting into the decision is what costs money.

That last decision is where a supported platform earns its keep. Serpent exists so a Salesforce pipeline is not one person's side project: deployments are ticket-based with Git running underneath, so admins and consultants can raise and track releases without the CLI, and platform compatibility is our problem rather than your leaver's. It installs nothing in your org, pricing is flat per company with unlimited users, and a free Essentials tier lets you try it on your own org.

FAQ

Are GitHub Actions a bad choice for Salesforce CI/CD?

No. It is a strong CI system and plenty of teams run on it successfully. The risk is not the tool, it is a bespoke pipeline with a single owner and no maintenance budget.

How long does a hand-built Salesforce pipeline usually last?

It typically works well for the first year, then starts costing real time as Salesforce releases, CLI changes, expiring credentials and runner updates accumulate.

What breaks first when the author leaves?

Authentication, usually. Expired certificates and rotated secrets fail loudly, and they fail in a part of the setup that was configured once and never documented.

How do we reduce the bus factor without replacing the pipeline?

Give it a named owner and a named deputy, put a tested runbook in the repository, diarise every credential expiry, and make a second person run a real deployment unaided at least once a month.

Is buying always cheaper than building?

Not always. Building is defensible when you have real platform engineering capacity and a funded owner. It becomes expensive when the pipeline is a favour done by someone whose actual job is delivering features.