Em tempos de DevOps, os termos que mais escutamos hoje em dia são:

  • Continuous Integration (Integração contínua)
  • Continuous Delivery (Entrega contínua)
  • Continuous Deployment (Implantação / Publicação contínua)

Como todo termo da moda, é comum ouvirmos explicações distorcidas sobre o que é e para o que serve cada uma das práticas.

Costumo brincar e dizer, que se os 3 conceitos fossem a mesma coisa, não teriam nomes diferentes. Pensando nisso, e já tendo visto muitas vezes pessoas querendo dizer uma coisa, mas na prática explicar outra, resolvi escrever para tentar dar uma visão macro e simples da diferença entre cada um dos termos.

O primeiro erro básico para fazer qualquer uma dessas coisas funcionar, ou melhor, para fazer qualquer coisa funcionar, é ter o real entendimento do que é e para o que serve. E isso implica em gastar um bom tempo estudando e buscando diversas fontes de pesquisa, até confirmar o seu entendimento. Talvez você até já tenha uma das 3 práticas em funcionamento no seu processo, e talvez nem imagine, pois não tem muito claro o entendimento sobre o que é cada termo.

Hoje, o que mais vejo são pessoas usando um dos termos para tentar dizer que quer todos eles juntos em funcionamento. Neste caso teríamos que criar um novo termo, talvez o "Continuous Everything" ou "Whole Automated Continuous Process".

Talvez, este novo termo seja o objetivo que muitos buscam chegar, afinal é o ápice do processo, mas é importante entender que é possível chegar no tal Continuous Everything implementando Continuous Integration, Continuous Delivery e Continuous Deployment de forma faseada e planejada.

Bom, vamos lá detalhar o que é cada um dos processos. Tentarei ser objetivo e simples na explicação.

Continuous Integration (Integração contínua)

Uma confusão frequente é equiparar a entrega contínua e a integração contínua. Esta visão é um grande equívoco. A integração contínua é a prática de integração e testes de um novo código com a base de código existente, e é uma condição necessária para que o processo de entrega contínua possa acontecer da forma correta.

É o processo de merging do seu novo código com uma brench / trunk. A idéia aqui é testar seu código o mais rápido possível para identificar os problemas mais cedo.

A maioria do trabalho é feito por meio de testes automatizados, e esta técnica requer um framework de testes unitários (Unit Tests). Normalmente há um servidor de compilação para realização destes testes, para que os desenvolvedores possam continuar o trabalho enquanto os testes estão sendo realizados.

Continuous Delivery (Entrega contínua)

Aqui é onde aparece a maior confusão. As pessoas às vezes usam os termos de entrega contínua e implantação contínua alternadamente. As duas práticas não são a mesma coisa. A Entrega Contínua é um conjunto de práticas que tem como objetivo garantir que o novo código pode ser implantado no ambiente de produção a qualquer momento, já a implantação contínua leva um passo mais longe.

Na prática de entrega contínua tratamos do envio do código para um ambiente, que pode ser DEV, STAGE ou PROD, uma vez que o desenvolvedor sente o código está pronto para enviar. Mas nesta parte do processo a idéia é de que se está entregando o código para uma base de usuários, entenda-se por base de usuários, Testers / QA, clientes homologar ou até usuários finais. Isto é semelhante ao de integração contínua, mas neste momento podemos incrementar o processo de teste com os testes de comportamento (Behavior Tests – BDD) para testar a lógica de negócio ou até mesmo testes visuais.

Quer dizer que após esta entrega para os primeiros usuários significa que deverá ir para produção ou mesmo stage? Não! Quer dizer que você está entregando para esta primeira base de usuários e ponto. Isso pode apenas significar que a entrega está sendo feita para Code Review.

Continuous Deployment (Implantação contínua)

Afinal, qual é o ponto mais longe que o Continuous Deployment aborda e que o faz tão diferente da prática de delivery? Esta parte do processo aborda a questão de automatização do processo de publicação no ambiente de produção, tão logo você esteja certo de que o código passou por todos os testes e está pronto para ser publicado. A idéia é entregar valor de negócio o mais rápido possível e não acumular código novo em stage. Ou seja, se o código passou pelo processo de integração que é responsável por testes de integração ou testes unitários, e também foi avançando no processo de delivery com testes manuais, visuais e de comportamento, então entra a fase de deployment que é responsável por publicar o código em produção de forma automatizada.

Nesta fase do processo assume-se que todos os testes foram feitos, e apenas será tratada a questão de publicação automatizada no ambiente de produção.

Parte-se do princípio de que o ambiente de produção é estável, de que tudo foi testado e que este processo deverá ser simples como apertar um botão e que deverá ser possível de ser feito por qualquer pessoa.

Ou seja, para Continuous Deployment, você necessariamente precisa ter Continuous Integration e Continuous Delivery funcionando como parte da sua rotina.

O processo termina aí? Pode terminar ou não, pois você ainda pode usar seu processo de integração e delivery para validar o que foi publicado em produção.

A imagem abaixo ajuda a visualizar melhor:

entrega-continua-vs-deploy-continuo

Note que na parte de cima é possível ver que o deploy em produção é feito de forma manual.

A explicação que fiz é uma visão bem macro. Existem muitos aspectos específicos de cada uma das práticas.

Pesquei uma conversa de Twitter que ilustra, na minha opinião, muito bem esta confusão:

o-que-e-continuous-delivery

Todo este processo é a conseqüência natural do movimento Agile. A cultura ágil procura corrigir os problema dos atrasos, excesso de funcionalidades, entrega real de valor de negócio e versões de software com bugs, promovendo
interações e mudanças incrementais ao código, e a colaboração entre as equipes, que neste caso visa unir o time de desenvolvimento e o time de intra-estrutura e segurança. O Agile inclui ainda a capacidade de adaptação rápida à mudança e menor risco para o negócio. Ou seja, este processo é tão ágil, como um processo ágil deve ser!

Lendo este meu último parágrafo acredito o nome do processo completo pudesse ser Continuous Agile. 🙂

Valores do Manifesto Ágil

Espero ter conseguido ser claro e ter ajudado a dismistificar o que significa cada uma das práticas. Leia mais sobre Devops.