Git-Branches Salesforce-Sandboxes zuordnen

Git-Branches Salesforce-Sandboxes zuzuordnen heisst zu entscheiden, welcher Branch die Source of Truth fuer jede Umgebung ist, damit eine Aenderung ueber gepruefte Merges statt Org-zu-Org-Deployments von Dev in die Produktion wandert. Langlebige Branches werden persistenten Sandboxes zugeordnet; kurzlebige Feature-Branches Scratch Orgs und Developer-Sandboxes. Stimmt die Zuordnung, ist Befoerderung nur ein Merge. Stimmt sie nicht, erbst du Merges von Merges und stille Drift.

Dieser Leitfaden behandelt die Zuordnungsmechanik, nicht die Wahl des Modells. Wenn du noch zwischen Trunk-based, GitFlow und Branch pro Umgebung schwankst, beginne mit Git-Branching-Strategien fuer Salesforce-Teams: eine Entscheidungsregel, und komm dann hierher zurueck, um es mit deinen Orgs zu verdrahten.

Welcher Sandbox-Typ stuetzt welchen Branch?

Ein Branch ist nur real, wenn es eine Org gibt, in die man ihn deployen und testen kann. Ordne jeden Branch dem Sandbox-Typ zu, der zu seinem Zweck und seiner Refresh-Kadenz passt:

• Feature-Branch zu einer Scratch Org oder Developer-Sandbox. Wegwerfbar, pro Ticket erstellt, beim Merge verworfen.
• Integration-Branch zu einer Developer-Pro-Sandbox, wo Feature-Arbeit landet und gemeinsam getestet wird.
• UAT-Branch zu einer Partial-Copy- oder Full-Sandbox, damit Business-User gegen repraesentative Daten testen.
• Main-Branch zur Produktion, stets geschuetzt und nur ueber einen gepruefen Merge aktualisiert.

Die Refresh-Kadenz begrenzt, wie viele langlebige Branches du wirklich stuetzen kannst. Salesforce setzt Mindest-Refresh-Intervalle von einem Tag fuer Developer und Developer Pro, fuenf Tagen fuer Partial Copy und 29 Tagen fuer Full, ein Branch, den du nicht refreshen kannst, ist also ein Branch, dem du nicht trauen kannst.

Wie fliesst die Befoerderung zwischen Branches?

Befoerderung ist ein Merge, kein Redeploy. Eine Aenderung startet auf einem Feature-Branch und steigt die Kette hinauf, sobald sie jedes Tor passiert:

1. Ziehe einen Feature-Branch, entwickle gegen seine Scratch Org oder Developer-Sandbox.
2. Oeffne einen Pull Request in den Integration-Branch; beim Merge Deploy in die Integrations-Sandbox.
3. Merge Integration in den UAT-Branch fuer die Business-Freigabe in der Partial-Copy- oder Full-Sandbox.
4. Merge UAT in Main; das Deploy in die Produktion ist dieselbe Metadata, die UAT bereits bestanden hat.

Die Regel, die den meisten Schmerz erspart: lass einen Branch, der der Produktion zugeordnet ist, nie einen direkten Commit annehmen. Alles erreicht ihn ueber einen gepruefen Merge, sodass die Branch-Historie auch deine Deployment-Historie ist.

Wie haelt Source Tracking einen Branch und seine Org im Gleichtakt?

Source Tracking erfasst, welche Metadata sich in einer Sandbox geaendert hat, sodass du diese Aenderungen in den Branch ziehst, statt einen vollstaendigen Retrieve zu raten. Deploye aus git in die zugeordnete Org und lass Source Tracking alles markieren, was ein Admin direkt in dieser Org geaendert hat. Diese Schleife haelt den Branch als Source of Truth und verhindert, dass Org und Branch leise auseinanderlaufen.

Daten, org-weite Einstellungen und Lizenzen leben ausserhalb des Repos, die Zuordnung deckt also nur Metadata ab. Behandle jene als Umgebungskonfiguration, die du separat seedest, nicht als etwas, das ein Branch befoerdern kann.

Was sind die haeufigen Zuordnungsfehler?

• Ein langlebiger Branch pro Developer-Sandbox. Jeder zusaetzliche langlebige Branch ist ein weiteres Merge-Ziel, das driftet. Halte Feature-Branches kurz und wegwerfbar.
• Org zu Org deployen und es Befoerderung nennen. Wenn der Branch nicht das ist, was du deployst, hoert die Branch-Historie auf, dem Live-Stand zu entsprechen.
• Einen UAT-Branch mit einer Developer-Sandbox stuetzen. Ohne repraesentative Daten testet die Freigabe das Falsche und uebersieht datengeformte Bugs.
• Admins die Produktion direkt aendern lassen. Ein Klick in der Produktion, der nie in git landet, macht deine Zuordnung beim naechsten Deploy zur Fiktion.

Lass die Zuordnung sich selbst erzwingen

Eine Zuordnung, die in einem Onboarding-Dokument lebt, bricht in der ersten vollen Release-Woche. Serpent arbeitet ticketbasiert mit Git im Hintergrund, sodass der Branch, seine Sandbox und der Befoerderungspfad aus dem Ticket kommen statt aus dem Gedaechtnis. Weitere Pipeline-Leitfaeden finden Sie in unserer SF-Guides-Bibliothek.

FAQ

Brauche ich einen Branch pro Sandbox?

Nein. Ordne langlebige Branches nur persistenten Umgebungen wie Integration, UAT und Produktion zu. Nutze kurzlebige Feature-Branches fuer Scratch- und Developer-Orgs.

Welche Sandbox sollte meinen UAT-Branch stuetzen?

Eine Partial-Copy- oder Full-Sandbox, damit Business-User gegen repraesentative Daten testen statt gegen eine leere Developer-Org.

Wie wird eine Aenderung zwischen Umgebungen befoerdert?

Ueber einen gepruefen Merge von einem Branch zum naechsten, gefolgt von einem Deploy aus git in die zugeordnete Org. Befoerderung ist ein Merge, kein Redeploy aus einer Org.

Was haelt einen Branch und seine Org davon ab, auseinanderzulaufen?

Source Tracking plus Deploy-aus-git. Der Branch bleibt Source of Truth, und jede direkte Org-Aenderung taucht als getrackter Diff zum Abgleich auf.

Welches Branching-Modell ordne ich zuerst zu?

Waehle das Modell vor der Zuordnung. Siehe unsere Entscheidungsregel zur Wahl nach Teamgroesse und Sandbox-Topologie.