Zelfgebouwde GitHub Actions voor Salesforce: wat gebeurt er als de bouwer vertrekt?

Kort antwoord: de eerste twee weken gebeurt er niets. Daarna verandert een Salesforce-release een API-versie, verloopt een certificaat, laat een runner-image een afhankelijkheid vallen, en faalt de deploy met een foutmelding waar niemand een notitie over heeft achtergelaten. Een zelfgebouwde Salesforce-pipeline is zelden infrastructuur. Het is een persoonlijk project met een busfactor van één, en de rekening komt ongeveer achttien maanden later.

Waarom voelt een zelfgebouwde pipeline in het begin gratis?

Omdat de bouw echt goedkoop is. De publieke tutorials zijn goed: JWT-authenticatie naar een connected app, secrets in de repository, een workflowbestand per branch, sfdx-git-delta om alleen het gewijzigde te deployen, en een testrun met een dekkingsdrempel (Salesforce Ben heeft een degelijke walkthrough). Een goede engineer heeft dat in een paar weken draaiend, en het eerste jaar werkt het.

Wat de tutorials niet behandelen, is wie het daarna bezit. Lees de reacties onder zo'n artikel en je vindt het echte verhaal: verouderde commando's, verlopen authenticatie, een Java-versie die verdween. Die reacties zijn de onderhoudsrekening in het klein.

Waarom breekt de pipeline na ongeveer achttien maanden?

Omdat alles eronder beweegt en de YAML niet.

• Drie Salesforce-releases per jaar. API-versies schuiven op, metadatavormen veranderen, en vastgezette versies in de workflow raken stilletjes achterop.
• De CLI verandert. Commando's krijgen andere namen en verdwijnen. Scripts op de oude namen blijven werken tot ze het niet meer doen.
• Certificaten en secrets verlopen. Het zelfondertekende certificaat achter de JWT-connected app heeft een vervaldatum die niemand in een agenda heeft gezet.
• Runner-images veranderen. Gehoste runners werken hun besturingssysteem, Node- en Java-versies bij op hun schema, niet op het jouwe.
• Externe actions driften. De deltatool, de scanner en de community-actions op een tag hebben allemaal hun eigen releasecyclus en breaking changes.
• De org groeit. De pipeline was ontworpen voor twee sandboxen en vier bijdragers. Hij bedient nu vijf omgevingen, een package en mensen die nooit een terminal hebben geopend.

Geen van deze dingen is op zichzelf moeilijk. Ze zijn moeilijk omdat ze op dinsdagmiddag arriveren, in een releasevenster, in een repository waarvan de auteur in maart is vertrokken.

Wat kost het onderhoud werkelijk?

Het eerlijke antwoord: het is een permanente, niet-begrote deeltijdbaan. De literatuur van de leveranciers is het over de vorm eens, ook al komen de cijfers van verschillende plekken: Gearset zet, met verwijzing naar Harvard Business Review, budgetoverschrijdingen bij zelfbouwsoftware op 70% (build or buy), en Copado stelt dat gevestigde DevOps-leveranciers 10 tot 15% van hun ontwikkelcapaciteit uitsluitend besteden aan het bijhouden van Salesforce-platformwijzigingen (the hidden costs of building your own). Samengelezen is de conclusie ongemakkelijk maar simpel: een gespecialiseerde leverancier behandelt platformcompatibiliteit als een fulltime engineeringprogramma. Jouw pipeline krijgt wat er overblijft van iemands vrijdag.

De kosten die nooit in een business case belanden:

• De release die stilstaat terwijl iemand een workflowbestand uitpluist dat hij niet heeft geschreven.
• De admin die geen deployments meer aanvraagt omdat de pipeline hem afschrikt, en terugging naar change sets.
• De tweede pipeline, naast de eerste gebouwd, omdat niemand de originele durfde aan te raken.
• De inwerkbelasting op elke nieuwe engineer die een maatwerksysteem moet leren dat nergens anders bestaat.

Hoe test je je eigen busfactor?

Vijf vragen. Beantwoord ze deze week eerlijk, en niet tijdens een opzegging.

