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.

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

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

• 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.