So automatisieren Sie Projektversioning und Veröffentlichungen mit kontinuierlicher Bereitstellung

Durch die Verwendung semantischer Versionsregelung kann die Wartung und Kommunikation von Softwareänderungen erleichtert werden. Manuelle Vorgänge sind jedoch umständlich. Selbst wenn Sie PR manuell verschmelzen, die Einreichung markieren und die Version verschieben, müssen Sie eine Release -Beschreibung schreiben. Es gibt viele Schritte, hohe Wiederholung, zeitaufwändig und arbeitsintensiv.

In diesem Artikel wird erläutert, wie effizientere Prozesse erzielt und Release -Prozesse vollständig automatisiert werden können, indem die semantische Versionierung in den kontinuierlichen Bereitstellungsprozess integriert wird.

Semantische Versionskontrolle

Eine semantische Version ist eine Versionsnummer, die aus drei Zahlen besteht, wie z. B. 1.4.10. Jede Zahl hat eine bestimmte Bedeutung:

Hauptversionsänderungen (Major)

Die erste Zahl zeigt eine Hauptversionsänderung an, was bedeutet, dass sich eine zerstörerische Veränderung vorliegt.

Minor -Versionsänderungen (Moll)

Die zweite Zahl zeigt eine geringfügige Versionsänderung an, was bedeutet, dass neue Funktionen hinzugefügt wurden.

Patch -Version Änderung

Die dritte Nummer gibt eine gepatchte Versionsänderung an, was bedeutet, dass ein Fehler behoben wird.

Die semantische Version kann besser verstanden werden als: destruktive Veränderungen, funktionale Änderungen und Fehlerbehebungen. Diese Beschreibung ist präziser und vermeidet Mehrdeutigkeit.

Informationsformat einreichen

Um sicherzustellen, dass die semantische Versionsnummer korrekt inkrementiert ist und die richtige Version veröffentlicht wird, ist ein standardisiertes Format zur Einreichungsinformation erforderlich. Ein standardisiertes Format zur Einreichungsinformation hilft zu bestimmen, wann die Zahl in Erhöhen und einfacher Veröffentlichungsanweisungen erstellt wird. Hier wird Angular verwendet, um Informationskonventionen einzureichen, und es kann natürlich auch nach Bedarf geändert werden.

Das Format lautet wie folgt:

<code></code>

Jede Einreichung enthält Titel , Körper und Fußnote .

Titel einreichen

Der Titel ist ein Muss, er verfügt über ein spezielles Format, einschließlich Typ , optionalem Umfang und Thema .

Der Titeltyp ist ein erforderliches Feld, um die Auswirkungen der Einreichung auf die nächste Version zu veranschaulichen. Es muss einer der folgenden Typen sein:

• Feat : Neue Funktionen
• Fix : Bug Fix
• Dokumente : Dokumentwechsel
• Stil : Änderungen, die die Bedeutung des Codes nicht beeinflussen (z. B. Räume, Formate, fehlende Semikolons usw.)
• Refactor : Code Refactoring, weder Behebung von Fehler noch Funktionen hinzufügen
• Perf : Leistungsverbesserungen
• Test : Fügen Sie Test hinzu oder korrigieren Sie den Test
• Aufgabe : Änderungen zum Erstellen von Prozessen oder Hilfstools und -Bibliotheken, z. B. Dokumente generieren

Ein Zielfernrohr ist eine Gruppierungseigenschaft, die Subsysteme angibt, die sich auf Subsysteme wie APIs, Anwendungs ​​-Dashboards oder Benutzerkonten usw. einreichen.

Das Titelthema sollte kurz die vorgenommenen Änderungen beschreiben. Die folgenden Regeln sind beim Schreiben eines Themas erforderlich:

• Verwenden Sie imperative Sätze, vorhandene Zeitform (z. B. "verändert" anstelle von "verändert" oder "verändert").
• Kleinbuchstaben des Anfangsbuchstabens.
• Am Ende wird keine Periode (.) Hinzugefügt.
• Vermeiden Sie Themenlängen von mehr als 80 Zeichen. Senden Sie die Leiche ein.

Wie das Titelthema sollte auch der Haupttext imperativen Sätzen anwesend werden. Es sollte die Motivation für die Veränderung enthalten und mit dem vorherigen Verhalten vergleichen.

Fußnoten einreichen

Die Fußnote sollte Informationen über die destruktiven Änderungen enthalten, und auch die Frage, die für diese Einreichung angegeben ist.

Destruktive Veränderungsinformationen sollten mit dem Brechen von Veränderungen beginnen: gefolgt von einem Raum oder zwei neuen Zeilen. Die verbleibenden Einreichungsinformationen finden Sie hier.

Erzwingen Sie das Format des Einreichungsinformates

In der Teamarbeit ist es immer eine Herausforderung, alles zu standardisieren, was jeder folgen muss. Um sicherzustellen, dass jeder die gleichen Einreichungskriterien verwendet, werden wir Komitee verwenden.

