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

Kurze Antwort: Org-Drift ist der aufsummierte Preis jeder Änderung, 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 vierteljährliche Sandbox-Aktualisierung, auf die die meisten Teams setzen, kann ihn nicht beheben, denn Refreshes laufen bestenfalls monatlich, während Drift täglich entsteht.

Was ist Org-Drift?

Org-Drift ist die Abweichung zwischen dem, was eine Umgebung enthält, 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 Änderung besteht alle Tests in der Sandbox und scheitert auf dem Weg in die Produktion. Die Ursache ist fast nie die Änderung. Die Sandbox war schlicht kein fairer Test mehr.

Woher kommt der Drift wirklich?

Fast alles davon stammt aus Änderungen, die im Moment vernünftig waren:

• Konfiguration direkt in der Produktion. Ein Picklist-Wert, freitags ergänzt, weil ein Deal ihn brauchte. Richtige Entscheidung, unsichtbar für Ihr Repository.
• Hotfixes, die nie zurückgemerged wurden. Der Fix ging live. Der Branch, auf dem er hätte 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 können also eine Zeit lang wirklich auf verschiedenen Plattformversionen laufen.

Nichts davon ist Nachlässigkeit. Es ist ein System, das Änderungen durch mehr als eine Tür hereinlässt.

Warum löst der Quartals-Refresh das nicht?

Das Refresh-Ritual unterstellt, Drift lasse sich periodisch zurücksetzen. Sehen Sie sich die Kadenz an, die Salesforce zulässt: Developer- und Developer-Pro-Sandboxes lassen sich etwa täglich aktualisieren, Partial Copy alle fünf Tage und Full Sandboxes alle 29 Tage (siehe die Salesforce-Dokumentation zu Sandbox-Typen).

Die für 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 löscht laufende Arbeit, verlangt Maskierung und erneutes Befüllen der Daten und kostet danach Tage an Einrichtung. Quartalsweise ist die ehrliche Zahl.

Drift entsteht derweil jeden Tag. Ein tägliches Problem löst man nicht mit einem Quartalsritual. Der Refresh ist nicht nutzlos, er setzt nur einen Zähler zurück, der sofort wieder steigt, und zwischen zwei Refreshes verfällt 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.
• Längere Schätzungen. Teams bauen Puffer für Deployment-Überraschungen ein. Dieser Puffer ist eingepreister Drift.
• Rollbacks, die nicht vollständig zurücksetzen. Enthält die Produktion Konfiguration, die Ihr Repo nie hatte, ist die Rückkehr zum Repo keine Rückkehr 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. Erklären 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. Täglich schlägt wöchentlich. Der Wert liegt darin, eine Änderung zu erwischen, solange die Person sich noch an das Warum erinnert.
3. Klassifizieren Sie den Unterschied, zeigen Sie ihn nicht nur. Drei Töpfe: erwartete Umgebungsunterschiede, akzeptierte Ausnahmen mit Eigentümer und Ablaufdatum, und echter ungeplanter Drift.
4. Leiten Sie ihn sofort an einen Menschen. Ein Driftbericht ohne Verantwortliche ist ein Dashboard, keine Kontrolle.
5. Schließen Sie den Kreis zum Repository. Legitime Produktionsänderungen gehören in die Quelle übernommen, nicht nur markiert. Sonst meldet jeder Zyklus ewig denselben Punkt.

Die meisten Werkzeuge dieser Kategorie können zwei Umgebungen vergleichen. Entscheidend ist, ob der Vergleich geplant läuft, ohne dass jemand daran denken muss, ob die Ausgabe klassifiziert statt roh ist, und ob sie an derselben Pipeline hängt, 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 Änderung markiert, und läuft über Standard-APIs, ohne etwas in Ihrer Org zu installieren. Erkennung und Deployment an einem Ort heißt: Der Fix ist eine Aktion statt eines Tickets an ein anderes Team.

Was tun Sie diese Woche?

Nehmen Sie Ihre geschäftskritischste 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 größte, planen Sie keine Refreshes mehr, sondern Vergleiche.

FAQ

Was verursacht Salesforce-Org-Drift?

Änderungen, die eine Org außerhalb des Deployment-Prozesses erreichen: direkte Produktionskonfiguration, nicht zurückgemergte Hotfixes, Pakete in einer Umgebung, Rechteänderungen 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, während Drift täglich wächst.

Wie oft sollte man auf Drift prüfen?

Täglich für die Produktion und jede Umgebung, die der Release-Validierung dient. Langsamer verlieren Sie den Kontext, um zu erklären, was sich geändert 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.