Andrew Hanna

Aktualisiert vor 3 Monaten

Eine Salesforce CI/CD Pipeline mit GitHub Actions bauen

Salesforce development hat sich weit von manuellen Change Sets entfernt. Wenn Teams wachsen und Releases häufiger werden, werden manuelle deployments schnell zum Engpass.

Hier kommt CI/CD (Continuous Integration and Continuous Delivery) ins Spiel. Eine gute Pipeline validiert, testet und promotet Änderungen automatisch von development bis production.

In diesem Guide zeigen wir, wie Salesforce CI/CD funktioniert, wie Sie eine Pipeline mit GitHub Actions bauen und wann DIY automation an ihre Grenzen kommt.

Warum CI/CD für Salesforce wichtig ist

Salesforce Teams liefern keine kompilierte App aus. Sie deployen metadata und Konfiguration:

Apex classes und triggers
Lightning Web Components
Flows und automation
Profiles, permission sets, objects, fields und layouts

Ohne automation entstehen environment drift, fehlende dependencies, manuelle Fehler und wenig Sichtbarkeit darüber, was sich wirklich geändert hat.

CI/CD pipelines lösen das, indem sie:

Änderungen automatisch validieren
Tests vor deployment ausführen
Git als source of truth nutzen
nur genehmigte Änderungen promoten

Salesforce development models

1. Org-based development

Dies ist weiterhin das häufigste Modell. Developers arbeiten in sandboxes, metadata wird nach Git geholt und CI/CD promotet diese metadata durch die Umgebungen.

Developer Sandbox
      ↓
QA
      ↓
UAT / Staging
      ↓
Production

2. Package-based development

Package-based development nutzt modulare Packages, statt den gesamten metadata tree als eine Einheit zu promoten. Das passt zu ISVs, AppExchange partners und Enterprise Teams mit mehreren Workstreams.

Empfohlene Patterns nach Teamgröße

Kleine Teams

Developer Sandbox
      ↓
Retrieve to Git
      ↓
Pull Request validation
      ↓
Build unlocked package version
      ↓
Install in Staging / QA Sandbox
      ↓
Install same package version in Production

Das funktioniert, wenn das Team klein und eng abgestimmt ist und eine staging oder QA Umgebung für signoff reicht.

Wachsende Teams

Größere Teams brauchen meist getrennte QA und UAT. QA validiert integrierte source changes, während UAT das release artifact prüft, das nach production geht.

Qa Devops

Developer Sandbox
      ↓
Feature branch
      ↓
Pull Request validation
      ↓
Merge to develop
      ↓
Deploy source to QA
      ↓
Create release branch
      ↓
Build unlocked package version
      ↓
Install package in UAT
      ↓
Install same package version in Production

ISVs und modular packages

ISVs starten oft package-led. Große orgs wechseln häufig zu modular unlocked packages, etwa für sales, service operations, onboarding und core automation.

Branching strategy

Vor der Pipeline sollten Sie festlegen, wie Arbeit durch Git läuft. Die häufigsten Optionen sind GitFlow und trunk-based development.

GitFlow

