Pre-Refresh-Risikoscanner
Verwenden Sie dieses Tool, wenn eine Sandbox-Aktualisierung ansteht und jemand wissen muss, was verloren geht. Der Scan ist nur lesend. Die Beurteilung liegt in den Fragen, der Überprüfung und der Notiz, die hinausgeht.
Schritt 1: Fragen vor dem Handeln
Stellen Sie diese Fragen in einer einzigen Nachricht und warten Sie auf die Antworten. Führen Sie den Scan nicht zuerst aus.
- Welche Org, und wie lautet ihr CLI-Alias? Bestätigen Sie, dass es sich um eine Sandbox handelt, nicht um Production. Production wird von diesem Skill niemals gescannt.
- Wann ist die Aktualisierung, und welcher Typ (Full, Partial, Developer Pro, Developer)? Full und Partial ersetzen Daten. Developer und Developer Pro behalten keine.
- Gibt es ein Source-Control-Projekt für diese Org? Wenn ja, wo liegt es auf der Festplatte? Der Scan kann die Org damit vergleichen.
- Wer besitzt die Integrationen? Die Checkliste weist Verantwortliche zu, daher helfen Namen (nur interne Personen).
- Gibt es in dieser Sandbox etwas, das bekanntermaßen nirgendwo anders existiert? Testdaten, die jemand manuell aufgebaut hat, ein Feature-Switch, eine Demo-Konfiguration.
Schritt 2: Den Scan ausführen
node scan.js --org <alias> --out ./out [--project <pfad zu sfdx-projekt>] [--days 90]
Das Skript schreibt out/refresh-risk-checklist.md und out/refresh-risk.json. Wenn eine Prüfung fehlschlägt (eine Berechtigung, die dem aktuellen Benutzer fehlt, ein Objekt, das die Org nicht hat), wird dies in der Checkliste vermerkt und das Skript fährt fort. Nicht mit mehr Berechtigungen wiederholen, ohne vorher zu fragen.
Schritt 3: Überprüfen, nicht einfach weiterleiten
Lesen Sie die Checkliste und wenden Sie Ihr Urteilsvermögen an, das das Skript nicht hat:
- Welche Elemente liegen außerhalb unseres Rahmens, sind aber dennoch gefährdet? Melden Sie sie trotzdem. Der Kunde hört es lieber zweimal als gar nicht.
- Welche Elemente sind Rauschen? Eine Connected App, die niemand nutzt, kann absichtlich fallen gelassen werden. Sagen Sie das, anstatt sie als Arbeit aufzulisten.
- Welche Elemente werden stillschweigend unterbrochen? Integrationsbenutzer und OAuth-Token gehören ganz oben in die Notiz.
- Gibt es ein Post-Copy-Skript? Falls nicht, empfehlen Sie eines. Es verwandelt den Großteil dieser Liste in Code.
Bearbeiten Sie die Checkliste: Streichen Sie Rauschen, fügen Sie Verantwortliche hinzu, fügen Sie alles hinzu, was aus den Antworten von Schritt 1 hervorgegangen ist.
Schritt 4: Die Notiz entwerfen
Schreiben Sie die Kundennotiz in einfachen Worten, eine Bildschirmlänge:
- Das Aktualisierungsdatum und der Typ, in der ersten Zeile.
- Was verloren geht oder zurückgesetzt wird, gruppiert: Daten, Anmeldeinformationen und Integrationen, geplante Jobs, Sandbox-spezifische Konfiguration.
- Was wir von ihnen brauchen, mit einem Datum: Verantwortliche für die Elemente außerhalb unseres Rahmens, Bestätigung für alles, was wir zu löschen planen.
- Was wir tun werden, mit einem Datum: Exports vorher, Neueingabe und Neuplanung nachher, ein Smoke-Test am ersten Tag.
Hängen Sie die Checkliste an. Senden Sie nichts, ohne dass der Engagement-Lead es zuerst gelesen hat.
Regeln
- Nur lesend. Das Skript fragt nur ab und listet auf. Niemals einen Schreibzugriff hinzufügen.
- Nur Sandboxes. Wenn der Alias auf Production verweist, stoppen und dies sagen.
- Niemals Geheimnisse in die Checkliste einfügen. Benannte Berechtigungsnamen, ja. Werte, niemals.
- Keine Kundennamen in etwas, das den Engagement-Ordner verlässt.