DevOps – Pipeline de implantação, CI (Continuous Integration) e CD (Continuous Delivery)

Em geral, o processo organizacional para lançamento de um produto (ou nova funcionalidade) no mercado segue as seguintes etapas:

  1. Visão do produto: definição das funcionalidades do produto
  2. Time de Dev: realiza o desenvolvimento de forma iterativa e incremental; uma nova versão a cada iteração
  3. Área de operação: implementa e mantém os ambientes estáveis
  4. Monitoramento e retorno: geração do valor e uso pelo cliente

O Fluxo de valor, desde a concepção do produto até a geração de valor, analisa o caminho completo de criação de valor e compreende o valor exato adicionado em cada parte. Em métodos ágeis, não há prescrição dos aspectos da entrega, e por isso, a última milha é regida por boas práticas para cobrir todo o processo da implantação.

O feedback vai guiando a estratégia da empresa, eliminando barreiras entre os departamentos e permitindo a colaboração entre as pessoas para gerar valor ao cliente.

pipeline-implantacao

Um pipeline de implantação é uma manifestação automatizada do seu processo para levar o software do controle de versão para as mãos de seus usuários. Todo o processo – do conceito ao dinheiro – pode ser modelado como um mapa de fluxo de valor. Envolve os processos de

  • Integração Contínua
  • Entrega Contínua
  • Implantação Contínua

CI-CD

Criando um pipeline de implementação (imagem abaixo no Azure DevOps):

  1. Modelar o fluxo de valor, criando um esqueleto do processo
  2. Automatizar os processos de compilação e testes
  3. Automatizar os processos de implantação
  4. Implantar a estratégia de entrega de versão

pipeline-implantacao-azure-devops.png

  • Envolver qualidade e segurança da informação desde o início
  • Estratégia de testes, considerando teste unitário, integração, segurança, TDD/BDD/ATDD, infraestrutura e performance
  • Telemetria eficiente na coleta e monitoramento das informações

CI (Continuous Integration)

São práticas que encorajam os desenvolvedores a integrar o seu trabalho continuamente – um novo código fonte (branch ou trunk) ao principal (main). Permite ajustes frequentes nos códigos, entregas rápidas e com menos bug. Há três coisas que você precisa estar ciente antes de CI:

  1. Controle de versão
  2. Build automatizado
  3. Acordo do time

Alguns pré-requisitos da CI:

  • Check in frequente
  • Suíte de testes abrangente
  • Manter o processo de Build e Teste curto
  • Gerenciando seu workspace de desenvolvimento

CI é uma prática, não uma ferramenta, e por isso, depende da disciplina para torna-la efetiva. Algumas práticas recomendadas para as equipes:

  • Builds devem passar no coffee test (menos de 5 minutos)
  • Não fazer check in de build com falha
  • Sempre execute todos os testes de confirmação antes do commit
  • Não vá embora com um build quebrado
  • Esteja sempre preparado para reverter a revisão anterior
  • Defina um time box antes de reverter (por exemplo: 10 minutos se não obtiver a solução, reverter a revisão anterior)
  • Test-Driven Development

Jez Humble: “The goal of continuous integration is that software is in a working state all the time”.

Continuous Delivery

É uma extensão do CI para garantir que novas modificações estejam disponíveis para serem implementadas no ambiente de produção.  Os testes e o processo de liberação são automatizados e contribuem com o controle de qualidade para prover feedbacks rápidos aos desenvolvedores.

O deploy para produção não é automático, porém pode ser realizado a qualquer momento, dependendo do aceite da alteração (com o clique de um botão).

Boas práticas:

  • Build somente uma vez o artefato (rebuild – passará novamente por todos os ambientes; quebrará sua auditoria)
  • Artefatos devem ser imutáveis (armazenados com restrição de permissão). Manter os acessos de deployers somente onde deve ter acesso
  • Duas boas razões para ser imutáveis: a) cria confiança entre o time b) ser rastreável (poder verificar versões específicas, etc.)
  • Deployment deve ir para uma cópia de produção; pare o deploy se uma etapa anterior falhar
  • Deployments devem ser idempotente

Métricas do seu pipeline:

  • Você é capaz de auditar uma simples mudança?
  • Quão rápido você pode mover uma mudança para produção?
    (overall cycle time)
  • Cycle time = do check-in até produção

Continuous Deployment

Processo sem intervenção humana, realizando todas as validações anteriores para disponibilizar a nova modificação em produção automaticamente. Somente uma falha encontrada nos testes impede a implementação em produção.

Neste processo é muito importante validar com a área de segurança da informação e compliance da sua empresa a aplicabilidade deste processo. Em operações críticas que trabalham com deploys contínuos (dezenas, centenas ou milhares por dia), torna-se inviável gerenciar este processo sem ter a implantação do Continuous Deployment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s