Commits enthalten in DevOpsChange-Anforderung
Die DevOpsArtefaktpaket 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 zu der 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 zurücksetzen: Commits, bei denen der Feldwert „Zurücksetzen“ als „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 mit dem Wert des Zusammenführungsfelds „wahr“.
- 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 neuesten allgemeinen Commit für die aktuelle Verzweigung und die zu fusionierende Verzweigung befinden. „Commit zusammenführen“ fügt dem Hauptzweig einen neuen Commit hinzu.
- Squash und Zusammenführung: Beim Squashen während einer Zusammenführung werden die Arbeitsstruktur und der Indexstatus generiert, um eine Zusammenführung abzugleichen, ohne dass ein Zusammenführungs-Commit erstellt wird. „Squash und Zusammenführen“ behält die Änderungen bei, entfernt jedoch die einzelnen Commits aus dem Verlauf. Hat einen einzelnen Commit mit dem Zusammenführungswert „wahr“.
Beispiel: Commits und Pakete
Dieses Beispiel besteht aus:
- Drei Pipelines erstellen (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: Berechnungslogik bestätigen
Anwendungsfall mit der Logik für die Berechnung von Commits, die Artefaktversionen zugeordnet werden. Die Verzweigungsinformationen werden immer dann einbezogen, wenn die 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.
- Commit-C1 beim Test erstellen, CI-Build ausführen, aber keine Artefaktversion erstellen.
- Erstellen Sie eine Commit-C2 auf dem Haupt, 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 wird fortgefahren:
- Erstellen Sie 1 Commit-C5 im Haupt, 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 wird fortgefahren:
Erstellen Sie ein Release mit Artefaktversion aus dem vorherigen Schritt, haben Sie eine CD-Pipeline mit dem Schritttyp = Prod.-Bereitstellung.
Erwartetes Ergebnis:
- Release ist derselben Artefaktversion (v2.0) zugeordnet.
- Die erstellte Change-Anforderung zeigt die Artefaktversion (v2.0) und Commits 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 in der Produktion bereitgestellt), werden in der Change-Anforderung angezeigt, aber nicht der Commit aus der Ausführung in der Testverzweigung.
- Die Anzahl der in der Change-Anforderung angezeigten Commits entspricht der Anzahl im Tool.
Mit dem Anwendungsfall wird fortgefahren:
- 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 dem 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, im vorherigen Paket in Prod bereitgestellt wurden.
- Es werden keine Commits aus der auf dem Test erstellten Artefaktversion angezeigt.
- Die Anzahl der in der Change-Anforderung angezeigten Commits entspricht der Anzahl im Tool.