Migrieren Sie den Verlauf von abgeschlossenen Update-Sätzen zur Quellcodeverwaltung
Bei Verknüpfung mit der Quellcodeverwaltung können Anwendungsentwickler mit dieser Funktion die Informationen in abgeschlossenen Update Sets in den Verlauf der Quellcodeverwaltung 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 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 Commits der Quellcodeverwaltung 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 dem Zeitstempel „sys_recorded_at“ sortiert. Für globale Anwendungen: Alle sys_update_xml- Datensätze, die zu der Anwendung gehören und Teil eines abgeschlossenen globalen Update Set sind, werden als historische Commits erfasst.
- Wenn Updates für eine Datei vorhanden sind, die zwischen verschiedenen Update-Sätzen in der falschen Reihenfolge sind.
- Ob ein Update Set mehrere Update-Datensätze für eine einzelne Datei enthält.
Die Commits für einen Update-Satz werden in mehrere Commits ([Historischer Commit 1], [Historischer Commit 2]...) aufgeteilt, um jedes Update darzustellen. Dadurch wird sichergestellt, dass jede Datei einen geordneten Verlauf von Aktualisierungen hat.
Der Ordner „ author_selective_update “ wird erst beim ersten Commit erstellt. Das bedeutet, dass Sie beim ersten Commit möglicherweise Dateien wie „sys_choice“ -Dateien sehen, die umbenannt und aus dem Ordner „update“ in den Ordner „ author_selective_update “ verschoben werden. Alle Dateien, die aus Update-Sätzen in historischen Commits gelöscht werden, werden gelöscht und nicht in den Ordner „ author_elective_update “ verschoben, wie dies bei tatsächlichen Commits der Fall wäre. Während des ersten Commits werden DELETE-Nutzlasten auch für alle DELETE 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 zu Batch- Update-Sätzen (siehe Abschnitt „Batch -Update-Sätze“ weiter unten) }
Update Sets als Batch verwenden
Wenn ein Update Set Teil eines Batch Update Set ist, werden diese Informationen im folgenden Format an die Commit-Nachricht angehängt, wobei die höchste Zahl die Batch Base 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 der Commit-Nachricht enthalten sind, indem Sie die Eigenschaft „glide.source_control.historical_commit_fields“ hinzufügen. Der Wert ist eine durch Kommas getrennte Liste von Feldern, die der Anwender aus den XML-Feldern „sys_update_set“ aufnehmen möchte. Leerzeichen und ungültige oder falsch geschriebene Feldnamen werden ignoriert. Diese Eigenschaft wird für alle Anwendungen verwendet, die von der Instanz aus mit der Quellcodeverwaltung verknüpft sind, wenn der Committter die Beibehaltung des Update-Satz-Verlaufs auswählt.