Veraltet – Verlauf des abgeschlossenen Update-Satzes zur Quellcodeverwaltung migrieren
Beim Verknüpfen mit der Quellcodeverwaltung ermöglicht diese Funktion Anwendungsentwicklern die Möglichkeit, die Informationen in abgeschlossenen Update-Sätzen in den Quellcodeverwaltungsverlauf zu migrieren.
Versuchen Sie, Apps in der aktuellen Version von zu erstellen und zu bearbeiten ServiceNow StudioStattdessen. Weitere Informationen finden Sie unter ServiceNow Studio.
Vor der Migration
- Erforderliche Rolle: Administrator
- Lesen Sie Veraltet – Verknüpfen Sie eine Anwendung oder eine Anwendungsanpassung mit der QuellcodeverwaltungThema
- Schließen Sie alle Update-Sätze für Ihre Anwendung ab, die Sie als Quellsteuerungsverlauf exportieren möchten.
- Exportieren Sie den abgeschlossenen Update-Satz, wenn Sie ihn beibehalten möchten.
- Wenn Sie „Ja, Update-Satz-Verlauf als Commits beibehalten“ auswählen, wird der Update-Satz-Verlauf als Quellsteuerungs-Commits beibehalten.
- Wenn Sie „Nein, Update-Satz-Verlauf nicht als Commits beibehalten“ auswählen, werden sie nicht als Commits beibehalten.
Für jeden abgeschlossenen Update-Satz mit Updates für die Anwendung, die Sie mit der Quellcodeverwaltung verknüpfen, werden Commits automatisch vom System basierend auf den sys_Update_xml-Datensätzen in den Update-Sätzen generiert. Die Commits werden nach sortiert sys_recorded_at Zeitstempel. Für globale Anwendungen: Beliebig sys_Update_xml Datensätze, die zur Anwendung gehören und Teil eines abgeschlossenen globalen Update-Satzes sind, werden als historische Commits erfasst.
- Wenn Updates für eine Datei vorhanden sind, die zwischen verschiedenen Update-Sätzen nicht in Ordnung sind.
- Wenn ein Update-Satz mehrere Update-Datensätze für eine einzelne Datei enthält.
Die Commits für einen Update-Satz sind in mehrere Commits aufgeteilt ([historischer Commit 1], [historischer Commit 2]...) Um jedes Update darzustellen. Dies geschieht, damit jede Datei einen geordneten Verlauf von Updates hat.
Die Author_elective_Update Ordner wird erst beim ersten Commit erstellt. Das bedeutet, dass beim ersten Commit Dateien wie angezeigt werden sys_choice Dateien, die umbenannt und aus dem Update-Ordner in verschoben werden Author_elective_Update Ordner. Alle Dateien, die aus Update-Sätzen in historischen Commits gelöscht werden, werden gelöscht und nicht in verschoben Author_elective_Update Ordner wie für tatsächliche Commits. Während des ersten Commits werden LÖSCHNUTZLASTEN auch für alle GELÖSCHTEN sys_Update_xml-Datensätze erstellt, die als Teil abgeschlossener Update-Sätze gelöscht wurden.
[Historical Commit 1] <Name of update set that this commit belongs to>
Description: <Description of update set that this commit belongs to>
Update Set was completed on / installed on <date>
Update Set was completed by <sys_user user_name > <sys_user email>
{}
{Informationen zum Batch-Update-Satz: Siehe Batch-Update-Sätze Abschnitt unten.
Batch-Update-Sätze
Wenn ein Update-Satz Teil eines Batch-Update-Satzes ist, werden diese Informationen im folgenden Format an die Commit-Nachricht angehängt, wobei die höchste Zahl die Batch-Basis ist:
{
"1": {
"parent": "<name of parent update set>",
"description": "<description of parent update set>"
},
"2": {
"parent": " <name of parent 1’s parent update set> ",
"description": " <description of parent 1’s parent update set> "
}
}
Anpassung
Sie können zusätzliche Felder hinzufügen, die in die Commit-Nachricht aufgenommen werden sollen, indem Sie hinzufügen Glide.Source_Control.history_commit_fields Eigenschaft. Der Wert ist eine kommagetrennte Liste von Feldern, die der Anwender aus sys_Update_Set-XML-Feldern einschließen möchte. Leerzeichen und ungültige oder falsch geschriebene Feldnamen werden ignoriert. Diese Eigenschaft wird für alle Anwendungen verwendet, die von der Instanz mit der Quellcodeverwaltung verknüpft sind, wenn der Committer den Update-Satz-Verlauf beibehalten möchte.