Paulo Gonçalves

Posted on Jun 8, 2020 • Edited on Aug 5, 2020

Entrega contínua no ServeRest 🚀

#continuousdelivery #serverest #ptbr

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 e beta 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 branch beta;
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 e commit-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 ou patch);
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 o CHANGELOG.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.
1. pre-commit: Será executado o standard, validando se o código respeita ao padrão de código do JS.
2. commit-msg: Será executado o commitlint, validando se a mensagem de commit segue o conventional commit.

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 ⭐.