Commits sind in der Change-Anforderung DevOps enthalten

  • Freigeben Version: Yokohama
  • Aktualisiert 30. Januar 2025
  • 6 Minuten Lesedauer

    • Das Artefaktpaket DevOps und die zugehörigen Artefaktversionen werden verwendet, um zu bestimmen, welche Commits in einem Change DevOps enthalten sind.

    Commits sind je nach Change-Typ in einem Change enthalten.
    Änderungstyp Commits enthalten
    Manuell Commits von den Artefaktversionen des Pakets im Change. Darüber hinaus sind die Commits aus Aufgabenausführungen aller Pipelineausführungen im Change-Referenzdatensatz enthalten, wenn die Spalte „data_type“ auf „plan“ oder „pipelineausführung“ festgelegt ist.
    Automatisiert
    • Ohne Paket: Alle Commits aus den Artefaktversionen sind enthalten. Die Artefaktversionen sind diejenigen, die mit der Pipeline-Ausführung und den Aufgabenausführungen für diese Pipeline-Ausführung verknüpft sind.
    • Mit Paket: Wenn eine der vorgelagerten Aufgabenausführungen des Change den Schritt „Prod-Bereitstellung“ enthält, werden Commits aus der letzten erfolgreichen Ausführung der Pipeline für die Prod-Bereitstellung eingeschlossen. Commits, die in mehreren Pipelineausführungen auftreten, werden nur einmal aufgelistet. Wenn der Schritt „Prod-Bereitstellung“ in den Ausführungen der vorangegangenen Aufgaben nicht vorhanden ist, sind die Commits aus allen Artefaktversionen des Pakets enthalten.
    • Commits ausführen: Wenn es keine Commits von mit oder ohne Paket-Flow gibt, wie zuvor angegeben, werden die Commits der vorgelagerten Aufgabenausführungen der Change-Anforderung zugeordnet.
    Alle Commits für Artefaktversionen im Paket, die nach dem letzten Bereitstellungsdatum generiert wurden (bis zur aktuell 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). Zum Beispiel wird die semantische Version 2.0.1 wie folgt gelesen:
    • Hauptversion 2
    • Nebenversion 0
    • Patch/Hotfix-Version 1

    Fehlgeschlagene Aufgabenausführungen zwischen der vorherigen und der aktuellen Artefaktversion, die kein Artefakt erstellt haben, denen aber Commits zugeordnet sind, werden ebenfalls der erstellten Artefaktversion zugeordnet.

    Arten von Commits

    • Normale Commits: Commits im nachverfolgten Repository sind der Change-Anforderung zugeordnet.
    • Commits rückgängig machen: Commits, bei denen der Feldwert „wahr“ festgelegt ist. Ein rückgängig gemachtes Commit führt zu einem rückgängig gemachten Commit und einem rückgängig gemachten Commit in der Quellstruktur. Beide Commits sind nicht mit der Change-Anforderung verknüpft.
    • Commits zusammenführen: Commits, bei denen der Zusammenführungsfeldwert als „wahr“ festgelegt ist.
      • Commit zusammenführen: Die Quellstruktur verfolgt den Commit für eine Verzweigung im Laufe der Zeit und ermöglicht das Durchführen eines speziellen Commits. Dieser Zusammenführungs-Commit kombiniert die übergeordneten Commits, die sich direkt nach dem letzten allgemeinen Commit in der aktuellen Verzweigung und in der zusammenzuführenden Verzweigung befinden. Beim Zusammenführen von Commit wird ein neuer Commit in der Hauptverzweigung hinzugefügt.
      • Zerkleinern und zusammenführen: Durch das Zerdrücken während einer Zusammenführung werden die Arbeitsstruktur und der Indexstatus so generiert, dass sie einer Zusammenführung entsprechen, ohne ein Zusammenführungs-Commit zu erstellen. 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 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-Kontrolle, mit vier Paketen:
      1. Pipeline A erstellen (Hauptversion 1)
      2. Pipelines A und B erstellen (Hauptversion 1)
      3. Pipelines B und C erstellen (Hauptversion 1)
      4. Pipelines A, B und C erstellen (Hauptversion 1)
    Tabelle : 1. Paket 1 (A 1.1.0)
    Commit Erstellen Sie eine Pipeline 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.
    Tabelle : 2. Paket 2 (A 1.2.0, B 1.1.0)
    Commit Erstellen Sie eine Pipeline 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.
    Tabelle : 3. Paket 3 (B 1.2.0, C 1.0.0)
    Commit Erstellen Sie eine Pipeline 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.
    Tabelle : 4. Paket 4 (A 1.4.0, B 1.3.0, C 1.2.0)
    Commit Erstellen Sie eine Pipeline 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 Nr. 2, in der Produktion bereitgestellt wurde.

    Beispiel: Berechnungslogik festlegen

    Anwendungsfall mit der Logik zum Berechnen von Commits, die Artefaktversionen zugeordnet werden. Die Verzweigungsinformationen werden immer dann einbezogen, wenn Commits definiert werden.

    Betrachten Sie beispielsweise zwei Pipelines, eine in der Hauptverzweigung und eine in der Testverzweigung. Szenario ausführen:

    • Commit-C0 auf Hauptelement erstellen, CI-Build ausführen, aber keine Artefaktversion erstellen.
    • Commit C1 beim Test erstellen, CI-Build ausführen, aber keine Artefaktversion erstellen.
    • Erstellen Sie einen Commit C2 auf dem Hauptelement, führen Sie einen CI-Build aus, und der Build schlägt fehl.
    • Erstellen Sie 2 Commits C3, C4 auf Hauptelement, führen Sie einen CI-Build aus, und erstellen Sie eine Artefaktversion (v1.0).
    Erwartetes Ergebnis: Artefaktversion (v1.0) ist C0, C2, C3, C4 zugeordnet. Commit C1 ist ausgeschlossen, da es sich in einer anderen Verzweigung befindet.
    Fortsetzung des Anwendungsfalls:
    • 1 Commit C5 auf Haupt erstellen, CI-Build ausführen, aber keine Artefaktversion erstellen.
    • Erstellen Sie 1 Commit C6 auf dem Hauptelement, führen Sie den CI-Build aus, und erstellen Sie eine Artefaktversion (v2.0).
    Erwartetes Ergebnis: Die neu erstellte Artefaktversion (v2.0) ist C5, C6 zugeordnet.
    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 werden zugeordnet.
    • Wenn keine vorherige Artefaktversion für das angegebene Artefakt gefunden wird, werden alle Commits aus Pipeline-Ausführungen in derselben Verzweigung zugeordnet.

    Fortsetzung des Anwendungsfalls:

    Erstellen Sie ein Release mit der Artefaktversion aus dem vorherigen Schritt, und verfügen Sie über eine CD-Pipeline mit Schritttyp = Prod-Bereitstellung.

    Erwartetes Ergebnis:
    • Release ist mit derselben Artefaktversion (v2.0) verknüpft.
    • Die erstellte Change-Anforderung zeigt die Artefaktversion (v2.0) und die Commits C0, C2, C3, C4, C5, C6.
    Zusammenfassung:
    • Commits aus beiden Artefaktversionen (v1.0, v2.0), die im Hauptzweig erstellt wurden (kein vorheriges Paket wurde in Prod bereitgestellt), werden in der Change-Anforderung angezeigt, jedoch nicht im Commit aus der Ausführung in der Testverzweigung.
    • Die Anzahl der in der Change-Anforderung angezeigten Commits entspricht der Anzahl im Tool.
    Fortsetzung des Anwendungsfalls:
    • Erstellen Sie 2 Commits C7, 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, 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 der Artefaktversion aus dem vorherigen Schritt (v4.0). Sie haben eine CD-Pipeline mit Schritttyp = Prod-Bereitstellung.
      Erwartetes Ergebnis:
      • Release ist mit Artefaktversion (v4.0) verknüpft.
      • Die erstellte Change-Anforderung zeigt die Artefaktversion (v4.0) und committet C9, C10.
    Zusammenfassung:
    • Die Change-Anforderung zeigt Commits nur aus der neuesten Artefaktversion, die im Hauptzweig erstellt wurde, da Commits aus früheren Artefaktversionen, die im Hauptzweig erstellt wurden, im vorherigen Paket für Prod bereitgestellt wurden.
    • Es werden keine Commits aus der beim Test erstellten Artefaktversion angezeigt.
    • Die Anzahl der in der Change-Anforderung angezeigten Commits entspricht der Anzahl im Tool.