Entrega contínua no ServeRest 🚀

Sumário

• ❓ O que é entrega contínua (Continuous delivery)?
• ❓ O que é o ServeRest?
• 🏁 Resultado
• 🔨 Desafios
• 📁 Libs NPM utilizadas
• 📑 Fluxo de trabalho
  • 1️⃣ Issue
  • 2️⃣ Desenvolvimento local
  • 3️⃣ Pull Request
  • 4️⃣ Criação da release
  • 5️⃣ Comunicação de release gerada

---

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

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

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