1. Als de pipeline nu zou falen, hoeveel mensen kunnen dan het log lezen en de oorzaak benoemen?
2. Waar staat de runbook, en wanneer klopte hij voor het laatst?
3. Wie roteert de credentials, en wat is de vervaldatum van het huidige certificaat?
4. Kan iemand die geen developer is een deployment starten en het resultaat begrijpen?
5. Als je dit morgen aan een externe moest overdragen, hoe lang tot die productief is?

Zijn vier van die antwoorden de naam van één persoon, dan heb je geen pipeline. Dan heb je een afhankelijkheid.

Wanneer is zelf bouwen nog steeds de juiste keuze?

Als de pipeline als product wordt behandeld en niet als gunst. Dus: een eigenaar met naam die niet de enige is, een tweede persoon die hem echt weleens heeft gerepareerd, documentatie die is getest door iemand die hem volgt, vastgezette en beoordeelde afhankelijkheden, en een regel in een budget. Genoeg teams halen die lat, zeker met een echte platform-engineeringfunctie en bijzondere eisen die geen leverancier dekt. Heb je diepe interne DevOps-capaciteit en de bereidheid die te financieren, dan is zelfbouw verdedigbaar.

Wat niet werkt is het midden: een maatwerksysteem zonder eigenaar, in een team dat eigenlijk Salesforce-functionaliteit moet opleveren.

Wat doe je in de week dat hij zijn ontslag indient?

1. Ga naast hem zitten en breek de pipeline expres in een sandbox. Kijk hoe hij diagnosticeert en leg het vast.
2. Inventariseer elk secret, certificaat en serviceaccount, met vervaldatum.
3. Laat een tweede persoon een volledige deployment doen, zonder hulp, terwijl de auteur toekijkt zonder het toetsenbord aan te raken.
4. Schrijf de drie meest voorkomende storingen op, met de oplossing per stuk.
5. Beslis bewust of je hem houdt of vervangt. Het besluit in drijven is wat geld kost.

Precies daar verdient een ondersteund platform zichzelf terug. Serpent bestaat zodat een Salesforce-pipeline niet het zijproject van één persoon is: deployments verlopen via tickets met Git eronder, zodat admins en consultants releases kunnen aanvragen en volgen zonder CLI, en platformcompatibiliteit is ons probleem in plaats van dat van je vertrekkende collega. Het installeert niets in je org en werkt via standaard-API's, de prijs is vast per bedrijf met onbeperkt gebruikers, en er is een gratis Essentials-plan om het op je eigen org te proberen. Opzetten duurt minder dan 15 minuten en ons team doet de onboardingsessie met je mee.

FAQ

Zijn GitHub Actions een slechte keuze voor Salesforce-CI/CD?

Nee. Het is een sterk CI-systeem en veel teams draaien er prima op. Het risico zit niet in de tool maar in een maatwerkpipeline met één eigenaar en geen onderhoudsbudget.

Hoe lang gaat een zelfgebouwde Salesforce-pipeline mee?

Meestal werkt hij het eerste jaar prima, en daarna begint hij echt tijd te kosten naarmate Salesforce-releases, CLI-wijzigingen, verlopende credentials en runner-updates zich opstapelen.

Wat breekt als eerste als de auteur vertrekt?

Meestal de authenticatie. Verlopen certificaten en geroteerde secrets falen luid, en juist in het deel van de opzet dat één keer is geconfigureerd en nooit gedocumenteerd.

Hoe verlagen we de busfactor zonder de pipeline te vervangen?

Geef hem een eigenaar en een plaatsvervanger bij naam, zet een geteste runbook in de repository, agendeer elke vervaldatum, en laat minstens maandelijks een tweede persoon zelfstandig een echte deployment draaien.

Is kopen altijd goedkoper dan bouwen?

Niet altijd. Bouwen is verdedigbaar met echte platform-engineeringcapaciteit en een gefinancierde eigenaar. Het wordt duur zodra de pipeline een gunst is van iemand wiens eigenlijke werk features opleveren is.