Org-Drift: Warum Ihre Salesforce-Sandboxes nicht mehr zur Produktion passen

Kurze Antwort: Org-Drift ist der aufsummierte Preis jeder Aenderung, die eine Org erreicht hat, ohne durch Ihren Prozess zu gehen. Er entsteht nicht durch einen schlechten Admin oder ein ausgelassenes Review, sondern als Summe hunderter kleiner, legitimer Ausnahmen. Und die vierteljaehrliche Sandbox-Aktualisierung, auf die die meisten Teams setzen, kann ihn nicht beheben, denn Refreshes laufen bestenfalls monatlich, waehrend Drift taeglich entsteht.

Was ist Org-Drift?

Org-Drift ist die Abweichung zwischen dem, was eine Umgebung enthaelt, und dem, was Ihre Quelle der Wahrheit sagt. Zwischen Sandbox und Produktion, zwischen zwei Sandboxes oder zwischen der Produktion und dem Repository, das sie beschreiben soll.

Das Symptom kennt jeder: Eine Aenderung besteht alle Tests in der Sandbox und scheitert auf dem Weg in die Produktion. Die Ursache ist fast nie die Aenderung. Die Sandbox war schlicht kein fairer Test mehr.

Woher kommt der Drift wirklich?

Fast alles davon stammt aus Aenderungen, die im Moment vernuenftig waren:

• Konfiguration direkt in der Produktion. Ein Picklist-Wert, freitags ergaenzt, weil ein Deal ihn brauchte. Richtige Entscheidung, unsichtbar fuer Ihr Repository.
• Hotfixes, die nie zurueckgemerged wurden. Der Fix ging live. Der Branch, auf dem er haette landen sollen, hat ihn nie bekommen.
• Pakete, die nur in einer Umgebung installiert wurden. Jemand installiert eine App in einer Sandbox zur Bewertung oder in der Produktion, um ein Team zu entsperren.
• Rechte per Ausnahme. Profile und Permission Sets driften in den meisten Orgs am schnellsten und liegen am seltensten in der Versionsverwaltung.
• Umgebungsspezifische Einstellungen, die nie gleich sein sollten. Endpunkte, Named Credentials, E-Mail-Zustellbarkeit, geplante Jobs. Das ist legitimer Drift, und er muss trotzdem deklariert werden: Wer legitimen nicht von unbeabsichtigtem Drift unterscheiden kann, ignoriert am Ende beides.
• Der Release-Kalender von Salesforce. Instanzen werden zu unterschiedlichen Zeiten aktualisiert, zwei Umgebungen koennen also eine Zeit lang wirklich auf verschiedenen Plattformversionen laufen.

Nichts davon ist Nachlaessigkeit. Es ist ein System, das Aenderungen durch mehr als eine Tuer hereinlaesst.

Warum loest der Quartals-Refresh das nicht?

Das Refresh-Ritual unterstellt, Drift lasse sich periodisch zuruecksetzen. Sehen Sie sich die Kadenz an, die Salesforce zulaesst: Developer- und Developer-Pro-Sandboxes lassen sich etwa taeglich aktualisieren, Partial Copy alle fuenf Tage und Full Sandboxes alle 29 Tage (siehe die Salesforce-Dokumentation zu Sandbox-Typen).

Die fuer realistisches Testen wichtigste Umgebung, die Full Sandbox, hat also eine harte Untergrenze von rund einem Monat. In der Praxis aktualisiert niemand mit maximaler Rate, denn ein Refresh loescht laufende Arbeit, verlangt Maskierung und erneutes Befuellen der Daten und kostet danach Tage an Einrichtung. Quartalsweise ist die ehrliche Zahl.

Drift entsteht derweil jeden Tag. Ein taegliches Problem loest man nicht mit einem Quartalsritual. Der Refresh ist nicht nutzlos, er setzt nur einen Zaehler zurueck, der sofort wieder steigt, und zwischen zwei Refreshes verfaellt Ihr Vertrauen in die Testumgebung fortlaufend, ohne dass es jemand misst.

Was kostet Drift wirklich?

