Versionnummern und Wechselprotokolle auf Autopilot

Früher war bei der Freilassung ein kleines Ritual erforderlich. Jemand entscheidet, dass es Zeit ist. Sie schauen sich die Kommits seit der letzten Version an, versuchen sich zu erinnern, was sich geändert hat, erraten, ob es eine Neben- oder Hauptversion ist, schreiben ein Changelog von Hand, markieren es und hoffen, dass sie nichts vergessen haben.

Wenn wir diesen Prozess automatisieren, ergibt sich meist ein besseres Ergebnis als wenn wir ihn manuell steuern.

Semantisches Versionenmanagement, einfach

Die meisten Projekte verwenden Semantische Versionen (SemVer): MAJOR.MINOR.PATCHWie ... 2.4.1.

• FERREN (2.4.1 → 2.4.2): Fehlerbehebungen, nichts Neues, nichts kaputt.
• Minderjährig (2.4.1 → 2.5.0): neue Funktionen, rückwärtskompatibel.
• - Das ist nicht wahr . (2.4.1 → 3.0.0): Veränderungen zu brechen. Die Nutzer müssen vielleicht etwas ändern.

Die Versionnummer ist ein Versprechen an Ihre Nutzer. Ein kleines Upgrade sollte sicher sein. Ein großer verdient Aufmerksamkeit.

Konventionelle Verpflichtungen

Der Trick zur Automatisierung von Versionen ist, dass Kommit-Nachrichten maschinell lesbar werden. Konventionelle Verpflichtungen ist eine einfache Konvention:

feat: add Apple Pay to checkout
fix: handle empty cart in order summary
docs: explain retry configuration
chore: update dependencies
feat!: remove deprecated v1 payment API

• feat bedeutet eine neue Funktion, also ein Kleines - Was ist?
• fix bedeutet eine Fehlerbehebung, also ein Patch - Was ist?
• ! oder BREAKING CHANGE: Fußzeile bedeutet: Haupt - Was ist?
• Andere Arten (docs, chore, refactor, test, ciDie Reaktion der Zellen auf die Zellen ist nicht von selbst auszulösen.

Sie können auch einen Bereich hinzufügen: fix(api): ..., feat(ui): ....

Um alle konsistent zu halten, fügen Sie Verpflichten als Check oder Squash-Fusionsversionen, bei denen der Titel der Pull-Anfrage der Konvention folgt, was für Teams oft einfacher ist.

Wenn Ihre Kommit-Geschichte klar genug ist, dass eine Maschine sie versteht, ist sie auch für Ihr zukünftiges Selbst klar genug.

Freisetzung bitte in Aktion

Bitte lassen Sie los., von Google, ist mein Lieblingswerkzeug dafür. Es beobachtet Ihre Hauptniederlassung und hält eine offene "Release Pull-Anfrage" mit:

• Die nächste Versionnummer, berechnet anhand der seit der letzten Veröffentlichung eingegangenen Kommits.
• Eine aktualisierte CHANGELOG.md, gruppiert in Features, Bugfixes und Änderungen.
• Versionen in Dateien wie package.json, pyproject.toml oder ein Helm Chart.yaml.

Wenn Sie bereit sind, zu entlassen, fügen Sie die Pull-Anfrage zusammen. release-please erstellt den Git-Tag und die GitHub-Veröffentlichung. Ihre normale Pipeline sieht das Tag und baut und veröffentlicht die Artefakte.

name: release-please
on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@<sha> # v4
        with:
          release-type: go

Was mir gefällt: ein Mensch entscheidet immer noch Wann Die Kommission hat die Kommission aufgefordert, die Das Werkzeug macht die Buchhaltung.

Semantic-release ist eine beliebte Alternative, die bei jeder Fusion automatisch freigegeben wird. Perfekt für Bibliotheken mit häufigen kleinen Releases, ein bisschen zu eifrig für einige Anwendungen.

Die Changerlogs lesen die Leute tatsächlich.

Die generierten Changelogs sind nur so gut wie Ihre Kommit-Nachrichten. Ein paar Tipps:

• Schreiben von Kommit- (oder PR-) Titeln für Benutzer, nicht für sich selbst: "Fix: zeigen Sie den richtigen Preis für ermäßigte Artikel", nicht "Bug-Fix".
• Die Änderungen werden klar markiert und die Migrationsschritte im Kommit-Body erläutert.
• Bearbeiten Sie den Changelog der PR-Veröffentlichung, bevor Sie die Verknüpfung durchführen, falls etwas mehr Erläuterungen benötigt. Es ist nur eine Akte.

Trunk-basiert oder GitFlow?

Automatisierte Versionsüberwachung funktioniert am besten mit Entwicklung auf Basis von Stamm: kurzlebige Zweige, die oft in den Hauptzweig zusammengeführt werden, wobei der Hauptzweig immer freigesetzt werden kann. Die Entlassungen sind nur Marken auf der Hauptstraße.

GitFlow, mit langlebigen Entwicklungs-, Release- und Hotfix-Abteilungen, wurde für eine Welt mit seltenen, großen Releases entwickelt. Für einige Produkte (wie Software, die an Kunden geliefert wird, die bestimmte Versionen installieren) ist es immer noch sinnvoll, aber für die meisten Webdienste fügt es Komplexität hinzu, ohne viel Nutzen zu bringen.

Also, wo fange ich an?

Einverstanden sein mit konventionellen Commits für Pull-Request-Titel, sie mit einer einfachen Überprüfung durchsetzen und Release-Please zu einem Repository hinzufügen. Nach ein paar Veröffentlichungen wird niemand wieder mit der Hand Schreiblogs schreiben wollen.

Ich sage: Lassen Sie den Roboter zählen und schreiben. Die Menschen entscheiden, wann sie abschieben.

Desly