Stellen Sie Ihre App bereit

Sobald die Anwendung erstellt und validiert wurde, muss die Anwendung in die Produktionsumgebung verschoben werden. Anwendungen können über ein Anwendungs-Repository oder mithilfe von Update Sets verschoben werden. Anwendungen sollten vor dem Übergang in die Produktion in Testumgebungen bereitgestellt werden.

Anwendungs-Repository (App Repo)

Durch die Veröffentlichung einer Anwendung im App-Repository wird diese Version der Anwendung für alle ServiceNow-Instanzen einer Organisation verfügbar gemacht. Verwenden Sie das App-Repository, um eine Anwendung in QA-/Testinstanzen (zu Testzwecken) und schließlich in Produktionsinstanzen (Prod) bereitzustellen.

Weitere Informationen finden Sie unter Anwendungen im Anwendungs-Repositoryveröffentlichen, Anwendungen installieren.

Update-Sätze

Wenn das Anwendungs-Repository nicht zum Bereitstellen von Anwendungen verwendet werden kann, verwenden Sie stattdessen Update Sets. Das Diagramm zeigt den Best Practice-Lebenszyklus eines Update Sets zur Bereitstellung einer Anpassung von der Entwicklungsinstanz bis zur Testinstanz.

Vorgehensweisen, die zu einem qualitativ hochwertigen Entwicklungs- und Releaseprozess führen:

• Verschieben Sie Anpassungen immer vom unteren Rand des Stapels nach oben.
  • Stellt sicher, dass Down-Stack-Instanzen mit Up-Stack-Instanzen übereinstimmen.
  • Während des Stapels eingeführte Anpassungen können durch zukünftige Veröffentlichungen aus dem Nachstapel überschrieben werden.
  • Häufige Szenarien:
    • Behebt Bedarf in Test oder Produktion – veröffentlichen Sie sie immer von „Entw“ nach oben
    • Gängige Prod-Administratoranpassungen, z. B. Auswahllisten – Updates immer von „Entw“ aufwärts veröffentlichen
• Überprüfen Sie vor der Übertragung immer die in einem Update Set enthaltenen Updates.
  • Suchen Sie nach Updates, die anderen Entwicklungsbemühungen zugeordnet sind, und Updates, die Tests zugeordnet sind.
  • Achten Sie auf Änderungen an Systemeigenschaften und Integrationsendpunkten. Beispiel: sys_properties-Änderung wird übertragen, die alle E-Mails an den Test-E-Mail-Account leitet
  • Verschieben Sie Updates in ein „verschrottetes“ Update Set, anstatt das Update zu löschen.
• Testen Sie nach der Veröffentlichung immer, um sicherzustellen, dass alle gewünschten Anpassungen erfasst und wie erwartet angewendet werden.
• Stellen Sie in Situationen mit mehreren parallelen Releases die Kommunikation und Koordination zwischen den Entwicklungsteams sicher.
• Vermeiden Sie es, mit der Entwicklungsinstanz zu experimentieren, da Anpassungen versehentlich erfasst und von anderen Teammitgliedern migriert werden können.
• Erfassen Sie die Entwicklung nicht im Standard-Update Set.

Listet alle Benutzer-Story-Nummern mit einer Kurzbeschreibung im Feld Beschreibung eines Update Sets auf. Schließen Sie alle manuellen Schritte ein, die zum Bereitstellen des Update Sets erforderlich sind.

Einige typische Beispiele für manuelle Schritte, die für eine Bereitstellung erforderlich sind und nicht in einem Update Set erfasst werden:

• Plugin-Aktivierung.
• Übertragung von Tabellen, die nicht im Update Set nachverfolgt werden (normalerweise beginnend mit „x_“ oder „u_“).
• Erstellung von Datenbankindizes für die Tabellen. Die Indexerstellung wird nicht über Update Set nachverfolgt und muss manuell erfolgen.

Update Set-Verwaltung

Stellen Sie sicher, dass das richtige Update Set ausgewählt ist, wenn Sie an einer Story oder einem Fehler arbeiten, und überprüfen Sie die Datensätze im Update Set täglich.

