Allgemeine Richtlinien und Anwendungsfälle für Entwickler-Sandboxes
Befolgen Sie einige allgemeine Richtlinien, um sicherzustellen, dass Sie Ihre Verwendung von Sandboxen optimieren.
Anzahl von Entwickler-SandboxesAnwender
In jeder Sandbox darf nur eine Person arbeiten. Mehrere Anwender pro Sandbox würden die Vorteile der parallelen Entwicklung negieren.
Timing für Entwickler-Sandboxes
Verwenden Entwickler-SandboxesDient zum Erstellen absichtlich transienter Umgebungen. Je länger sie halten, desto weiter kommen sie von der ursprünglichen Basisinstanz. Daher Entwickler-SandboxesSollte so kurzlebig wie möglich sein.
- Ein Sprint
- Eine Story
- Eine Testrunde
Beispiele für Sandbox-Zuteilung
- Erstellen Sie Verzweigungen zu Beginn eines Sprints.
- Für jede Sandbox muss eine neue Verzweigung erstellt werden.
- Wenn Sie einen Fehler in der Mitte eines Sprints beheben müssen, erstellen Sie anstelle von Änderungen eine zweite Sandbox mit einer neuen Verzweigung, und beheben Sie den Fehler dort. Führen Sie diese Änderungen dann in der Release-Verzweigung zusammen, und stellen Sie die Fehlerkorrektur in der Produktion bereit.
- Erstellen Sie eine Sandbox, um eine Story oder Funktion zu testen, indem Sie die Änderungen an einer neuen Sandbox abrufen, die Sie nach Abschluss des Tests stilllegen.
Entwickler-Sandboxes Im Vergleich zu nicht-Produktionsinstanzen
Entwickler-SandboxesSind kein Ersatz für nicht-Produktionsinstanzen. Entwickler-SandboxesSind als temporär vorgesehen, während nicht-Produktionsinstanzen dauerhafter sind und langfristig verwendet werden können.
| Nicht-Produktionsinstanzen | Entwickler-Sandboxes |
|---|---|
| Partitionieren Sie die Arbeit Ihres Unternehmens nach Team oder Projekt | Isolieren Sie Entwicklermetadatenänderungen in einem Projekt. |
| Gruppen beginnen mit erheblich unterschiedlichen Konfigurationen | Alle Entwickler beginnen mit derselben Baseline-Instanzkonfiguration. |
| Gleichzeitige Workstreams sind isoliert oder minimal ausgerichtet | Entwicklungsaktivitäten folgen einer konsistenten Kadenz. |
| Dauerhafte Umgebung für langfristige Changes | Die Arbeit kann in einer temporären Umgebung abgeschlossen und der Versionskontrolle übergeben werden. |
Entwickler-Sandboxes und ServiceNow Fluent
Entwickler-SandboxesArbeiten Sie am besten mit ServiceNow FluentUnd ServiceNow IDE.
Low-Code-Changes, die in XML-Markup dargestellt werden, verursachen manchmal Zusammenführungsprobleme, da die generierte Dateistruktur die Ausrichtung von Changes schwierig machen kann. Bei Verwendung von Low-Code-Buildern auf ServiceNow AI Platform, Die beste langfristige Strategie besteht darin, Änderungen in zu speichern ServiceNow FluentAnstelle von XML.
ServiceNow Fluent Ist eine domänenspezifische Programmiersprache, mit der Sie Anwendungsmetadaten im Quellcode definieren können. Entwickler und Administratoren können problemlos nach Änderungen in der Versionssteuerung suchen, z. B. Git. Details finden Sie unter ServiceNow Fluent.
Sie können verwenden Entwickler-SandboxesMit Systemupdate-Sätze, Aber eine zukunftsweisende Lösung ist zu verwenden ServiceNow IDE. Ihre Sandboxen und werden gekoppelt ServiceNow IDEMit Versionssteuerung und Bereitstellungs-Apps (z. B. App Engine Management Center) Ermöglicht ein bereinigtes, optimiertes Bereitstellungs-Ökosystem. Weitere Informationen finden Sie unter ServiceNow IDE.
Entwickler-Sandboxes Häufig gestellte Fragen
Siehe ServiceNow Communityartikel auf Entwickler-Sandboxen: Häufig gestellte Fragen und Leitfaden für erste Schritte .