Continuando do post capítulo 1. Vou continuar falando de práticas que aprendi sobre Entrega Contínua.
Estou construindo um blog e usando essa construção como exemplo para o assunto.
Esta é a segunda parte. Se você não leu a primeira parte, aqui: capítulo 1.
(Antes de voltarmos a esse papo de Entrega Contínua. Um ponto. Houve alguns termos que são minhas traduções livres. Se você conhece traduções melhores comenta logo abaixo. Obrigada!)
Integração Contínua
Com testes bem escritos e com boa cobertura, nós garantimos que os requisitos do sistema estão satisfeitos.
Testes nos dão a segurança que novos códigos no fonte não mudarão funcionalidades já existentes ou garantir que novas funcionalidades façam o que se espera delas. Os testes precisam traduzir como o sistema deve funcionar.
"Falhe rápido, falhe frequentemente" (tradução livre-“Fail fast, fail often”)
Como desenvolvedoras precisamos fazer commits/pushes (Git) frequentes e pequenos, executar sempre os testes localmente antes de puxar código, executar verificações de segurança (próxima seção).
Um commit é uma peça de código onde todos os testes (novos e velhos) passam e o código está pronto para ser usado em produção.
Tenha uma suite de testes consistente. Como desenvolvedora pense nos possíveis cenários, de sucesso e erro, que você consegue elaborar.
Como time, tenham estórias consistentes, pequenas, com valor e com critérios de aceitação (acceptance criteria). Aqui um texto sobre usar I.N.V.E.S.T, uma técnica para escrever estórias.
Use uma ferramenta de Entrega e Implantação Contínua (CI/CD em inglês-Continuous Integration e Continuous Deployment). Existem muitas opções no mercado: Circle CI, Go CD, Travis CI, Concourse CI, etc. Elas ajudam a ter um lugar centralizado onde seu time pode seguir a situação do código: testes, análises de qualidade, implantação entre os ambientes, e por aí vai.
Com a prática da Integração Contínua, você garante a junção dos códigos vindos dos pares ou pessoas no seu time e que o código integrado está ideal para uso. Vá além dos testes unitários. Há outros tipos de testes, mais alto nível, que podem ajudar a fazer a entrega mais confiável. Alguns exemplos de tipos de testes: End to end (preferir não traduzir), Funcionais, Integração.
Ainda sobre testes, pesquise sobre Pirâmide de Testes e o anti padrão Ice Cream Cone.
Testes de segurança
Como garantir que o que entregamos é seguro?
Três coisas que vem a minha mente: evite o security sandwich (infelizmente não encontrei fontes em pt-br), use a ferramenta de Entrega e Implantação Contínua para rodar os testes de segurança e faça o ambiente para executar seus builds seguro.
No projeto do Blog (capítulo 1), eu adicionei uma verificação nas dependências, procurando por dependências vulneráveis (nsp) e também um teste de segurança estático (eslint-não só para verificações lint, scanjs, no-unsafe-innerhtml).
Já que consigo usar estas verificações por linha de comando, eu posso adicioná-las junto com outras verificações em uma ferramenta de Entrega e/ou Implantação contínua. Com isso posso monitorar se um novo código não está seguro. E isso não só para mim, mas também para as pessoas que estão contribuindo/usando meu projeto.
Pense em análise de dependências, análise de segurança estática (infelizmente fontes em inglês) e dinâmica para seu projeto. Alguns destas análises podem ser integradas na ferramenta de Integração/Implantação Contínua.
Uma boa fonte sobre o assunto de segurança é o site do OWASP (inglês) onde você encontra o OWASP Top 10 além de vários textos sobre o tema. O Top 10 consiste de uma lista das vulnerabilidades mais encontradas em sistemas pelo mundo.
Outras fontes em inglês: https://devops.com/automated-security-testing-continuous-delivery-pipeline/.
(complicado achar conteúdo em português sobre o assunto)
A tal da implantação
Lembra do processo de implantação (ou deployment pipeline)?
Nas seções/posts anteriores lemos sobre CI, tests e análises de segurança. Isto cobre desde estágio de commit (Commit Stage) até os testes manuais (Manual Testing).
Agora vamos ler sobre a Entrega (Release).
Ambientes (Environments)
Também é parte de uma entrega contínua usar ferramentas como o Docker para ajudar a manter a consistência entre os vários ambientes que você implantará sua aplicação.
Por exemplo, ter o ambiente das desenvolvedoras idêntico ao ambiente onde são executados testes de aceitação automatizados. Isso diminui o trabalho na investigação de erros otimizando o tempo do seu time para focar no que importa: a funcionalidade. Esta não é uma boa prática somente para ambientes de testes, mas também para o de produção.
Heroku, Google Cloud Platform (opção 1 e opção 2) e AWS provêem implantação usando Docker. (Fontes em inglês)
(Pretendo escrever um texto sobre Heroku com Docker. Logo mais. ;) )
Aqui um texto explicando o uso do Docker com uma aplicação NodeJS. E se for mesmo usar a ferramenta, procure por melhores práticas usando-a.
Muitas ferramentas por aí estão suportando Docker. Mesmo que você não a use, tenha em mente manter a consistência entre seus ambientes de implantação. Eles devem ser espelhos de um e outro. Talvez você se interesse por infraestrutura como código (infrastructure as code).
Implantando o blog
Eu escolhi Heroku por ser a ferramenta que tenho mais contexto.
Heroku tem uma funcionalidade chamada Pipeline. Diferente de uma ferramenta como Circle, uma pipeline no Heroku é exclusivo para monitorar/disparar as implantações para uma aplicação, e não rodar verificações tipo testes.
É possível começar uma implantação (deploy) no Heroku usando commandos Git (inglês). Mas falando em Entrega Contínua, nós precisamos pensar em automação.
O Circle 2.0 usa o arquivo .circleci/config.yml. Então…
Abaixo .circleci/config.yml no repositório continuous-delivery-blog para usar o Circle.
Eu não vou fazer Implantação Contínua (Continuous Deployment), isso significa que minha implantação em produção será manual. Eu tenho um botão "On Hold" no Circle para começar a implantação no ambiente de produção.
É isso. Eu naveguei pelos conceitos que sou exposta no meu dia-a-dia:
- Integração Contínua: faça pushes ao master, commits pequenos, não puxe sem rodar os testes localmente, seu time deve usar uma ferramenta para Integração e Entrega Contínua;
- Segurança: além de testes funcionais, de unidade, etc, é necessário integrar a Segurança no desenvolvimento de software. Isso significa termos verificações de segurança do sistema que estamos entregando em nossas builds/pipelines; Onboarding: quando alguém entra no seu time, para essa pessoa já começar a contribuir, deve existir uma boa documentação e automação de como testar e executar o sistema.
- Ambientes: é estritamente importante ter todos os ambientes com as mesmas configurações, desde do ambiente de quem desenvolve até produção. Isso evita o “funciona na minha máquina”.
- Deploy (Implantação): a implantação do seu sistema tem que ser simples como o apertar de um botão, e você deve confiar que tudo vai ficar bem quando você aperta o botão.
Outros assuntos para ficar "ligada"
Database (em Inglês)
Logging e Monitoramento
Repositório do blog: https://github.com/roselmamendes/continuous-delivery-blog
Você usa alguma das coisas que mencionei aqui?
Gostaria de pedi ajuda sobre fontes em português sobre os assuntos aqui abordados. Você conhece algum? Comenta no twitter e me marca @roselmamendes :) (rosto sorrindo)