Vor der Migration

Wenn Sie eine Anwendung mit der Quellcodeverwaltung verknüpfen, werden die Update Sets und Kunden-Update-Datensätze gelöscht. Nachdem Sie eine Verknüpfung mit der Quellcodeverwaltung hergestellt haben und die Anwendung über abgeschlossene Update Sets verfügt, werden Sie im folgenden Dialogfeld aufgefordert, eine Auswahl zu treffen.

• 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.

Unabhängig davon, welche Option Sie auswählen, wird bei Auswahl von Fortfahrender Vorgang Verknüpfung mit Quellcodeverwaltung gestartet, und alle abgeschlossenen Update Sets und alle Kunden-Update-Datensätze werden gelöscht. Wenn Sie zusätzliche Update Sets abschließen müssen oder nicht fortfahren möchten, wählen Sie Abbrechen.

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.

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.