Een Salesforce CI/CD-Pijplijn Opzetten met GitHub Actions

Om een Salesforce CI/CD-pijplijn met GitHub Actions op te zetten, bewaar je je metadata in Git in source format, authenticeer je GitHub bij je org met een JWT-gebaseerde Connected App, en voeg je een workflow toe die wijzigingen valideert bij elke pull request en ze deployt bij merge. De hele pijplijn leeft in een enkel .github/workflows YAML-bestand en draait op de Salesforce CLI. Deze gids doorloopt de actuele, sf v2-manier, en wijst daarna de delen aan die stilletjes stukgaan in productie. Het maakt deel uit van onze SF Guides-bibliotheek op /serpent/resources.

Wat heb je nodig voordat je begint?

Een werkende pijplijn gaat ervan uit dat een paar dingen al op hun plaats staan:

• Project in source format. Je metadata leeft onder force-app in source format, gecommit naar een GitHub-repo.
• Salesforce CLI v2 (sf). De oude sfdx CLI is uitgefaseerd, dus bouw op sf.
• Een deploy-doel. Een sandbox voor validatie en een productie- of staging-org voor de release.
• Een Connected App in de doel-org met digitale handtekeningen aan, plus een vooraf geautoriseerde integratiegebruiker.

Als je metadata nog niet in Git staat, komt die migratie eerst. We behandelen de branching- en omgevingsmechaniek in onze bijbehorende gids voor het bouwen van een Salesforce CI/CD-pijplijn met GitHub Actions.

Hoe koppel je GitHub Actions veilig aan Salesforce?

Gebruik de JWT Bearer Flow. Die is headless, heeft geen interactieve login nodig en is wat Salesforce aanbeveelt voor CI. Genereer een sleutelpaar, upload het certificaat naar een Connected App, en log daarna vanaf de runner in met de private sleutel.

1. Maak de sleutel en het certificaat: openssl genrsa -out server.key 2048 en dan openssl req -new -x509 -nodes -sha256 -days 365 -key server.key -out server.crt.
2. Maak een Connected App in de org, zet Use digital signatures aan en upload server.crt.
3. Bewaar server.key en je consumer key, gebruikersnaam en instance-URL als GitHub-repository-secrets, nooit in de YAML.
4. Authenticeer op de runner: sf org login jwt --client-id $SF_CONSUMER_KEY --jwt-key-file server.key --username $SF_USERNAME --instance-url $SF_INSTANCE_URL --set-default-org.

Hoe ziet de GitHub Actions-workflow eruit?

Het kernpatroon is een workflow met twee gedragingen, afhankelijk van het event. Valideer bij een pull request zodat niets merget dat zou falen; deploy echt wanneer de wijziging op je main-branch belandt.

• Triggers: pull_request tegen main voor validatie, push naar main voor deployment.
• Validatiestap (PR): sf project deploy validate --source-dir force-app --test-level RunLocalTests --wait 30 --verbose. Dit is een check-only run, dus er wordt niets naar de org geschreven.
• Deploystap (merge): sf project deploy start --source-dir force-app --test-level RunLocalTests --wait 30 --verbose.

Gebruik een if:-conditie op elke job zodat hetzelfde bestand beide events afhandelt. Lokale tests draaien bij validatie is wat hiervan een echte poort maakt in plaats van een stempel, en het is de ruggengraat van elke serieuze Salesforce test-automatiseringspijplijn in CI.

Hoe deploy je alleen wat veranderd is?

De hele force-app-map elke keer deployen is traag en wordt erger naarmate de repo groeit. De community-tool sfdx-git-delta berekent het verschil tussen twee commits en produceert een pakket met alleen de gewijzigde metadata:

sf sgd source delta --to HEAD --from HEAD~1 --output delta --generate-delta --source-dir force-app

Je richt het deploy-commando vervolgens op de delta-map. Het snijdt de deploytijd fors terug, maar lees de volgende sectie voordat je het blind vertrouwt.

Wat maakt een zelfgebouwde pijplijn stilletjes stuk?

De meeste tutorials eindigen bij een groene deploy. De fouten duiken later op, en ze zijn de reden dat we hier tooling omheen bouwen in plaats van teams een kaal YAML-bestand te geven:

• Verwijderingen. Een naieve delta deployt toevoegingen en bewerkingen maar verwijdert geen verwijderde componenten. Je hebt een destructive-changes-stap nodig, anders drift de metadata en stapelen verouderde componenten zich op.
• Gedeeltelijke metadata. Profiles, permission sets en enkele andere types leven nog in grote gedeelde bestanden die niet netjes diffen, dus delta-deployments kunnen ze missen of overschrijven.
• Onderhoud is van jou. Elke CLI-wijziging, elk nieuw metadatatype en elke edge case is nu de YAML van je team om te repareren. Die kosten stapelen op, en dat is precies wat back-promotie tussen omgevingen erger maakt als je het met de hand scriptt.

Als je die pijplijn liever niet voor eeuwig bezit, handelt een managed platform delta, destructive changes en de gedeeltelijke-metadata-randen voor je af. Bekijk wat Serpent dekt en wat het kost voordat je een kwartaal aan engineeringtijd in een zelfgebouwde steekt.

FAQ

Moet ik sfdx of sf gebruiken voor een Salesforce GitHub Actions-pijplijn?

Gebruik sf (Salesforce CLI v2). De oude sfdx CLI is uitgefaseerd en zou niet de basis van een nieuwe pijplijn moeten zijn.

Waarom JWT-auth in plaats van een gebruikersnaam en wachtwoord?

JWT Bearer Flow is headless en heeft geen interactieve login of MFA-prompt nodig, wat een CI-runner vereist, en Salesforce beveelt het aan voor automatisering.

Wat is het verschil tussen deploy validate en deploy start?

Validate is een check-only run die verifieert en tests draait zonder de org te wijzigen, ideaal bij pull requests; start voert de echte deployment uit bij merge.

Heb ik sfdx-git-delta nodig?

Nee, maar het is de moeite waard zodra deploys traag worden. Combineer het wel met een destructive-changes-stap zodat verwijderingen worden afgehandeld en niet stilletjes overgeslagen.