Migrieren Sie den Verlauf der abgeschlossenen Update Sets in die Quellcodeverwaltung
Bei der Verknüpfung mit der Quellcodeverwaltung ermöglicht diese Funktion Anwendungsentwicklern die Möglichkeit, die Informationen in abgeschlossenen Update Sets in den Verlauf der Quellcodeverwaltung zu migrieren.
Vor der Migration
- Erforderliche Rolle: admin
- Lesen Sie das Thema Verknüpfen Sie eine Anwendung oder Anwendungsanpassung mit der Quellcodeverwaltung .
- Schließen Sie alle Update Sets für Ihre Anwendung ab, die Sie als Quellcodeverwaltungsverlauf exportieren möchten.
- Exportieren Sie das fertige Update Set, wenn Sie es beibehalten möchten.
- Wenn Sie „Ja, Update Set-Verlauf als Commits beibehalten“ auswählen, wird der Update Set-Verlauf als Quellcodeverwaltungs-Commits beibehalten.
- Wenn Sie „Nein, Update Set-Verlauf nicht als Commits beibehalten“ auswählen, werden sie nicht als Commits beibehalten.
Für jedes abgeschlossene Update Set 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 Sets generiert. Die Commits werden nach dem Zeitstempel sys_recorded_at sortiert. Für globale Anwendungen: Alle sys_update_xml- Datensätze, die zur Anwendung gehören und Teil eines abgeschlossenen globalen Update Sets sind, werden als historische Commits erfasst.
- Wenn Updates für eine Datei vorhanden sind, die zwischen verschiedenen Update Sets nicht in der Reihenfolge sind.
- Wenn ein Update Set mehrere Update-Datensätze für eine einzelne Datei enthält.
Die Commits für ein Update Set werden in mehrere Commits aufgeteilt ([Historischer Commit 1], [Historischer Commit 2]...), um jedes Update darzustellen. Dies geschieht, damit jede Datei einen geordneten Aktualisierungsverlauf hat.
Der Ordner „ author_selective_update “ wird erst beim ersten Commit erstellt. Das bedeutet, dass beim ersten Commit möglicherweise Dateien wie sys_choice- Dateien umbenannt und aus dem Update-Ordner in den Ordner „ author_selective_update “ verschoben werden. Alle Dateien, die aus Update Sets in historischen Commits gelöscht werden, werden gelöscht und nicht in den Ordner „ author_selective_update “ verschoben, wie dies bei tatsächlichen Commits der Fall wäre. Während des ersten Commit werden DELETE-Nutzlasten auch für alle DELETE-sys_update_xml-Datensätze erstellt, die als Teil abgeschlossener Update Sets 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 Set (siehe Abschnitt „ Batch-Update Sets “ weiter unten) }
Batch-Update Sets
Wenn ein Update Set Teil eines Batch-Update Sets ist, werden diese Informationen im folgenden Format an die Commit-Nachricht angehängt, wobei die höchste Nummer 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 die Eigenschaft glide.source_control.historical_commit_fields hinzufügen. Der Wert ist eine durch Kommas getrennte Liste von Feldern, die der Benutzer aus sys_update_set XML-Feldern aufnehmen möchte. Leerzeichen und ungültige oder falsch geschriebene Feldnamen werden ignoriert. Diese Eigenschaft wird für alle Anwendungen verwendet, die über die Instanz mit der Quellcodeverwaltung verknüpft sind, wenn der Committer den Update Set-Verlauf beibehalten möchte.