Integração contínua, entrega contínua ou deployment contínuo? Há sempre um grande mal entendido em relação a esses termos! Vamos esclarecê-los em apenas cinco minutos.

Integração contínua

A Integração Contínua (Continuous Integration – CI) é uma prática de desenvolvimento da Extreme Programming que exige que os desenvolvedores integrem o código em uma mainline o mais frequentemente possível, pelo menos uma vez por dia, e cada check-in é verificado por uma build automática que compila o código e roda o conjunto de testes automatizados contra ele, permitindo que os times detectem problemas com antecedência.

No contexto Git, a mainline geralmente se torna o branch mestre, e cada check-in é um novo commit que emerge no repositório remoto.

Implementar integração contínua oferece vários benefícios:

• Fundir o inferno, isto é, conflitos intermináveis de mesclagem enquanto se funde o código na mainline, é evitado porque o código deve ser integrado ao mainline o mais frequentemente possível (pelo menos uma vez por dia).
• Permite detectar erros rapidamente à medida que testes automáticos são executados em cada commit que faz check-in no repositório remoto. Assim, menos bugs são enviados para a produção.
• Quando um erro é detectado, é muito mais fácil corrigir porque a quantidade de código envolvida em cada commit é muito menor.
• Promove a comunicação humana anteriormente quando ocorrem conflitos de mesclagem. As pessoas podem se sentar e entender como seus códigos estão realmente influenciando o código umas das outras.
• Construir o release é fácil, pois todos os problemas de integração foram solucionados antecipadamente.

No entanto, tudo tem um preço. Para implementar a integração contínua, a equipe de desenvolvimento deve entender que:

• As tarefas devem ser divididas o máximo possível na fase de planejamento, porque o código deve ser desenvolvido (incluindo testes automatizados) e integrado na mainline o mais rápido possível, pelo menos uma vez por dia.
• Testes automatizados devem estar presentes para cada novo recurso, melhoria ou correção de bugs. Eles garantirão que uma mudança – mesmo que pequena – não quebre qualquer outra parte do sistema.

A segunda parte da definição afirma que “cada check-in é verificado por uma build automatizada que compila o código e executa o conjunto de testes automatizados”. Para executar testes automatizados em cada commit que emerge na mainline do repositório remoto, a equipe precisará configurar um servidor de integração contínua. O objetivo essencial do servidor CI é executar testes automatizados em cada novo commit que emerge na mainline do repositório remoto, mas na verdade, ele é capaz de fazer muito mais do que isso, como emitir notificações personalizadas quando um teste ou build falhar, desencadeando geração de releases, desencadeando deployments em ambientes específicos, e assim por diante. Um conhecido servidor CI é o Jenkins, um servidor CI open source líder, escrito em Java, que fornece centenas de plugins para apoiar a construção, o deploying e a automação de qualquer projeto.

Um fluxo contínuo de integração contínua assegurará que a mainline esteja sempre em um estado deployable. Integração contínua e outras práticas da Extreme Programming, como Automated Tests, Pair Programming, Test Driven Development, Refactoring e Simple Design, contribuem grandemente para a qualidade de um código de aplicação. Se a sua equipe não se preocupa com essas técnicas (e outras), é muito provável que você não consiga garantir que o código realmente funcione como pretendido. Então, como você poderia ter um fluxo de deployment automatizado se você não tem ideia se o código que está sendo entregue funciona ou não? Essa é a razão pela qual a integração contínua é um requisito para a implementação de entrega contínua e deployment contínuo.

Entrega contínua

Eu realmente gosto da definição de entrega contínua de Jezz Humble:

Entrega contínua é a capacidade de obter mudanças de todos os tipos; incluindo novos recursos, mudanças de configuração, correções de bugs e experiências em produção, ou nas mãos dos usuários, de forma segura, rápida e sustentável.

Em outras palavras, quando sua equipe realmente implementa a entrega contínua, o que isso realmente significa é que o mainline está sempre em um estado deployable, e pode-se decidir fazer deploy dele na produção a qualquer momento com o toque de um botão. Isso, por sua vez, só é possível porque, quando esse botão é tocado, um pipeline automatizado (um conjunto de etapas automatizadas que o código muda até ser finalmente implementado na produção) é desencadeado. O elemento chave para alcançar a entrega contínua é a automação!

Bem, se você pode fazer deploy na produção a qualquer momento, a questão é: quando é o momento certo? Claro, a resposta pode variar dependendo dos requisitos da sua empresa, mas a verdade é que, se você deseja obter os benefícios da entrega contínua, você deve fazer o deploy na produção o mais cedo possível para garantir que você libere lotes pequenos nos quais é fácil solucionar problemas, caso eles ocorram.

Deployment contínuo

O deployment contínuo é muito semelhante à entrega contínua, mas dá um passo adiante em relação à automação. Na entrega contínua, todas as mudanças levadas para o repositório principal estão prontas para deploy em produção, mas o início desse processo ainda requer interação humana. No deployment contínuo, o deployment para a produção é ativado automaticamente para cada alteração que passa no conjunto de testes.

Como na implantação contínua, todas as mudanças que passam no conjunto de testes são colocadas em deploy para produção, ela depende fortemente das Feature Flags para liberar recursos para usuários finais.  

Este artigo foi baseado no conteúdo do meu livro Continuous Delivery for Java Apps: Build a CD Pipeline Step by Step Using Kubernetes, Docker, Vagrant, Jenkins, Spring, Maven, and Artifactory. Clique no link e faça o download da amostra gratuita do livro (110 páginas gratuitas!) para saber mais sobre Agile, Entrega Contínua, Scrum, Testes Automatizados (unidade, integração, aceitação e testes de desempenho), Feature Branch, Feature Flags, Testes A/B, Canary Releases, Apache Maven, Artifactory, Docker, Kubernetes e muito mais!  

Esse livro irá guiá-lo através da implementação da entrega contínua do mundo real usando tecnologias de alto nível que estão em alta demanda pelas melhores empresas de todo o mundo. Em vez de terminar o livro pensando “eu sei o que é a entrega contínua, mas não tenho ideia de como implementá-la”, você acabará com a sua máquina configurada com um cluster Kubernetes que executa o Jenkins Pipelines de forma distribuída e escalável (cada pipeline executado em um novo slave Jenkins alocado dinamicamente como um pod Kubernetes) para testar (unidade, integração, aceitação, desempenho e smoke tests), construir (com Maven), lançar (para Artifactory), distribuir (para Docker Hub) e deploy (em Kubernetes) um aplicativo Spring Boot para ambientes de teste, encenação e produção implementando o padrão de deploy Canary Release para mitigar riscos.

Esse é o livro que eu gostaria de ter encontrado quando eu estava aprendendo sobre entrega contínua; é por isso que o escrevi. Isso lhe dará anos de experiência na implementação de entrega contínua em vários projetos diferentes.

***

Jorge Acetozi faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://www.linkedin.com/pulse/continuous-integration-vs-delivery-deployment-jorge-acetozi/