DevOps — Como desenhar uma pipeline eficiente para aplicações

---

Validações e Integridade

Nessa fase, colocamos passos interessantes para garantir que o que foi desenvolvido não impacte aquilo que já está estável, por esse motivo é sempre essencial ter uma branch estável e sempre disparar esse tipo de validação nos momentos de merge dessas mudanças ( o que conhecemos como Pull Request ).

Validação

O ideal é desenvolver esse passo junto com as pessoas que estão desenvolvendo o projeto, tentar entender steps básicos através de uma entrevista no intuíto de entender os passos necessários para :

• Instalar as dependencias do projeto
• Construir/Compilar o projeto
• Executar os testes do projeto

Metricas

Nesse passo, é interessante extrair todas as métricas relacionadas a qualidade do projeto, essas métricas podem ser:

• Qualidade de código com ferramentas ( como Sonar ou CodeSense ), essas ferramentas são interessantes e podem mostrar detalhes dos códigos que as vezes acabam passando batido conforme o crescimento do projeto
• Podemos também extrair métricas de tempo de execução do código
• Quantidade de Pull Requests aberto por pessoas
• Motivo do Pull Requestes, se é uma nova feature ou algum fix
• Analise de performance com ferramentas como Lighthouse ou ClinicJS

Segurança

Para fazer um paralelo com a nossa vida, esse processo consistem em garantir que todas as ferramentas, bibliotecas e códigos nosso estão passando pelo processo de validade e segurança, podemos dividir essa análise em 3 passsos.

Execuções de ferramentas de análise SAST e DAST para garantir que o código exposto para o mundo externo não terá nenhuma ponto para ser explorado.

Analíses de dependências ou containers, garantir que todas as suas dependências estão atualizadas e sem nenhum código vunerável com ferramentas como:

• RetireJS
• NSP
• Snyk
• Trivy

Analíse de keys e senhas salves no código para garantir que em nenhuma possibilidade do projeto ser exposto com credenciais com:

• Gitleaks
• Trufflehog

Build and Deploy

Na fase de build e deploy do seu código, seu sistema de CI/CD deverá criar sempre criar um artefato estável, seja uma library, um arquivo ( zip, war, ear e etc ) ou uma imagem docker para ser utilizada depois.

Ideal também é que esse artefato seja salvo em um Container Registry ou Artifact Library ( como Jfrog ) específico da empresa para não expor nenhuma inteligência de negôcio.

Opinião do autor.
Sempre sugiro utilizar imagens alpines para tentar deixar o ambiente da aplicação mais automatizado possível. Imagem pesada naturalmente onerando tempo para subir a aplicação
Outro ponto importante seria para gerar apenas o artefato uma vez e publica-los em todos ambientes que ele for testado ( desenvolvimento, testes, homologação ), a ideia de ter um artefato para cada ambiente com suas particularidades acaba adicionando uma camada complexa no controle de SCM do projeto.

Rastreabilidade

Sempre que o artefato estiver criado o ideal é sempre controlar a versão em que ele está e até mesmo quando foi gerado, principalmente se sua gestão de projeto permite vários deploys/deliveries em um pequeno espaço de tempo. Algumas stacks como java e javascript utiliza-se convenções de nome nos artefatos para diferenciar os artefatos que podem se considerar instáveis ( ainda não foram aprovados para produção ) e os estáveis:

• Em JavaScript, podemos usar -beta e -alpha
• Em Java, para projetos instáveis podemos usar a convençãoversão-do-projeto-SNAPSHOT

Por fim, a versão do seu artefato pode respeitar a versão oficial do seu projeto ( packge.json, pom.xml ) junto com a data atual da execução da pipeline, isso facilitará o rastreamento do momento exato em que esse artefato foi gerado.

Exemplo:artifact-20220227-1.0.0.zip , nome-da-imagem:1.0.0-2022-02-27

Comunicação

Por ultimo mas não menos importante, um bom plano de comunicação é aquele que atinge a maior quantidade de pessoas com a mensagem necessária.

Changelog: Você usar a estratégia de manter o repisório se atualizando com um arquivo de changelog.md contendo informações tecnicas sobre as as versões publicadas e sua descrição como esta ferramenta standard-version ou maven-plugin-release.

Comunicação Interna: Você também pode desenvolver internamente automações em Python/Go para facilitar a comunicação como o Slack para notificar uma quantidade de pessoas ou canais sobre a versão publicada do produto ou até mesmo o Confluence para gerar um pré release notes contendo as informações sobre o build e deploy gerado.

---

Tem interesse em aprender mais sobre? Entre em contato conosco ❤️!