O padrão mais importante da entrega contínua é o chamado pipeline de implantação que segundo Humble e Farley (2014) é “uma manifestação automatizada do processo de levar o software do controle de versão até os usuários”. Ele tem como base o processo de integração contínua, “e é essencialmente o princípio de integração contínua levado à sua conclusão lógica” (HUMBLE; FARLEY, 2014).
O pipeline de implantação é uma implementação de ponta a ponta da automatização do processo de compilação, testes e implantação, que permite às equipes de teste e operação implantar a aplicação em ambientes de teste, de homologação e de produção com o apertar de um botão. Aos desenvolvedores, é permitida a visualização dos estágios do processo de entrega alcançados por cada versão do software e dos problemas encontrados em cada uma delas. Além disso, proporciona ao gerente a verificação e monitoração de métricas fundamentais como tempo de ciclo, taxa de transferência e qualidade de acesso, permitindo a visibilidade sobre o processo de entrega que torna possível a identificação, otimização e remoção de gargalos (ALMEIDA, 2014).
Assim, através do pipeline de implantação consegue-se um processo de entrega contínua mais rápido e mais seguro (HUMBLE; FARLEY, 2014 apud ALMEIDA, 2014).
De acordo com Humble e Farley (2014), o pipeline de implantação possui três objetivos:
Em primeiro lugar, ela torna cada parte do processo de compilação, implantação, teste e entrega de versão visível a todos os envolvidos, promovendo a colaboração. Em segundo, melhora o feedback do processo, de modo que os problemas são identificados resolvidos o mais cedo possível. Finalmente, permite que equipes entreguem e implantem qualquer versão de seu software para qualquer ambiente a qualquer momento por meio de um processo automatizado (HUMBLE; FARLEY,2014).
Para a obtenção de bons resultados, o pipeline de implantação requer que alguns princípios sejam seguidos. Humble e Farley (2014) afirmam que as práticas são compilar apenas uma vez o código; fazer implantação da mesma maneira para cada ambiente; usar smoke tests; implantar em uma cópia do ambiente de produção; e que cada mudança deve ser propagada instantaneamente.

A Figura acima representa um pipeline de implantação básico. Humble e Farley (2014) explicam que o processo começa no momento que o desenvolvedor faz um novo check-in no sistema. O sistema de integração contínua responde criando uma nova instância do pipeline. Assim, no primeiro estágio, conhecido como estágio de commit, tem-se a compilação do código, execução dos testes unitários, realização de análise do código e criação dos instaladores. Sendo bem-sucedido, ele é compilado em binários e armazenados em um repositório de artefatos.
Testes de aceitação automatizados compõem o segundo estágio, no qual demora-se mais para ser executado. O segundo estágio inicia-se automaticamente quando o primeiro é realizado com sucesso.
A partir daí, o pipeline pode ser dividido em implantações automáticas do código em vários ambientes – UAT – Testes de Aceitação do Usuário, testes de capacidade e produção.
Diferentemente da transição automática do estágio um para o dois, nesta etapa, sugere-se que o desenvolvedor faça isso manualmente.
Através do sistema de integração contínua, é possível realizar a implantação no ambiente correto, tornando possível a visualização de todas as versões candidatas disponíveis e suas situações, permitindo também que uma versão anterior seja implantada.
No próximo post, será detalhado o pipeline de implantação apresentando ferramentas que atendam ao que é proposto. Acesse aqui.