Back-promotie instellen in een Salesforce DevOps-pipeline

Kort antwoord: back-promotie is de merge die een productiewijziging weer omlaag brengt naar elke lagere branch en org in je pipeline. Je hebt het nodig omdat een hotfix die rechtstreeks in productie is gezet nergens anders bestaat, waardoor de volgende gewone release hem stilletjes overschrijft. De veilige manier om dit te automatiseren is een trapsgewijze merge, één omgeving tegelijk, geopend als pull request en niet gepusht door een script.

Wat is back-promotie in een Salesforce-pipeline?

Een gewone promotie brengt een wijziging omhoog: dev naar integration naar uat naar main. Back-promotie gaat de andere kant op en merget wat al in een hogere omgeving staat naar beneden, zodat de lagere omgevingen weer kloppen.

Er moeten twee dingen meereizen, en de meeste teams doen alleen het eerste:

• De broncode. Merge de hogere branch in de lagere branch, zodat de repository het met zichzelf eens is.
• De org. Deploy die merge naar de lagere sandbox, anders bouw je je volgende werk op metadata die niet meer overeenkomt met productie.

Waarom hebben hotfixes een weg terug omlaag nodig?

Omdat een hotfix de aanname breekt waar je pipeline op rust: dat productie alleen ontvangt wat via de keten omhoog is gekomen. Breek die aanname en er volgen drie problemen.

• Stille regressie. De volgende release deployt de oudere versie van hetzelfde component en de fix verdwijnt. Er gaat niets mis, dus niemand merkt het tot het incident zich herhaalt.
• Onbetrouwbare UAT. Je test tegen een toestand waarin productie niet meer verkeert.
• Stapelende conflicten. Elke dag dat de branches uit elkaar blijven lopen wordt de uiteindelijke merge groter en handmatiger.

Buitenom-wijzigingen zijn niet alleen hotfixes. Een page layout die tijdens een incident in productie is aangepast, een picklistwaarde voor support, een veld dat is toegevoegd om een gebruiker te deblokkeren: ze hebben allemaal dezelfde weg terug nodig.

Wat veroorzaakt de mergechaos eigenlijk, en hoe voorkom je die?

Dit is het deel dat de meeste handleidingen overslaan. Back-promotie gaat op voorspelbare manieren mis, en vijf regels voorkomen bijna alles.

1. Merge omlaag, cherry-pick niet. Een cherry-pick maakt een nieuwe commit met een andere hash, dus Git beschouwt het origineel nog steeds als niet gemerged en gooit hetzelfde conflict bij elke volgende merge opnieuw op. Merge de branch.
2. Cascadeer stap voor stap, in pipelinevolgorde. main in uat, dan uat in integration, dan integration in dev. main direct in dev mergen laat de overgeslagen branches later conflicteren.
3. Voer het uit op de dag dat de hotfix live gaat. Divergentie is goedkoop in uren en duur in weken.
4. Open een pull request, push niet. Een automatisering die stil merget haalt de review en het audit trail weg, precies de twee dingen die een hotfix het hardst nodig heeft.
5. Faal luid bij een conflict en wijs het toe aan de auteur van de hotfix. Die heeft de context. Een conflict dat bij de dienstdoende collega belandt, wordt opgelost met gokwerk.

Back-promotie is geen deployprobleem. Het is een probleem van branchhygiëne dat zich drie weken later als deployprobleem meldt.

Hoe zet je back-promotie stap voor stap op?

1. Schrijf de pipelinevolgorde op. Eén geordende lijst van omgevingen en de branch waar elke bij hoort. Zonder die lijst betekent back-promotie niets.
2. Geef hotfixes een eigen branch vanaf productie. Branch vanaf main, nooit vanaf dev, zodat de fix niets ongereleased meeneemt.
3. Laat de hotfix door de normale poorten gaan. Dezelfde tests, dezelfde review, dezelfde goedkeuring, alleen een kortere route.
4. Trigger de cascade bij merge naar main. De pipeline opent automatisch een back-promotie-pull-request naar de eerstvolgende branch eronder.
5. Deploy elke gemergede branch naar zijn org. Gelijke broncode zonder gelijke org laat de drift precies staan waar hij stond.
6. Controleer met een driftcheck. Vergelijk elke lagere org met zijn branch zodra de cascade klaar is. Een verschil betekent dat er iets in de org is gewijzigd en nooit is gecommit.
7. Leg het vast op het work item. Een hotfix is niet klaar als productie werkt. Hij is klaar als elke omgeving hem draagt.

Is een sandbox refresh een vervanging voor back-promotie?

Nee, en dat wel denken is een veelgemaakte en dure fout. Een refresh vervangt de sandbox door een kopie van productie, wat de hotfix inderdaad meebrengt, en vernietigt onderweg elke ongereleasede wijziging in die sandbox. Refreshes zijn bovendien gerantsoeneerd: een Full sandbox kan maar eens per 29 dagen worden ververst (Salesforce Help), dus het is een geplande gebeurtenis en geen incidentrespons.

Gebruik refreshes om data en langlopende drift te resetten. Gebruik back-promotie om broncode en orgs daartussenin gelijk te houden. De meeste Salesforce DevOps-platformen ondersteunen deze vorm in enige mate, waaronder Copado, Gearset, AutoRABIT, Flosum, Blue Canvas en Salto. Wat verschilt is of de cascade automatisch is en of hij als beoordeelbare pull request binnenkomt.

FAQ

Wat is het verschil tussen promotie en back-promotie?

Promotie brengt een wijziging omhoog richting productie. Back-promotie brengt een bestaande wijziging uit een hogere omgeving omlaag, zodat de lagere omgevingen niet verder afdrijven.

Moet back-promotie volledig automatisch zijn?

De trigger en de pull request wel. De merge zelf hoort nog steeds te worden goedgekeurd, want een conflict dat zonder review wordt opgelost is precies hoe een hotfix twee keer ongedaan wordt gemaakt.

Hoe gaan we om met een conflict tijdens back-promotie?

Los het op in de back-promotiebranch, in het voordeel van het productiegedrag, en laat degene die de hotfix schreef het bevestigen. Los het nooit op door de lagere branch integraal over te nemen.

Hebben we back-promotie nodig als niemand rechtstreeks in productie werkt?

Ja, alleen minder vaak. Langlopende releasebranches, teruggedraaide releases en patchversies van packages zetten allemaal wijzigingen in hogere omgevingen die de lagere niet hebben.

Meer stapsgewijze pipeline-playbooks staan in de SF Guides-bibliotheek. Opent je pipeline de cascade vandaag nog niet, begin dan met regel twee: stap voor stap, in volgorde. Dan is back-promotie niet langer de klus die niemand wil.