Antecipando o início do curso "CI / CD em AWS, Azure e Gitlab" preparamos uma tradução de material útil para você.
Integração Contínua (CI) e Entrega Contínua (CD) são uma cultura, um conjunto de princípios e práticas que permitem aos desenvolvedores implantar mudanças de software com mais frequência e mais confiabilidade.
CI / CD é uma das práticas DevOps . Também se aplica a práticas ágeis : a automação da implantação permite que os desenvolvedores se concentrem em atender aos requisitos de negócios, qualidade de código e segurança.
Definição de CI / CD
Integração contínua é uma metodologia de desenvolvimento e um conjunto de práticas nas quais pequenas mudanças são feitas no código com commits frequentes. E uma vez que a maioria dos aplicativos modernos são desenvolvidos usando várias plataformas e ferramentas, é necessário um mecanismo de integração e teste das mudanças introduzidas.
Tecnicamente falando, o objetivo da CI é fornecer uma maneira consistente e automatizada de construir, empacotar e testar aplicativos. Com um processo simplificado de integração contínua, os desenvolvedores estão mais propensos a fazer commits frequentes, o que por sua vez ajudará a melhorar a comunicação e a qualidade do software.
A entrega contínua começa onde a integração contínua termina. Ele automatiza a implantação de aplicativos em ambientes diferentes: a maioria dos desenvolvedores trabalha com ambientes de produção e ambientes de desenvolvimento e teste.
As ferramentas CI / CD ajudam a personalizar configurações de ambiente específicas que são definidas durante a implantação. E também a automação de CI / CD realiza as solicitações necessárias para servidores web, bancos de dados e outros serviços que podem precisar ser reiniciados ou realizar algumas ações adicionais ao implantar o aplicativo.
A integração e entrega contínuas precisam de testes contínuosporque o objetivo final é desenvolver aplicativos de qualidade. O teste contínuo geralmente é implementado como um conjunto de vários testes automatizados (regressão, desempenho e outros) que são executados no pipeline de CI / CD.
A prática madura de CI / CD permite a implantação contínua: quando o código passa com sucesso pelo pipeline de CI / CD, os assemblies são implantados automaticamente no ambiente de produção. As equipes que praticam a entrega contínua podem pagar a implantação diária ou mesmo por hora. É importante notar aqui, porém, que a entrega contínua não é adequada para todos os aplicativos de negócios .
A integração contínua melhora a comunicação e a qualidade
A Integração Contínua é uma metodologia de desenvolvimento baseada em processos regulados e automação. Com a integração contínua implementada, os desenvolvedores costumam enviar seu código para o repositório de código-fonte. E a maioria das equipes segue a regra de se comprometer pelo menos uma vez por dia. Pequenas mudanças são mais fáceis de detectar defeitos e vários problemas do que grandes mudanças que foram trabalhadas por um longo período de tempo. Além disso, trabalhar com ciclos de confirmação curtos reduz a probabilidade de vários desenvolvedores alterarem a mesma parte do código, o que pode levar a conflitos de mesclagem.
As equipes que implementam a integração contínua geralmente começam configurando um sistema de controle de versão e definindo um fluxo de trabalho. Apesar do fato de que os commits são feitos com frequência, implementar recursos e corrigir bugs pode levar muito tempo. Existem várias abordagens para controlar quais recursos e códigos estão prontos.
Muitas pessoas usam sinalizadores de recursos - um mecanismo para ativar e desativar a funcionalidade em tempo de execução. A funcionalidade que ainda está em desenvolvimento é envolvida em sinalizadores de recursos e implantada do branch master para a produção, mas é desabilitada até que esteja totalmente pronta para uso. De acordo com um estudo recente63 por cento das equipes que usam o recurso de sinalização relatam testabilidade aprimorada e qualidade de software aprimorada. Existem ferramentas especiais para trabalhar com sinalizadores de recursos, como CloudBees Rollout , Optimizely Rollouts e LaunchDarkly , que se integram ao CI / CD e permitem a configuração no nível do recurso.
Outra maneira de trabalhar com recursos é usando ramificações no sistema de controle de versão. Nesse caso, você precisa definir um modelo de ramificação (por exemplo, como Gitflow) e descrever como o código entra nas ramificações de desenvolvimento, teste e produção. Para recursos com um longo ciclo de desenvolvimento, ramificações de recursos separadas são criadas. Depois de concluir o trabalho em um recurso, os desenvolvedores mesclam as alterações do branch de recurso no branch de desenvolvimento principal. Essa abordagem funciona bem, mas pode ser inconveniente se muitos recursos estiverem sendo desenvolvidos ao mesmo tempo.
A fase de construção visa automatizar o empacotamento do software, banco de dados e outros componentes necessários. Por exemplo, se você estiver desenvolvendo um aplicativo Java, o CI empacotará todos os arquivos estáticos, como HTML, CSS e JavaScript, junto com o aplicativo Java e os scripts de banco de dados.
O CI não apenas empacotará todos os componentes de software e bancos de dados, mas também executará testes de unidade e outros tipos de teste automaticamente. Esse teste permite que os desenvolvedores obtenham feedback de que as alterações feitas por eles não prejudicaram nada.
A maioria das ferramentas de CI / CD permite que você inicie um build manualmente, em um commit ou em uma programação. As equipes precisam discutir um cronograma de construção que se adapte a elas com base no tamanho da equipe, confirmações diárias esperadas e outros critérios. É importante que os commits e builds sejam rápidos, caso contrário, builds longos podem se tornar um obstáculo para desenvolvedores que tentam se comprometer com rapidez e frequência.
O teste contínuo é mais do que automação de teste
Estruturas de teste automatizadas ajudam os engenheiros de controle de qualidade a projetar, executar e automatizar vários tipos de testes que ajudam os desenvolvedores a rastrear o sucesso de construção. O teste inclui testes funcionais que são desenvolvidos no final de cada sprint e combinados em testes de regressão para todo o aplicativo. Os testes de regressão informam a equipe se suas alterações quebraram algo em outra parte do aplicativo.
A prática recomendada é exigir que os desenvolvedores executem todos ou parte dos testes de regressão em seu ambiente local. Isso garantirá que os desenvolvedores confirmem o código já verificado.
Os testes de regressão são apenas o começo. Teste de desempenho, teste de API, análise de código estático, teste de segurança - esses e outros tipos de teste também podem ser automatizados. O ponto principal é a capacidade de executar esses testes na linha de comando, por meio de um webhook ou por meio de um serviço da web e retornar o resultado da execução: o teste foi bem-sucedido ou não.
O teste contínuo envolve não apenas automação, mas também a integração de testes automatizados no pipeline de CI / CD. Testes de unidade e funcionais podem fazer parte do CI e identificar problemas antes ou durante o lançamento do pipeline de CI. Testes que requerem implantação de ambiente completo, como teste de desempenho e segurança, geralmente fazem parte do CD e são executados após as compilações terem sido implantadas nos ambientes de destino.
O pipeline de CD automatiza a entrega de mudanças em diferentes ambientes
A entrega contínua é a implantação automática de um aplicativo em seu ambiente de destino. Normalmente, os desenvolvedores trabalham com um ou mais ambientes de desenvolvimento e teste onde um aplicativo é implementado para teste e revisão. Para isso, são utilizadas ferramentas de CI / CD como Jenkins , CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI.
Um pipeline de CD típico consiste em etapas de construção, teste e implantação. Pipelines mais complexos incluem as seguintes etapas:
- Recuperando código do controle de origem e executando uma compilação.
- Configuração de infraestrutura automatizada por meio de uma abordagem de infraestrutura como código.
- Copiar o código para o ambiente de destino.
- Configurando variáveis de ambiente para o ambiente de destino.
- (-, API-, ).
- , , .
- .
- .
Por exemplo, no Jenkins transportador determinado arquivo Jenkinsfile, que descreve as várias etapas como montagem (construção), teste (teste) e implantação (implantação). Ele também descreve variáveis de ambiente, chaves secretas, certificados e outros parâmetros que podem ser usados em estágios de pipeline. A seção de postagem configura o tratamento de erros e notificações.
Em um pipeline de CD mais complexo, pode haver etapas adicionais, como sincronização de dados, arquivamento de recursos de informações, instalação de atualizações e patches. As ferramentas CI / CD geralmente suportam plug-ins. Por exemplo, Jenkins tem mais de 1.500 plug-ins para integração com plataformas de terceiros, para estender a interface do usuário, administração, gerenciamento de código-fonte e construção.
Ao usar uma ferramenta de CI / CD, os desenvolvedores devem garantir que todos os parâmetros sejam configurados fora do aplicativo por meio de variáveis de ambiente. As ferramentas CI / CD permitem definir os valores dessas variáveis, mascarar senhas e chaves de conta e personalizá-las durante a implantação para um ambiente específico.
Também nas ferramentas do CD, há painéis e relatórios. No caso de uma falha de construção ou entrega, eles notificam sobre isso. Integrando o CD com controle de versão e ferramentas ágeis, é mais fácil encontrar alterações de código e histórias de usuário incluídas na construção.
Implementar pipelines de CI / CD com arquiteturas Kubernetes e sem servidor
Muitas equipes que usam pipelines de CI / CD nas nuvens usam contêineres como Docker e sistemas de orquestração como Kubernetes . Os contêineres ajudam a padronizar o empacotamento, a entrega e a simplificar o dimensionamento e a destruição de ambientes não persistentes.
Existem muitas opções para compartilhar containers, infraestrutura como código e pipelines CI / CD. Você pode aprender mais sobre isso nos artigos Kubernetes com Jenkins e Kubernetes com Azure DevOps .
A computação sem servidor é outra maneira de implantar e dimensionar aplicativos. Em um ambiente sem servidor, a infraestrutura é totalmente gerenciada pelo provedor de nuvem e o aplicativo consome recursos conforme necessário de acordo com suas configurações. Por exemplo, na AWS, os aplicativos sem servidor são executados por meio de funções do AWS Lambda , cuja implantação pode ser integrada ao pipeline de CI / CD do Jenkins usando um plug-in.
CI / CD permite implantação de código mais frequente
Então, vamos resumir. Pacotes de CI, compilações de testes e notificam os desenvolvedores se algo der errado. O CD implanta aplicativos automaticamente e executa testes adicionais.
Os pipelines de CI / CD são projetados para organizações que precisam fazer mudanças frequentes em aplicativos com um processo de entrega confiável. Além de padronizar compilações, desenvolver testes e automatizar implantações, obtemos um fluxo de trabalho holístico para implantar mudanças de código. A implementação de CI / CD permite que os desenvolvedores se concentrem em melhorar seus aplicativos e não perder tempo implantando-os.
CI / CD é uma das práticas DevOpsporque visa combater as contradições entre os desenvolvedores que desejam fazer alterações frequentes e a exploração, que exige estabilidade. Com a automação, os desenvolvedores podem fazer alterações com mais frequência, e as equipes de operação, por sua vez, ganham mais estabilidade, uma vez que a configuração dos ambientes é padronizada e testes contínuos são realizados durante o processo de entrega. Além disso, a configuração de variáveis de ambiente é separada do aplicativo e existem procedimentos de reversão automatizados.
O impacto da implementação de pipelines CI / CD pode ser medido em termos de DevOps Key Performance Indicators (KPIs)... KPIs como frequência de implantação, tempo médio de recuperação e tempo médio de recuperação geralmente melhoram com implantações de CI / CD com testes contínuos. No entanto, CI / CD é apenas um processo que pode contribuir para essas melhorias. Existem outras condições para aumentar a frequência de entrega.
Para começar a usar CI / CD, a equipe de desenvolvimento e operações precisa colaborar em tecnologias, práticas e prioridades. As equipes precisam construir um consenso sobre as abordagens corretas para seus negócios e tecnologia para que, após a implementação de CI / CD, a equipe siga consistentemente as práticas escolhidas.
Resumo das ferramentas CICD: Gitlab CI, Docker, Ansible