main      → production history
develop   → integration branch
feature/* → work item branches
release/* → release candidate branches
hotfix/*  → urgent production fixes

GitFlow passt zu Teams mit QA, UAT, scheduled releases und expliziten release candidate branches. Trunk-based development passt besser zu kleinen reifen Teams mit starker automation und häufigen deployments.

Empfohlene Pipeline-Architektur

Für die meisten wachsenden Salesforce Teams empfehlen wir:

Developer Sandbox
      ↓
Retrieve metadata to Git
      ↓
Feature branch
      ↓
Pull Request validation
      ↓
Merge to develop
      ↓
Deploy source to QA
      ↓
Create release branch
      ↓
Build unlocked package version
      ↓
Install package in UAT
      ↓
Regression testing and signoff
      ↓
Install same package version in Production

Source deploys nach QA sind schnell für integration testing. Die package version wird danach zum stabilen release artifact für UAT und production.

package.xml vs source tracking vs Serpent workflow

Kategorie	Package.xml	Source tracking + unlocked packages	Serpent workflow
Modell	Manifest-driven deployment	Git-driven development mit package promotion	Task-driven workflow rund um Git, Umgebungen und Releases
Best for	Hotfixes und legacy teams	Moderne Teams mit versioned releases	Teams, die Tempo, Sichtbarkeit und weniger friction wollen
Dependencies	Manuell	Besser, aber Disziplin nötig	Unterstützt durch metadata analysis und workflow logic
Zusammenarbeit	Meist manuell	Git-centric und developer-friendly	Für developers, admins, testers und release managers geeignet

package.xml und source tracking

package.xml ist das traditionelle manifest für metadata, die Sie retrieve oder deployen wollen.

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <members>AccountService</members>
    <name>ApexClass</name>
  </types>
  <version>61.0</version>
</Package>

Es gibt explizite Kontrolle, ist aber manuell, dependency-anfällig und bei großen releases schwerer zu pflegen.

Source tracking vergleicht Änderungen in einer org mit lokaler source:

sf project retrieve start
sf project deploy start

Für die meisten modernen Teams ist source tracking im development sinnvoll, während unlocked packages die release promotion übernehmen.

Feature-level changes sicher auswählen

Eine sandbox enthält oft mehrere Änderungen. Das sichere Muster ist: alles retrieve, nur die Komponenten einer feature auswählen und diesen Scope in eine feature branch committen.

sf project retrieve start
git status
git add force-app/main/default/classes/PricingService.cls
git add force-app/main/default/triggers/OpportunityTrigger.trigger
git commit -m "Feature: pricing approval flow"

Mit Serpent wird das einfacher, weil work items, metadata selection und dependency analysis in einem Workflow zusammenliegen.

Delta deployments vs full branch deployments

Delta deployments sind nützlich für schnelle PR validation und kleine isolierte Features.

sf sgd source delta \
  --to HEAD \
  --from origin/develop \
  --output-dir delta \
  --generate-delta

sf project deploy validate --source-dir delta --test-level RunLocalTests
sf project deploy start --source-dir delta

Full deployments sind besser für destructive changes, revert commits und das Zurücksetzen von drift in gemeinsamen Umgebungen.

sf project deploy start --source-dir force-app

Unlocked packages für release versioning

Unlocked packages machen releases expliziter: Sie promoten ein versioned artifact statt lose metadata. Das verbessert traceability, UAT-to-production promotion und rollback planning.

sf package create --name SalesApp --package-type Unlocked --path force-app
sf package version create --package SalesApp --wait 20 --installation-key-bypass
sf package install --package 04tXXXXXXXXXXXX --target-org myUATOrg --wait 20
sf package install --package 04tXXXXXXXXXXXX --target-org myProdOrg --wait 20

GitHub Actions Pipeline bauen

GitHub Actions eignet sich für Teams, die die mechanics verstehen und ihre eigene CI/CD foundation im repository bauen wollen. Workflows werden als YAML definiert.

feature/*   → developer work item branches
develop     → deployed to QA
release/*   → package version build
main        → production history
hotfix/*    → urgent production fixes

name: Salesforce CI/CD

on:
  pull_request:
    branches: [develop]
  push:
    branches:
      - develop
      - 'release/*'
  workflow_dispatch:
    inputs:
      package_version_id:
        required: false

env:
  PROJECT_DIR: force-app
  QA_ALIAS: qa
  UAT_ALIAS: uat
  PROD_ALIAS: prod
  PACKAGE_NAME: SalesApp

jobs:
  pr-validate:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install @salesforce/cli --global
      - run: sf plugins install sfdx-git-delta
      - run: echo "${{ secrets.SF_JWT_KEY_QA }}" > server.key
      - run: |
          sf org login jwt \
            --client-id ${{ secrets.SF_CLIENT_ID_QA }} \
            --jwt-key-file server.key \
            --username ${{ secrets.SF_USERNAME_QA }} \
            --instance-url ${{ secrets.SF_INSTANCE_URL_QA }} \
            --alias $QA_ALIAS
      - run: |
          sf sgd source delta --to HEAD --from origin/develop --output-dir delta --generate-delta
          sf project deploy validate --source-dir delta --target-org $QA_ALIAS --test-level RunLocalTests

In production fügen Teams meist separate Jobs für deploy to QA, package version build, install in UAT und manuelle promotion nach production hinzu.

Connected App und JWT authentication

Erstellen Sie eine Connected App im Salesforce App Manager.
Setzen Sie die callback URL auf http://localhost:1717/OauthRedirect.
Wählen Sie OAuth scopes wie api und refresh_token, offline_access.
Laden Sie ein certificate hoch und speichern Sie den private key in GitHub Secrets.

openssl genrsa -out server.key 2048
openssl req -new -x509 -days 1825 -key server.key -out server.crt

Häufige Fehler

Error	Wahrscheinliche Ursache	Fix
`INVALID_LOGIN`	JWT key oder client ID falsch	Secrets und trailing newlines prüfen.
`INSUFFICIENT_ACCESS`	Connected App permissions	Scopes und Aktivierung für den integration user prüfen.
Tests failing on deploy	Code coverage unter 75%	`sf apex run test` lokal ausführen und coverage erhöhen.

Fazit

Salesforce DevOps hängt nicht von einem einzelnen Tool oder einem perfekten Pipeline Format ab. Entscheidend ist ein zuverlässiger Prozess, in dem Git die source of truth ist, Änderungen automatisch validiert werden und releases versioned und traceable sind.

GitHub Actions hilft Teams, automation unter der Oberfläche zu verstehen. Wenn Salesforce environments komplexer werden, helfen Tools wie Serpent, Tempo, Kontrolle, Sichtbarkeit und release confidence zu behalten.