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ção
versã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 ❤️!