Von release-please zu semrel
Diese Anleitung unterstützt Teams beim Umstieg von release-please auf semrel, ohne Release-Governance zu verlieren.
Mapping auf einen Blick
Abschnitt betitelt „Mapping auf einen Blick“| release-please Verhalten | semrel Entsprechung |
|---|---|
| Release-PR mit Versions-/Changelog-Änderungen | semrel Analyzer + Generator-Ausgaben in CI |
| Tag und Release nach Merge | semrel Provider + Publish-Stufen |
| PR-Transparenz und Review-Gate | Branch-Protection beibehalten, semrel nach Merge ausführen |
Empfohlenes Rollout
Abschnitt betitelt „Empfohlenes Rollout“- release-please PR-Flow vorübergehend für Audit-Transparenz beibehalten.
- semrel Dry-Run auf gemergten PRs ausführen und Version/Changelog vergleichen.
- Version/Changelog-Ownership auf semrel-Plugins umstellen.
- Publishing und Tag-Ownership auf semrel verlagern.
- release-please Release-Erstellung deaktivieren, um doppelte Tags/Releases zu verhindern.
Beispiel-Plugin-Basis
Abschnitt betitelt „Beispiel-Plugin-Basis“plugins: - uses: @semrel/github
- uses: @semrel/conventional
- uses: @semrel/release-notes
- uses: @semrel/changelog-md args: file: CHANGELOG.mdRisiken und Checks
Abschnitt betitelt „Risiken und Checks“- release-please und semrel dürfen nie gleichzeitig Tags erzeugen.
- Monorepo-Paketversionsverhalten vor dem Cutover prüfen.
- Rollback testen, indem der bisherige Workflow für einen Zyklus verfügbar bleibt.