Verschieben Sie sys_update_xml- Datensätze nicht manuell zwischen Update Sets. Die einzige Ausnahme ist das Verschieben eines Datensatzes in das Standard-Update Set.

Update Sets erfassen Konfigurationsinformationen, jedoch keine Aufgaben- oder Prozessdaten. Zum Beispiel verfolgen Update Sets Servicekatalog-Elementdefinitionen und zugehörige Konfigurationsdaten wie Variablen und Variablenauswahlmöglichkeiten. Die in Tests erteilten Bestellungen (Anforderungen, Elemente, Katalogaufgaben) werden jedoch nicht von Update Sets nachverfolgt.

Beachten Sie die DOs und DON'Ts für Update Sets:

• Um einen bestimmten sys_update_xml -Datensatz aus dem aktuellen Update Set zu entfernen, verschieben Sie den Datensatz in das Standard-Update Set, und füllen Sie das Feld sys_update_set.comments des Datensatzes mit dem Grund für das Verschieben des Datensatzes in das Standard-Update Set aus.
• Verschieben Sie Anpassungsdatensätze niemals von einem Update Set in ein anderes Update Set.
• Löschen Sie niemals ein Update Set, es sei denn, das Update Set wurde erfolgreich mit einem neuen Update Set zusammengeführt.
• Verwenden Sie immer Datenextrakte oder Import Sets, um Daten von einer Instanz in eine andere zu verschieben (und keine Update Sets).

Stapelung von Update Sets

Batch-Update Sets, um eine Massenvorschau und einen Commit für Update Sets durchzuführen.

Der Umgang mit mehreren Update Sets kann zu Problemen führen, einschließlich der Übergabe von Update Sets in der falschen Reihenfolge oder des versehentlichen Auslassens eines oder mehrerer Sets. Vermeiden Sie diese Probleme, indem Sie abgeschlossene Update Sets in einem Batch gruppieren.

Das System organisiert Update Set-Batches in einer Hierarchie. Ein Update Set kann als übergeordnetes Element für mehrere untergeordnete Update Sets fungieren. Ein gegebenes Set kann sowohl ein untergeordnetes als auch ein übergeordnetes Element sein und Hierarchien auf mehreren Ebenen ermöglichen. Ein Update Set auf der obersten Ebene der Hierarchie fungiert als Basis-Update Set.

Wenn Sie eine Vorschau oder einen Commit für das Basis-Update Set anzeigen, wird der gesamte Batch in der Vorschau angezeigt oder festgelegt. Das System bestimmt die Verarbeitungsreihenfolge und prüft auf Kollisionen basierend auf den Daten, an denen die Änderungen aufgezeichnet wurden, und auf ihrer sequenziellen Abstammung. Ihre Vorfahren sind die spezifischen Instanzen, in denen die Änderungen in den Update Sets stattgefunden haben.

Die Stapelung von Update Sets kann auf Releases angewendet werden, bei denen ein leeres übergeordnetes Update Set für das Release erstellt wird und tatsächliche Update Sets als untergeordnete Elemente in das Release aufgenommen werden.

Vorteile der Stapelung von Update Sets:

• Einzelne Update Sets können im letzten Moment aus dem Release entfernt werden.
• Batching ähnelt dem Zusammenführen, außer dass Updates entfernt werden können.
• Batch-Update Sets sind einfach bereitzustellen. Nur das übergeordnete Update Set muss verarbeitet werden.

Weitere Informationen finden Sie unter System-Update Sets.

Nächste Schritte

Nachdem die App bereitgestellt wurde, überlegen Sie, wie Sie sie verbessern und erweitern können. Hier sind einige Vorschläge, um zu bestimmen, wo es als Nächstes hingehen soll:

• Die Personen, die die Anwendung täglich verwenden, sind die beste Quelle für Feedback. Sprechen Sie mit ihnen darüber, welche neuen Funktionen oder Änderungen sie sehen möchten.
• Bestimmen Sie, ob zusätzliche zugehörige Prozess-Flows über Flow Designer automatisiert werden können.
• Bestimmen Sie, ob neue IntegrationHub-Speichen für neue Integrationen genutzt werden können.