DEV Community

Paulo Gonçalves
Paulo Gonçalves

Posted on • Updated on

Entrega contínua no ServeRest 🚀

Sumário


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:

  1. Todos os cenários deveriam ser cobertos por teste;
  2. O código deveria seguir o padrão do JS;
  3. As mensagens de commit deveriam seguir o padrão do Conventional Commit;
  4. Todas as alterações que geraram release deveriam estar documentadas no Changelog;
  5. O versionamento deveria corresponder às alterações desde a última release e ao Semantic versioning;
  6. A estratégia de branches deveria permitir integrar código na master e beta apenas se todas as validações fossem executadas;
  7. Publicar na dist-tag @latest apenas o que fosse integrado na master, e @beta o que fosse integrado na branch beta;
  8. 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.

  1. Standard - JavaScript style guide, linter, and formatter;
  2. Husky - Executa ações em git hooks, como pre-commit e commit-msg;
  3. Commitlint - Valida se a mensagem de commit segue o conventional commits;
  4. Supertest - Testes de APIs Rest;
  5. 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);
  6. Semantic-release/release-notes-generator - Gera as notas da release;
  7. Semantic-release/changelog - Gera/atualiza o changelog com as notas da release;
  8. Semantic-release/npm - Atualiza a versão do projeto e publica o pacote NPM;
  9. Semantic-release/git - Commita o package.json, package-lock.json e o CHANGELOG.md;
  10. 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.

  1. O desenvolvedor irá atuar em uma branch a partir da master (seguindo o Github Flow).
  2. 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

Continuous Integration

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:

  1. Code review de outro desenvolvedor;
  2. 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;
  3. Validação da mensagem de commit com commitlint. Executado na pipeline de integração contínua;
  4. 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

Continuous Delivery

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:

  1. A versão do package.json e do package-lock.json são atualizadas;
  2. É gerada as notas de release contendo informação de todos os commits desde a última git tag;
  3. O CHANGELOG é atualizado com as notas de release;
  4. É realizado publicação no NPM, e o artefato é armazenado temporariamente;
  5. 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;
  6. É criado nova release no Github utilizando a tag gerada, o artefato armazenado temporariamente e as notas de release;
  7. É 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 ⭐.


Esse post está sendo versionado e hospedado no Github

Top comments (0)