Você sabe o que é um pipeline CI/CD? Muito comentado quando o assunto são equipes ágeis e DevOps, a Integração Contínua (CI) e a Entrega Contínua (CD) incorporam ao mesmo tempo uma cultura, um conjunto de princípios operacionais e uma coleção de práticas que possibilitam às equipes de desenvolvimento de aplicações fornecer alterações de código com mais frequência e confiabilidade. Esse tipo de implementação é conhecido, basicamente, como um pipeline CI/CD.
Com um pipeline CI/CD, um artefato que faz parte do lançamento de um software, por exemplo, pode se mover e progredir pelo pipeline desde o estágio de check-in do código até os estágios de teste, construção, deploy e produção. Este conceito é poderoso porque uma vez que um pipeline é especificado, partes ou o todo do processo de implementação do projeto poderá ser automatizado, agilizando o projeto e reduzindo erros. Em outras palavras, um pipeline CI/CD facilita a entrega de software várias vezes ao dia para as empresas, automaticamente.
Como se pode imaginar, seguir um pipeline CI/CD é uma das melhores práticas que as equipes DevOps possam pensar em implementar. Também é uma prática recomendada de Metodologia Ágil, uma vez que permite às equipes de desenvolvimento de software se concentrarem em atender aos requisitos de negócios, segurança e qualidade de código uma vez que as etapas de implantação estão automatizadas no pipeline. No entanto, muitos engenheiros DevOps ainda confundem pipeline CI/CD com automação de estágios individuais em CI/CD.
Embora ferramentas diferentes possam automatizar cada estágio complicado na Integração/Entrega Contínua, toda a cadeia de desenvolvimento de software CI/CD ainda pode ser interrompida devido à intervenção manual no meio do caminho. Neste post, vamos primeiro entender os vários estágios que compõem um processo CI/CD e por que um pipeline deste tipo é essencial para uma organização entregar código em escala e com qualidade e segurança.
As equipes de desenvolvimento de aplicação das organizações geralmente consistem de desenvolvedores, QAs/testers, engenheiros de operações e SREs (Site Reliability Engineers). Eles trabalham juntos para entregar software de qualidade nas mãos de seus clientes. O CI/CD acaba sendo uma combinação de dois processos separados: integração contínua e implantação contínua. As principais etapas de cada um estão listadas e esquematizadas a seguir.
Integração Contínua
Continuous Integration (CI), ou simplesmente Integração Contínua, é o processo em que o software é construído e os testes iniciais são concluídos. O Continuous Deployment (CD), ou simplesmente Implantação Contínua (CD) é o processo de combinar código com infraestrutura, garantindo que todos os testes sejam concluídos e as políticas seguidas, e então fazer o deploy do código no ambiente pretendido. Claro que cada organização têm seus próprios processos, mas, de uma maneira geral, as principais etapas estão figuradas na imagem abaixo:
CI: Commit de Código
- Pessoas: Desenvolvedores e Engenheiros, Administradores de Banco de Dados (DBA), Equipe de Infraestrutura.
- Tecnologia: GitHub, Gitlab, SVM, BitBucket.
- Processo: Um estágio de “commit de código” é algo conhecido como “controle de versão”. Um commit é uma operação que envia ao repositório as alterações mais recentes escritas por um desenvolvedor. Cada versão do código escrita por um desenvolvedor é armazenada indefinidamente. Somente após o entendimento e revisão das alterações com os colaboradores é que os desenvolvedores irão escrever o código e confirmar assim que os requisitos de software, aprimoramentos de recursos, correções de bugs ou solicitações de alteração foram concluídos. O repositório onde as alterações de edição e commit são gerenciadas é chamado de Gerenciamento de Código Fonte (ferramenta SCM). Depois que o desenvolvedor faz o commit do código (code Push Request), as alterações passam por um merge no branch do código base armazenado em repositório central, como o GitHub .
CI: Análise Estática de Código
- Pessoas: Desenvolvedores e Engenheiros, Administrador de Banco de Dados (DBA), Equipe de infraestrutura, Testadores.
- Tecnologia: GitHub, Gitlab, SVM, BitBucket.
- Processo: Depois que o desenvolvedor escreve o código e o envia para o repositório, o sistema é acionado automaticamente para iniciar o próximo processo de análise de código. Imagine uma etapa em que o código confirmado é construído diretamente mas falha durante o build ou deploy. Isso se prova um processo lento e caro em termos de utilização de recursos, tanto da máquina quanto do capital humano. O código deve ser verificado em uma política de análise estática do código.
O SAST (Static Application Security Test) é um método de teste de caixa branca para examinar o código por dentro do sistema usando ferramentas SAST como SonarQube, Veracode, Appscan, etc., para encontrar falhas de software, vulnerabilidades e pontos fracos (como injeção SQL etc.). Este é um processo rápido onde o código é verificado para identificação de erros sintáticos. Este estágio não inclui o recurso de verificação de erros de tempo de execução, que é executado em um estágio posterior.
Incluir uma verificação de política em um pipeline automatizado pode reduzir drasticamente o número de erros encontrados posteriormente no processo.
CI: Build
- Pessoas: Desenvolvedores e Engenheiros.
- Tecnologia: Jenkins, Bamboo CI, Circle CI, Travis CI, Maven, Azure DevOps.
- Processo: O objetivo do processo de Integração Contínua é obter commits regulares de código e construir continuamente artefatos binários. O processo de integração contínua ajuda a encontrar bugs mais rapidamente, verificando se o novo módulo adicionado funciona bem com os módulos existentes. Isso ajuda a reduzir o tempo de verificação por uma nova alteração no código. As ferramentas de build ajudam a compilar e criar arquivos executáveis ou pacotes (.exe, .dll, .jar, etc.) dependendo da linguagem de programação usada para escrever o código-fonte. Durante o build, os scripts SQL também são gerados e testados juntamente com os arquivos de configuração de infraestrutura. Em resumo, o estágio do build é onde seus aplicativos são compilados. Outras sub atividades que fazem parte do processo de build são: Artifactory Storage, Build Verification e Unit Tests, sobre os quais comentaremos a seguir.
Build Verification Test (BVT)/Smoke Tests e Unit Tests
O “smoke testing” é executado imediatamente após a criação do build. O BVT verifica se todos os módulos estão integrados corretamente, bem como se os recursos críticos do programa estão funcionando bem. O objetivo é rejeitar um aplicativo muito danificado para que a equipe de QA não perca tempo instalando e testando o aplicativo de software.
Logo após essas verificações, um UT (unit test/teste de unidade) é adicionado ao pipeline para reduzir ainda mais as falhas na produção. O UT checa unidades ou componentes individuais do código escrito pelo desenvolvedor para validar se eles funcionam conforme o esperado.
Armazenamento Artifactory
Depois que um build é preparado, os pacotes são armazenados em um local centralizado ou em um banco de dados chamado Artifactory ou Repositório. Pode haver muitas compilações sendo geradas por dia, e manter o controle de todas as compilações pode ser bastante complexo. Portanto, assim que a compilação é gerada e verificada, ela é enviada ao repositório para armazenamento. Ferramentas de repositório como Jfrog Artifactory são usadas para armazenar arquivos binários como .rar, .war, .exe, Msi etc. A partir daqui, os testadores podem escolher manualmente, bem como fazer o deploy de um artefato em um ambiente de teste para fazer as devidas verificações.
CI: Estágios de Teste
- Pessoas: Testadores, Engenheiros de Controle de Qualidade (QA testers).
- Tecnologias: Selenium, Appium, Jmeter, SOAP UI, Tarantula.
- Processo: Após um processo de build, uma série de testes automatizados validam a veracidade do código. Esta etapa previne que os erros cheguem até o ambiente de produção. Dependendo do tamanho do build, essa verificação pode durar de segundos a horas. Para grandes organizações onde os códigos são “commitados” e construídos a partir de muitas equipes, essas verificações são executadas em um ambiente paralelo para economizar um tempo precioso e notificar os desenvolvedores sobre bugs o mais cedo possível.
Esses testes automatizados são configurados por testadores (conhecidos como engenheiros de QA) que, por sua vez, configuraram casos de teste e cenários com base em user stories. Eles realizam análises de regressão e testes de estresse para verificar se há desvios no resultado esperado. As atividades envolvidas nos testes são Sanity tests, Integration tests (testes de integração) e Stress testing. Vale ressaltar que este é um nível muito avançado de testes: aqui são encontrados problemas que provavelmente fugiram ao desenvolvedor que criou o código.
Testes de integração
Os testes de integração são realizados usando ferramentas como Cucumber, e Selenium, entre outras, onde módulos de aplicativos individuais são combinados e testados como um grupo enquanto se avalia a conformidade com os requisitos funcionais especificados. Após um teste de integração, alguém precisa aprovar que o conjunto de atualizações nesse grupo seja movido para o próximo estágio, que normalmente é o teste de desempenho. Esse processo de verificação pode ser complicado, mas é uma parte importante do processo geral. Existem algumas soluções emergentes para o processo de verificação.
Teste de carga
O teste de carga é realizado utilizando ferramentas de teste automatizadas como Grafana k6 e JMeter, entre outras, para verificar se um aplicativo está estável e tem um bom desempenho quando exposto a alto tráfego. Esse teste normalmente não é executado em todas as atualizações, pois o teste de estresse completo é de longa duração. Quando novos recursos importantes são lançados, várias atualizações são agrupadas e o teste de desempenho completo é concluído. Nos casos em que uma única atualização está sendo movida para o próximo estágio, o pipeline pode incluir o canary testing como alternativa.
Continuous Deployment: Bake e Deploy
- Pessoas: Engenheiro de Infraestrutura, Site Reliability Engineer(SRE), Engenheiro de Operações.
- Tecnologias: Spinnaker, Argo CD, Tekton CD.
- Processo: Após o estágio de teste ser concluído, os códigos associados ao critério estão prontos para serem implantados nos servidores onde devem ser integrados ao aplicativo principal. Antes de serem implantados na produção, eles serão implantados para teste/preparação em um ambiente beta que é usado internamente pela equipe do produto. Mas antes que os builds sejam movidos para esses ambientes, no entanto, deverão passar por dois estágios menores chamados Bake e Deploy. Ambos os estágios são nativos do Spinnaker.
CD: Bake
O “bake” neste caso refere-se à criação de uma instância de imagem imutável do código-fonte com a configuração atual na produção. Essas configurações podem ser coisas como alterações no banco de dados e outras atualizações de infraestrutura. O Spinnaker pode acionar o Jenkins para executar essa tarefa e algumas organizações preferem usar o Packer para fazer isso.
CD: Deploy
O Spinnaker passará automaticamente a imagem preparada no bake para o estágio de deploy. É aqui que o grupo de servidores é definido para ser implantado em um cluster. Um processo funcionalmente idêntico é realizado durante o estágio de deploy, semelhante aos processos de teste descritos acima. Os deploys são primeiro movidos para teste, estágio e, finalmente, para ambientes de produção – após aprovações e verificações. Todo esse processo é gerenciado por ferramentas como o Spinnaker.
CD: Verificação
Este também é um local essencial para as equipes otimizarem o processo geral de CI/CD. Como muitos testes aconteceram agora, as falhas devem ser raras. No entanto, qualquer falha neste ponto precisa ser resolvida o mais rápido possível para que o impacto no cliente final seja minimizado. Portanto, as equipes também devem considerar a automação dessa parte do processo.
O deploy para produção é realizado usando estratégias de implantação como Blue-Green, Canary Analysis, Rolling Update etc. Durante o estágio de deploy, a aplicação em execução é monitorada para validar se o deploy atual está correto ou precisa ser revertido em um roll back.
CD: Monitoramento e Observabilidade
Pessoas: SREs, Equipe de Operações
Tecnologia: One Platform, Prometheus + Grafana, Elastic Stack, Data Dog, Newrelic entre outros APMs
Processo: Para chegar a um release seguro e robusto do software, rastrear a integridade da versão em um ambiente de produção é essencial. As ferramentas de monitoramento de aplicativos farão o rastreamento a partir das métricas de desempenho estabelecidas, como a utilização da CPU e a latência das versões. Os analisadores de log farão a verificação de torrents de logs produzidos pelo middleware e sistema operacional subjacentes para identificar o comportamento e rastrear a origem dos problemas. Em caso de qualquer problema em produção, as partes envolvidas são notificadas para garantir a segurança e confiabilidade do ambiente de produção. Além disso, o estágio de monitoramento ajuda as empresas a reunir inteligência sobre como as alterações do novo software contribuem para a receita das organizações. E, de quebra, também ajudam a equipe de infraestrutura a rastrear a tendência de comportamento do sistema para fazer o planejamento de capacidade.
Continuous Deployment: Ferramenta de Feedback e Colaboração
Pessoas: SREs, Ops e Equipe de Manutenção.
Tecnologias: JIRA, ServiceNow, Slack, Email, Hipchat.
Processo: O objetivo das equipes DevOps é lançar mais rápido e continuamente, ao mesmo tempo em que reduz continuamente os erros e problemas de desempenho. Isso é feito por meio de feedbacks frequentes para desenvolvedores, agilistas e gerentes de projeto sobre a qualidade e o desempenho da nova versão por slack ou e-mail, ou mesmo criando tickets em ferramentas de ITSM. Normalmente, os sistemas de feedback fazem parte de todo o processo de entrega de software; portanto, qualquer alteração na entrega é frequentemente registrada no sistema para que a equipe de entrega possa agir em seguida, e de forma integrada e coordenada com as demais equipes DevOps.