Plugin-Migrationsanleitung
Nutze diesen Hub, um den passenden Migrationspfad für dein aktuelles Release-Tool auszuwählen.
Quell-Tool auswählen
Abschnitt betitelt „Quell-Tool auswählen“| Aktuelles Tool | Passende Migrationsseite | Typische Migrationspriorität |
|---|---|---|
| semantic-release | Von semantic-release zu semrel | zuerst Analyzer + Generatoren, dann Publisher-Parität |
| GoReleaser | Von GoReleaser zu semrel | zuerst Build-Matrix-Parität, dann Split für Package/Publish |
| release-please | Von release-please zu semrel | PR-Transparenz behalten, dann Tag-/Release-Ownership umstellen |
Gemeinsame Migrationsbasis
Abschnitt betitelt „Gemeinsame Migrationsbasis“Alle Migrationspfade laufen auf dasselbe semrel-Zielmodell hinaus:
- Updater pflegen Versionsmetadaten in Quell- und Konfigurationsdateien
- Packager erzeugen auslieferbare Artefakte
- Publisher laden Artefakte in Registries oder HTTP-Endpunkte hoch
Migrationsstrategie
Abschnitt betitelt „Migrationsstrategie“- Vorhandene Updater-Plugins unverändert beibehalten.
- In CI eine Build-Stufe ergänzen, die echte Release-Artefakte erzeugt (
dist/,charts/, Image-Tarballs). - Packager-/Publisher-Plugins nach der Build-Stufe einhängen.
- Zuerst im Dry-Run ausführen und Ergebnisse mit dem bisherigen Release-Flow vergleichen.
- Dann produktiv schalten und die ersten 2-3 Releases eng überwachen.
Validierungs-Checkliste
Abschnitt betitelt „Validierungs-Checkliste“semrel --dry-run releasezeigt die erwartete Plugin-Reihenfolge und Artefaktpfade.- Build-Artefakte existieren, bevor Publisher-Plugins starten.
- Zugangsdaten für Registry/Endpoint kommen über Umgebungsvariablen.
- Release Notes und Changelog enthalten weiterhin die erwarteten Inhalte.
- Ein Rollback-Pfad ist vorhanden (alten Release-Flow für einen Zyklus parallel behalten).