Back-Promotion in einer Salesforce-DevOps-Pipeline einrichten

Kurze Antwort: Back-Promotion ist der Merge, der eine Produktivänderung wieder hinunter in jeden tieferen Branch und jede tiefere Org Ihrer Pipeline trägt. Sie brauchen ihn, weil ein direkt in der Produktion angewandter Hotfix sonst nirgends existiert und die nächste gewöhnliche Auslieferung ihn stillschweigend überschreibt. Der sichere Weg zur Automatisierung ist ein kaskadierender Merge, eine Umgebung nach der anderen, als Pull Request geöffnet statt per Skript gepusht.

Was ist Back-Promotion in einer Salesforce-Pipeline?

Eine normale Promotion bewegt eine Änderung nach oben: dev nach integration nach uat nach main. Back-Promotion geht in die Gegenrichtung: Sie nimmt, was in einer höheren Umgebung bereits vorhanden ist, und merged es nach unten, damit die tieferen Umgebungen wieder übereinstimmen.

Zwei Dinge müssen mitreisen, und die meisten Teams erledigen nur das erste:

• Der Quellcode. Mergen Sie den höheren Branch in den tieferen, damit das Repository mit sich selbst übereinstimmt.
• Die Org. Deployen Sie diesen Merge in die tiefere Sandbox, sonst bauen Sie Ihre nächste Arbeit auf Metadaten, die nicht mehr zur Produktion passen.

Warum brauchen Hotfixes einen Weg zurück nach unten?

Weil ein Hotfix die Annahme bricht, auf der Ihre Pipeline steht: dass die Produktion nur erhält, was die Kette hinaufgekommen ist. Bricht diese Annahme, folgen drei Fehler.

• Stille Regression. Die nächste Auslieferung deployt die ältere Version derselben Komponente, und der Fix verschwindet. Nichts schlägt fehl, also merkt es niemand, bis sich der Vorfall wiederholt.
• Unzuverlässiges UAT. Sie testen gegen einen Zustand, in dem die Produktion nicht mehr ist.
• Wachsende Konflikte. Mit jedem Tag, den die Branches auseinanderlaufen, wird der spätere Merge größer und manueller.

Änderungen am Prozess vorbei sind nicht nur Hotfixes. Ein während eines Vorfalls in der Produktion geändertes Page Layout, ein für den Support ergänzter Auswahllistenwert, ein Feld, das eine Nutzerin entsperren sollte: Sie alle brauchen denselben Rückweg.

Was erzeugt das Merge-Chaos wirklich, und wie vermeiden Sie es?

Das ist der Teil, den die meisten Anleitungen auslassen. Back-Promotion scheitert auf vorhersehbare Weise, und fünf Regeln verhindern fast alles davon.

1. Nach unten mergen, nicht cherry-picken. Ein Cherry-Pick erzeugt einen neuen Commit mit anderem Hash, also gilt das Original für Git weiter als nicht gemergt und bringt denselben Konflikt bei jedem künftigen Merge erneut hoch. Mergen Sie den Branch.
2. Eine Stufe nach der anderen, in Pipeline-Reihenfolge. main in uat, dann uat in integration, dann integration in dev. Wer main direkt in dev merged, überlässt den übersprungenen Branches den Konflikt für später.
3. Führen Sie ihn am Tag des Hotfixes aus. Divergenz ist über Stunden billig und über Wochen teuer.
4. Öffnen Sie einen Pull Request, pushen Sie nicht. Eine Automatisierung, die still merged, entfernt Review und Audit-Trail, also genau das, was ein Hotfix am dringendsten braucht.
5. Bei Konflikt laut scheitern und der Hotfix-Autorin zuweisen. Sie hat den Kontext. Ein Konflikt, der bei der Bereitschaft landet, wird durch Raten gelöst.

Back-Promotion ist kein Deployment-Problem. Es ist ein Problem der Branch-Hygiene, das sich drei Wochen später als Deployment-Problem meldet.

Wie richten Sie Back-Promotion Schritt für Schritt ein?

