semantic-release vs release-please: Releases automatizados no CI
Ambos automatizam o versionamento a partir de Conventional Commits, mas o semantic-release publica direto do CI enquanto o release-please propõe um PR de release revisável.
O semantic-release analisa commits e publica uma nova versão (changelog, tags, registry) automaticamente no push. O release-please (Google), em vez disso, abre e mantém um PR de release; ao dar merge nele, o release é feito, mantendo um gate humano.
| semantic-release | release-please | |
|---|---|---|
| Gatilho do release | Automático no push para a branch de release | Merge do PR de release |
| Gate humano | Nenhum por padrão | Sim (revisar o PR) |
| Changelog/versionamento | A partir dos commits | A partir dos commits |
| Etapa de publicação | Integrada à execução | Após o merge do PR |
| Melhor para | Pipelines totalmente automatizados | Releases revisados e agrupados |
No CI
O semantic-release é totalmente sem intervenção: faça push de commits em conformidade e ele versiona, cria tags e publica no mesmo job. O release-please mantém um humano no loop ao manter um PR de release que agrupa mudanças e um changelog até você dar merge, o que serve a times que querem revisar o que é lançado. Ambos dependem de Conventional Commits e rodam como uma etapa de CI.
Setup de CI
Dê ao job de release os tokens/permissões certos para criar tags e publicar, e fixe a versão da ferramenta para reprodutibilidade. O job de release roda nos runners de CI; runners gerenciados mais rápidos encurtam builds de release que também compilam ou empacotam artefatos.
O veredito
Quer publicação totalmente automatizada direto do CI: semantic-release. Quer um PR de release revisável e agrupado como gate: release-please. Ambos usam Conventional Commits - escolha pelo quanto de controle humano você quer sobre cada release.