Commits enthalten in DevOps Change-Anforderung
Die DevOps Artefaktpaket und die zugehörigen Artefaktversionen werden verwendet, um zu bestimmen, welche Commits in enthalten sind DevOpsÄndern.
Commits werden basierend auf dem Change-Typ in einem Change enthalten.
| Änderungstyp | Commits enthalten |
|---|---|
| Manuell | Commits aus den Artefaktversionen des Pakets im Change. Darüber hinaus werden die Commits aus Aufgabenausführungen aller Pipeline-Ausführungen im Change-Referenzdatensatz eingeschlossen, wenn die Spalte „Data_type“ „Plan“ oder „Pipeline-Ausführung“ ist. |
| Automatisiert |
|
Alle Commits für Artefaktversionen im Paket, die nach dem letzten Bereitstellungsdatum generiert wurden (bis zur derzeit bereitgestellten Version), sind in der Change-Anforderung enthalten. Vorherige Hauptversionen sind nicht enthalten.
Hinweis:
Patch- und Hotfix-Versionen sind ausgeschlossen.
Wenn angegeben, wird die semantische Version verwendet, um Commits für einen Change zu bestimmen. Format ist (MAJOR.MINOR.PATCH). Beispiel: Semantische Version 2.0.1 wird wie folgt gelesen:
- Hauptversion 2
- Nebenversion 0
- Patch-/Hotfix-Version 1
Fehlgeschlagene Aufgabenausführungen zwischen den vorherigen und aktuellen Artefaktversionen, die kein Artefakt erstellt haben, aber über zugeordnete Commits verfügen, werden auch der erstellten Artefaktversion zugeordnet.
Typen von Commits
- Normale Commits: Commits im nachverfolgten Repository sind der Change-Anforderung zugeordnet.
- Commits rückgängig machen: Commits, bei denen der Feldwert „Zurücksetzen“ auf „wahr“ festgelegt ist. Ein Zurücksetzen des Commits führt zu einem zurückgesetzten Commit und einem Zurücksetzen des Commits in der Quellstruktur. Beide Commits sind der Change-Anforderung nicht zugeordnet.
- Commits zusammenführen: Commits, bei denen der Wert des Zusammenführungsfelds „wahr“ ist.
- Commit zusammenführen: Die Quellstruktur verfolgt den Commit für eine Verzweigung im Laufe der Zeit und ermöglicht die Durchführung eines speziellen Commits für die Zusammenführung. Dieser Zusammenführungs-Commit kombiniert die übergeordneten Commits, die sich direkt nach dem letzten allgemeinen Commit für die aktuelle Verzweigung und die zu fusionierende Verzweigung befinden. Commit zusammenführen fügt der Hauptverzweigung einen neuen Commit hinzu.
- Squash und Zusammenführung: Durch das Squashing während einer Zusammenführung werden die Arbeitsstruktur und der Indexstatus generiert, um eine Zusammenführung abzugleichen, ohne dass ein Commit für die Zusammenführung erstellt wird. Beim Kürzen und Zusammenführen werden die Änderungen beibehalten, die einzelnen Commits werden jedoch aus dem Verlauf entfernt. Sie hat einen einzelnen Commit mit mit dem Zusammenführungswert „wahr“.
Beispiel: Commits und Pakete
Dieses Beispiel besteht aus:
- Drei Build-Pipelines (A, B und C)
- Eine Release-Pipeline (ABC) unter Change-Steuerung mit vier Paketen:
- Pipeline A erstellen (Hauptversion 1)
- Pipelines A und B erstellen (Hauptversion 1)
- Pipelines B und C erstellen (Hauptversion 1)
- Pipelines A, B und C erstellen (Hauptversion 1)
| Commit | Pipeline erstellen | Semantische Version | Im Paket enthalten |
|---|---|---|---|
| 1 | A | 1.0.0 | X |
| 2 | A | 1.0.1 | -- |
| 3 | A | 1.1.0 | X |
Hinweis: Commit 2 (Build A, semantische Version 1,0.1) ist nicht im Paket enthalten, da die Syntax der semantischen Version auf einen Patch oder Hotfix hinweist. |
|||
| Commit | Pipeline erstellen | Semantische Version | Im Paket enthalten |
|---|---|---|---|
| 4 | A | 1.1.1 | -- |
| 5 | A | 1.2.0 | X |
| 6 | A | 1.2.0 | X |
| 7 | B | 1.0.0 | X |
| 8 | B | 1.0.0 | X |
| 9 | B | 1.1.0 | X |
| 10 | B | 1.1.0 | X |
Hinweis: Commit 4 (Build A, semantische Version 1,1.1) ist nicht enthalten, da die Syntax der semantischen Version auf einen Patch oder Hotfix hinweist. |
|||
| Commit | Pipeline erstellen | Semantische Version | Im Paket enthalten |
|---|---|---|---|
| 11 | A | 1.3.0 | -- |
| 12 | B | 1.2.0 | X |
| 13 | B | 1.2.0 | X |
| 14 | C | 1.0.0 | X |
| 15 | C | 1.0.0 | X |
| 16 | C | 1.0.0 | X |
Hinweis: Commit 11 (Build A, semantische Version 1,3.0) ist nicht enthalten, da das Paket Build A nicht angibt |
|||
| Commit | Pipeline erstellen | Semantische Version | Im Paket enthalten |
|---|---|---|---|
| 17 | A | 1.4.0 | X |
| 18 | A | 1.4.0 | X |
| 19 | B | 1.3.0 | X |
| 20 | B | 1.3.0 | X |
| 21 | C | 1.1.0 | X |
| 22 | C | 1.1.0 | X |
| 23 | C | 1.2.0 | X |
| 24 | C | 1.2.0 | X |
Hinweis: Commit 11 ist auch in diesem Paket enthalten, da es Teil der Änderungen in Hauptversion 1 von Build A ist, seit das letzte Paket (einschließlich Hauptversion 1 von Build A), Paket 2, in der Produktion bereitgestellt wurde. |
|||
Beispiel: Commit-Berechnungslogik
Anwendungsfall mit der Logik für die Berechnung von Commits, die Artefaktversionen zugeordnet werden. Die Verzweigungsinformationen werden immer dann einbezogen, wenn Commits definiert sind.
Betrachten Sie beispielsweise zwei Pipelines, eine in der Hauptverzweigung, eine in der Testverzweigung. Szenario ausführen:
- Commit-C0 auf Haupt erstellen, CI-Build ausführen, aber keine Artefaktversion erstellen.
- Erstellen Sie einen Commit C1 beim Test, führen Sie den CI-Build aus, aber erstellen Sie keine Artefaktversion.
- Erstellen Sie eine Commit-C2 im Hauptmodus, führen Sie den CI-Build aus, und der Build schlägt fehl.
- Erstellen Sie 2 Commits C3,C4 auf Haupt, führen Sie einen CI-Build aus, und erstellen Sie eine Artefaktversion (v1.0).
Mit dem Anwendungsfall fortfahren:
- Erstellen Sie 1 Commit C5 im Hauptmodus, führen Sie den CI-Build aus, aber erstellen Sie keine Artefaktversion.
- Erstellen Sie 1 Commit C6 im Hauptmodus, führen Sie den CI-Build aus, und erstellen Sie eine Artefaktversion (v2.0).
Zusammenfassung :
- Alle Commits aus Pipeline-Ausführungen (erfolgreich und fehlgeschlagen) in derselben Verzweigung zwischen der letzten Artefaktversion für ein bestimmtes Artefakt und der aktuellen Artefaktversion sind zugeordnet.
- Wenn keine vorherige Artefaktversion für das angegebene Artefakt gefunden wird, werden alle Commits aus Pipeline-Ausführungen in derselben Verzweigung zugeordnet.
Mit dem Anwendungsfall fortfahren:
Erstellen Sie ein Release mit Artefaktversion aus dem vorherigen Schritt, haben Sie eine CD-Pipeline mit Schritttyp = Prod-Bereitstellung.
Erwartetes Ergebnis:
- Release ist derselben Artefaktversion (v2.0) zugeordnet.
- „Erstellte Change-Anforderung“ zeigt Artefaktversion (v2.0) und Commits für C0, C2, C3, C4, C5 an C6.
Zusammenfassung :
- Commits aus beiden Artefaktversionen (v1.0, v2.0), die auf der Hauptverzweigung erstellt wurden (kein vorheriges Paket wurde für Prod bereitgestellt), werden in der Change-Anforderung angezeigt, aber nicht der Commit aus der Ausführung in der Testverzweigung.
- Die Anzahl der Commits, die in der Change-Anforderung angezeigt werden, entspricht der Anzahl im Tool.
Mit dem Anwendungsfall fortfahren:
- Erstellen Sie 2 Commits C7 und C8 in der Testverzweigung, führen Sie den CI-Build aus, und erstellen Sie eine Artefaktversion.
Erwartetes Ergebnis: Artefaktversion (v3.0) ist C1, C7, C8 zugeordnet.
- Erstellen Sie 2 Commits C9 und C10 in der Hauptverzweigung, führen Sie den CI-Build aus, und erstellen Sie eine Artefaktversion.
Erwartetes Ergebnis: Artefaktversion (v4.0) ist C9, C10 zugeordnet.
- Erstellen Sie ein Release mit Artefaktversion aus dem vorherigen Schritt (v4.0), haben Sie eine CD-Pipeline mit Schritttyp = Prod-Bereitstellung.Erwartetes Ergebnis:
- Release ist Artefaktversion (v4.0) zugeordnet.
- „Erstellte Change-Anforderung“ zeigt Artefaktversion (v4.0) und Commits C9, C10 an.
Zusammenfassung :
- Die Change-Anforderung zeigt Commits nur aus der neuesten Artefaktversion an, die auf der Hauptverzweigung erstellt wurde, da Commits aus vorherigen Artefaktversionen, die auf der Hauptversion erstellt wurden, auf Prod im vorherigen Paket bereitgestellt wurden.
- Es werden keine Commits aus der Artefaktversion angezeigt, die auf dem Test erstellt wurde.
- Die Anzahl der Commits, die in der Change-Anforderung angezeigt werden, entspricht der Anzahl im Tool.