1. Schreiben Sie die Pipeline-Reihenfolge auf. Eine geordnete Liste der Umgebungen und des jeweils zugehörigen Branch. Ohne sie bedeutet Back-Promotion nichts.
2. Geben Sie Hotfixes einen eigenen Branch aus der Produktion. Von main abzweigen, nie von dev, damit der Fix nichts Unveröffentlichtes mitnimmt.
3. Schicken Sie den Hotfix durch die normalen Tore. Dieselben Tests, dasselbe Review, dieselbe Freigabe, nur auf kürzerem Weg.
4. Lösen Sie die Kaskade beim Merge nach main aus. Die Pipeline öffnet automatisch einen Back-Promotion-Pull-Request in den nächsttieferen Branch.
5. Deployen Sie jeden gemergten Branch in seine Org. Quellcode-Gleichstand ohne Org-Gleichstand lässt die Abweichung genau dort, wo sie war.
6. Prüfen Sie mit einer Drift-Kontrolle. Vergleichen Sie jede tiefere Org mit ihrem Branch, sobald die Kaskade durch ist. Ein Unterschied heißt: In der Org wurde etwas geändert und nie committet.
7. Halten Sie es am Work Item fest. Ein Hotfix ist nicht fertig, wenn die Produktion läuft. Er ist fertig, wenn jede Umgebung ihn trägt.

Ersetzt ein Sandbox-Refresh die Back-Promotion?

Nein, und das anzunehmen ist ein häufiger und teurer Fehler. Ein Refresh ersetzt die Sandbox durch eine Kopie der Produktion, bringt den Hotfix damit tatsächlich herunter und zerstört unterwegs jede unveröffentlichte Änderung in dieser Sandbox. Refreshes sind zudem rationiert: Eine Full-Sandbox lässt sich nur alle 29 Tage auffrischen (Salesforce Help), also ein geplantes Ereignis und keine Reaktion auf einen Vorfall.

Nutzen Sie Refreshes, um Daten und langfristige Abweichungen zurückzusetzen. Nutzen Sie Back-Promotion, um Quellcode und Orgs dazwischen im Gleichstand zu halten. Die meisten Salesforce-DevOps-Plattformen unterstützen diese Form in irgendeiner Ausprägung, darunter Copado, Gearset, AutoRABIT, Flosum, Blue Canvas und Salto. Unterschiedlich ist, ob die Kaskade automatisch läuft und ob sie als prüfbarer Pull Request ankommt.

FAQ

Was ist der Unterschied zwischen Promotion und Back-Promotion?

Promotion bewegt eine Änderung die Pipeline hinauf Richtung Produktion. Back-Promotion bewegt eine bereits oben vorhandene Änderung nach unten, damit die tieferen Umgebungen nicht weiter abdriften.

Sollte Back-Promotion vollautomatisch sein?

Auslöser und Pull Request ja. Der Merge selbst sollte weiterhin freigegeben werden, denn ein ohne Review gelöster Konflikt ist genau der Weg, auf dem ein Hotfix ein zweites Mal verschwindet.

Wie gehen wir mit einem Konflikt während der Back-Promotion um?

Lösen Sie ihn im Back-Promotion-Branch zugunsten des Produktivverhaltens und lassen Sie es von der Person bestätigen, die den Hotfix geschrieben hat. Lösen Sie ihn nie, indem Sie den tieferen Branch pauschal übernehmen.

Brauchen wir Back-Promotion, wenn niemand direkt in der Produktion arbeitet?

Ja, nur seltener. Langlebige Release-Branches, zurückgenommene Auslieferungen und Patch-Versionen von Paketen setzen alle Änderungen nach oben, die unten fehlen.

Weitere Schritt-für-Schritt-Playbooks stehen in der SF-Guides-Bibliothek. Wenn Ihre Pipeline die Kaskade heute nicht für Sie öffnet, beginnen Sie mit Regel zwei: eine Stufe nach der anderen, in Reihenfolge. Dann ist Back-Promotion nicht länger die Aufgabe, die niemand will.