Commitizen ist ein Befehlszeilen -Tool, das den Prozess der Verwendung eines konsistenten Commit -Nachrichtenformats vereinfacht. Wenn Sie das Repository mit dem Komitee kompatibel machen, kann jeder im Team Git CZ ausführen und detaillierte Eingabeaufforderungen zum Ausfüllen der Einreichungsinformationen erhalten.

Generieren und veröffentlichen

Nachdem wir wissen, dass unsere Einsendungen konsistente Standards folgen, können wir damit beginnen, Veröffentlichungen und Freigabeboten zu generieren. Dazu verwenden wir ein Paket namens Semantic-Release. Dies ist ein gut gepflegtes Paket mit einer guten Unterstützung für eine Vielzahl von CI-Plattformen (Continuous Integration).

Semantische Freisetzung ist der Schlüssel zu unserer Reise, da alle für die Veröffentlichung erforderlichen Schritte durchgeführt werden, darunter:

1. Bestätigen Sie die letzte Version, die Sie veröffentlicht haben
2. Bestimmen Sie den Veröffentlichungstyp basierend auf den seit der letzten Veröffentlichung hinzugefügten Einsendungen
3. Generieren Sie Veröffentlichungsanweisungen für Einsendungen, die seit der letzten Veröffentlichung hinzugefügt wurden
4. Aktualisieren Sie die Datei package.json und erstellen Sie ein GIT -Tag, das der neu veröffentlichten Version entspricht
5. Neue Version schieben

Jeder CI ist in Ordnung. In diesem Artikel verwenden wir Github-Aktionen, da ich die vorhandenen Funktionen der Plattform gerne verwenden möchte, bevor ich nach einer Lösung von Drittanbietern suche.

Es gibt viele Möglichkeiten, semantische Freisetzung zu installieren, aber wir werden semantische Release-CLI verwenden, da es Schritt-für-Schritt-Vorgänge bietet. Lassen Sie uns das NPX-Semantik-Release-Cli-Setup im Terminal ausführen und den interaktiven Zauberer ausfüllen.

Das Skript wird Folgendes ausführen:

• Führen Sie den NPM -Adduser mit den bereitgestellten NPM -Informationen aus, um .npmrc zu generieren.
• Erstellen Sie ein GitHub Personal Access Token.
• Update package.json.

Sobald die CLI beendet ist, fügt sie package.json semantische Freisetzung hinzu, aber sie wird sie nicht tatsächlich installieren. Führen Sie die NPM -Installation aus, um es und andere Projektabhängigkeiten zu installieren.

Das einzige, was noch übrig ist, ist, CI durch GitHub -Aktionen zu konfigurieren. Wir müssen manuell einen Workflow hinzufügen, der semantische Freisetzung ausführt. Erstellen wir einen Publishing -Workflow in .github/Workflows/Release.yml.

 <code>name: Release on: push: branches: - main jobs: release: name: Release runs-on: ubuntu-18.04 steps: - name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci - name: Release env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # If you need an NPM release, you can add the NPM_TOKEN # NPM_TOKEN: ${{ secrets.NPM_TOKEN }} run: npm run release</code>

Steffen Brewersdorff hat CI mit Github -Aktionen hervorragend eingeführt, aber lassen Sie uns kurz überprüfen, was hier vor sich geht.

Dies wartet, bis ein Druck in den Hauptzweig auftritt, bevor die Pipeline ausgeführt wird. Sie können diese Einstellung ändern, wenn Sie mit einem, zwei oder allen Zweigen ausgeführt werden möchten.

 <code>on: push: branches: - main</code>

Anschließend wird das Repository gezogen und den Knoten installiert, sodass NPM zur Installation von Projektabhängigkeiten verwendet werden kann. Wenn dies etwas ist, das Sie bevorzugen, können Sie einen Testschritt hinzufügen.

 <code>- name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci # You can add a test step here # - name: Run Tests # run: npm test</code>

Lassen Sie schließlich die semantische Freisetzung alle magischen Operationen durchführen:

 <code>- name: Release run: npm run release</code>

Drücken Sie Änderungen und Ansichtsaktionen:

Jedes Mal, wenn ein bestimmter Zweig verpflichtet (oder zusammengeführt) wird, wird der Vorgang ausgeführt und mit einem Release -Hinweis veröffentlicht.

Poste eine Party!

Wir haben erfolgreich einen semantischen CI/CD -Workflow erstellt! Ist es nicht so schmerzhaft? Das Setup ist relativ einfach und es gibt keine Nachteile, wenn ein semantischer Veröffentlichungsworkflow vorhanden ist. Es erleichtert nur die Verfolgung von Änderungen.

Semantische Freisetzung Es gibt viele Plug-Ins, die eine fortgeschrittenere Automatisierung ermöglichen. Zum Beispiel gibt es sogar einen Slack -Release -Bot, der nach erfolgreicher Bereitstellung des Projekts im Projektkanal veröffentlicht werden kann. Sie müssen nicht zu Github gehen, um Updates zu finden!

Das obige ist der detaillierte Inhalt vonSo automatisieren Sie Projektversioning und Veröffentlichungen mit kontinuierlicher Bereitstellung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!