Sumário
- ❓ O que é entrega contínua (Continuous delivery)?
- ❓ O que é o ServeRest?
- 🏁 Resultado
- 🔨 Desafios
- 📁 Libs NPM utilizadas
- 📑 Fluxo de trabalho
Nesse texto vou relatar todas as etapas necessárias para a implementação da entrega contínua no ServeRest, as vantagens dela e porque não é apenas inserir npm publish
na pipeline do projeto, mas sendo um conjunto de boas práticas.
Não é possível entregar código de qualidade sem um bom processo de desenvolvimento
⛔ O QUE NÃO IREI ABORDAR: Detalhes de implementação o suficiente para configurar a entrega contínua no seu projeto. Porém é possível utilizar as informações passadas para tal fim, já que é um agregado de informações coletadas e que deram certo.
Antes de abordarmos a entrega contínua aplicada no ServeRest, temos que entender 2 coisas:
❓ O que é entrega contínua (Continuous delivery)?
A definição de entrega contínua fornecida pelo http://continuousdelivery.com é:
Entrega Contínua é a capacidade de obter alterações de todos os tipos - incluindo novos recursos, alterações de configuração, correções de bugs e experimentos - em produção ou nas mãos dos usuários, com segurança e rapidez, de maneira sustentável.
❓ O que é o ServeRest?
O ServeRest é um projeto NPM open source de ensino de testes de API para QAs. Ele fornece APIs Rest de forma fácil e bem documentada para que seja possível testar os verbos GET, POST, DELETE e PUT, autenticação e segurança de API.
Sendo o ServeRest um projeto com foco em qualidade, não seria menos esperado dele de que possuísse um processo de desenvolvimento de qualidade.
🏁 Resultado
Antes de passarmos por detalhes da entrega contínua, é importante entendermos o ganho adquirido.
A entrega contínua foi importante para garantir a qualidade de software do ServeRest e rapidez na entrega de novas releases. Com ela apenas código bem estruturado, que passa em todos os testes e possui boa mensagem de commit é integrado ao código. Além de que as releases são geradas apenas se necessário, de acordo com alguns critérios.
Para o mantenedor do projeto, basta realizar code review em PR de outros colaboradores e realizar o merge com a branch master ou beta. Não terá mais a preocupação em atualizar a master/beta local, criar tag, atualizar o changelog, commitar, executar git push
e npm publish
apontando para a tag correta (@latest caso fosse a branch master e @beta caso fosse a branch beta).
O impacto para o usuário é de que correções sejam liberadas de forma mais rápida e, principalmente, bugs em produção são menos frequentes.
🔨 Desafios
Para entregar o código em produção com rapidez e segurança, alguns itens teriam que ser solucionados:
- Todos os cenários deveriam ser cobertos por teste;
- O código deveria seguir o padrão do JS;
- As mensagens de commit deveriam seguir o padrão do Conventional Commit;
- Todas as alterações que geraram release deveriam estar documentadas no Changelog;
- O versionamento deveria corresponder às alterações desde a última release e ao Semantic versioning;
- A estratégia de branches deveria permitir integrar código na
master
ebeta
apenas se todas as validações fossem executadas; - Publicar na dist-tag @latest apenas o que fosse integrado na
master
, e @beta o que fosse integrado na branchbeta
; - Somente deveria ser feita publicação automática caso a alteração realizada necessitasse de publicação.
📁 Libs NPM utilizadas
Para solucionar todos os desafios listados acima e poder entregar uma release com qualidade e manter o código bem estruturado, foram utilizadas diversas libs NPM em conjunto, cada qual com sua responsabilidade e sendo executadas em etapas diferentes no fluxo de trabalho.
-
Standard -
JavaScript style guide, linter, and formatter
; -
Husky - Executa ações em git hooks, como
pre-commit
ecommit-msg
; - Commitlint - Valida se a mensagem de commit segue o conventional commits;
- Supertest - Testes de APIs Rest;
-
Semantic-release/commit-analyzer - Analisa as mensagens de commit de acordo com o conventional-changelog e informa qual tipo de versão deve ser gerada (
major
,minor
oupatch
); - Semantic-release/release-notes-generator - Gera as notas da release;
- Semantic-release/changelog - Gera/atualiza o changelog com as notas da release;
- Semantic-release/npm - Atualiza a versão do projeto e publica o pacote NPM;
-
Semantic-release/git - Commita o
package.json
,package-lock.json
e oCHANGELOG.md
; - Semantic-release/github - Publica uma release no Github com as notas da release.
Para mais detalhes visualize a seção devDependencies do package.json
📑 Fluxo de trabalho
Abaixo será relatado todo o fluxo de trabalho, desde o momento que um bug é relatado até o momento que a correção está publicada em nova release.
1️⃣ Issue
Um usuário abre uma nova issue no projeto, relatando um bug e seguindo o template de issue.
2️⃣ Desenvolvimento local
Libs: husky
, commitlint
e standard
.
- O desenvolvedor irá atuar em uma branch a partir da master (seguindo o Github Flow).
- Serão feito os ajustes afim de corrigir o bug, e então será realizado o commit. Nesse momento será utilizado a lib
husky
.-
pre-commit: Será executado o
standard
, validando se o código respeita ao padrão de código do JS. -
commit-msg: Será executado o
commitlint
, validando se a mensagem de commit segue o conventional commit.
-
pre-commit: Será executado o
Caso alguma validação encontre problema, o commit será abortado, e então o dev terá que ajustar o código ou a mensagem de commit. Com isso todo commit realizado estará bem estruturado.
3️⃣ Pull Request
Libs: supertest
, commitlint
e standard
O desenvolvedor irá abrir no Github uma Pull Request para integrar a sua branch com a master. O PR somente será mergeado caso as seguintes etapas sejam aprovadas:
- Code review de outro desenvolvedor;
- Validação dos testes de API criados com
supertest
nas 3 principais versões LTS do node. Executado na pipeline de integração contínua; - Validação da mensagem de commit com
commitlint
. Executado na pipeline de integração contínua; - Validação da estrutura do código com
standard
. Executado na pipeline de integração contínua.
Print de validações feitas em um Pull Request:
4️⃣ Criação da release
Lib: semantic-release/*
Após o PR ser aprovado e integrado com a master ou beta, começa todo o processo de entrega contínua.
Inicialmente são executados as mesmas validações feitas na PR (commitlint, standard e testes de API). Apenas com a execução com sucesso de todas essas validações é que é iniciado o processo de entrega contínua.
Print da pipeline de Continuous Delivery:
Na atividade release é executado o semantic-release
, que utiliza a configuração implementada e realiza as tarefas de entrega contínua.
Inicialmente é validado se há commit, desde a última git tag, que gera uma nova release major
, minor
ou patch
. Caso esse critério seja atendido as seguintes ações são realizadas:
- A versão do package.json e do package-lock.json são atualizadas;
- É gerada as notas de release contendo informação de todos os commits desde a última git tag;
- O CHANGELOG é atualizado com as notas de release;
- É realizado publicação no NPM, e o artefato é armazenado temporariamente;
-
package.json, package-lock.json e CHANGELOG são commitados com nova tag e informação da nova release. É utilizado o usuário
semantic-release-bot
; - É criado nova release no Github utilizando a tag gerada, o artefato armazenado temporariamente e as notas de release;
- É feita comunicação aos interessados sobre a nova release. Veja mais na seção Comunicação de release gerada.
Print do commit do semantic-release
:
Print da release gerada no github:
Caso queira verificar com mais detalhes a configuração feita quanto ao
semantic-release
, verifique o arquivo .releaserc.js e o workflow de continuous delivery (a partir da linha 60).
5️⃣ Comunicação de release gerada
Lib: semantic-release
Após a publicação da release em produção é preciso comunicar aos interessados de que suas respectivas issues e PR foram corrigidas.
O semantic-release
verifica quais issues foram fechadas e quais PRs foram aprovados e que fazem parte da nova release. Com isso ele adiciona comentário informando de que uma nova release está disponível com a solução para a situação relatada e adiciona as labels released on @{tag} e released on @{versão}.
Print de comentário e label automático em PR:
Com isso passamos por todas as etapas da entrega contínua no contexto do ServeRest. Caso tenha dúvidas ou sugestões, deixe um comentário abaixo. Não deixe de visitar o repositório do ServeRest e deixar a sua estrelinha ⭐.
Top comments (0)