• Fehlgeschlagene Deployments. Der sichtbare Posten, und der kleinste.
• Falsche Sicherheit. Weit schlimmer. Tests, die gegen eine gedriftete Sandbox laufen, sagen nichts, und Sie merken es erst in der Produktion.
• Laengere Schaetzungen. Teams bauen Puffer fuer Deployment-Ueberraschungen ein. Dieser Puffer ist eingepreister Drift.
• Rollbacks, die nicht vollstaendig zuruecksetzen. Enthaelt die Produktion Konfiguration, die Ihr Repo nie hatte, ist die Rueckkehr zum Repo keine Rueckkehr in einen bekannten Zustand.
• Audit-Risiko. "Was ist in der Produktion und wer hat es hineingebracht" sollte genau eine Antwort haben.

Wie sieht kontinuierliche Drift-Erkennung aus?

1. Erklaeren Sie eine Quelle der Wahrheit. Meist Git. Alles andere wird dagegen verglichen. Ohne diesen Schritt liefert Drift-Erkennung zwei Listen und kein Urteil.
2. Erstellen Sie geplante Snapshots jeder Umgebung. Taeglich schlaegt woechentlich. Der Wert liegt darin, eine Aenderung zu erwischen, solange die Person sich noch an das Warum erinnert.
3. Klassifizieren Sie den Unterschied, zeigen Sie ihn nicht nur. Drei Toepfe: erwartete Umgebungsunterschiede, akzeptierte Ausnahmen mit Eigentuemer und Ablaufdatum, und echter ungeplanter Drift.
4. Leiten Sie ihn sofort an einen Menschen. Ein Driftbericht ohne Verantwortliche ist ein Dashboard, keine Kontrolle.
5. Schliessen Sie den Kreis zum Repository. Legitime Produktionsaenderungen gehoeren in die Quelle uebernommen, nicht nur markiert. Sonst meldet jeder Zyklus ewig denselben Punkt.

Die meisten Werkzeuge dieser Kategorie koennen zwei Umgebungen vergleichen. Entscheidend ist, ob der Vergleich geplant laeuft, ohne dass jemand daran denken muss, ob die Ausgabe klassifiziert statt roh ist, und ob sie an derselben Pipeline haengt, die deployt.

Genau das ist der Entwurfsgedanke von Serpent: Drift-Erkennung steht neben Delta-Deployments, Ein-Klick-Rollback und einer KI-Code-Review, die Governance-Abweichungen bei jeder Aenderung markiert, und laeuft ueber Standard-APIs, ohne etwas in Ihrer Org zu installieren. Erkennung und Deployment an einem Ort heisst: Der Fix ist eine Aktion statt eines Tickets an ein anderes Team.

Was tun Sie diese Woche?

Nehmen Sie Ihre geschaeftskritischste Sandbox und vergleichen Sie sie einmal mit der Produktion. Sortieren Sie das Ergebnis in "erwartet", "davon wussten wir" und "wer war das". Ist der dritte Stapel der groesste, planen Sie keine Refreshes mehr, sondern Vergleiche.

FAQ

Was verursacht Salesforce-Org-Drift?

Aenderungen, die eine Org ausserhalb des Deployment-Prozesses erreichen: direkte Produktionskonfiguration, nicht zurueckgemergte Hotfixes, Pakete in einer Umgebung, Rechteaenderungen und legitime umgebungsspezifische Einstellungen, die nie als solche dokumentiert wurden.

Behebt ein Sandbox-Refresh den Drift?

Nur kurz. Full Sandboxes lassen sich bestenfalls alle 29 Tage aktualisieren, die meisten Teams schaffen ein Quartal, waehrend Drift taeglich waechst.

Wie oft sollte man auf Drift pruefen?

Taeglich fuer die Produktion und jede Umgebung, die der Release-Validierung dient. Langsamer verlieren Sie den Kontext, um zu erklaeren, was sich geaendert hat.

Ist jeder Drift schlecht?

Nein. Endpunkte, Credentials und geplante Jobs sollen sich unterscheiden. Das Problem ist nicht, dass es Unterschiede gibt, sondern dass undeklarierte Unterschiede von Fehlern nicht zu unterscheiden sind.