Integração contínua e entrega contínua (CI/CD) na abordagem DevOps

No último post da série sobre computação em nuvem para iniciantes, aprofundamos as questões que envolvem a segurança e criptografia na computação em nuvem. Neste post, abordaremos as boas práticas de integração entre as equipes de desenvolvimento, infraestrutura e testes, conceitos estes que compõem o chamado “pipeline DevOps”.

Integração contínua (do inglês Continuous Integration, sigla CI) é uma prática de desenvolvimento de software onde os programadores integram o código criado por eles várias vezes ao dia a partir de um repositório compartilhado. Proposto pela primeira vez em 1991 por um engenheiro de software americano chamado Grady Booch, o termo “Continuous Integration” prevê a integração de código a partir de testes automatizados e verificações de build. O teste automatizado não é parte obrigatória da CI, porém geralmente seu uso é implícito e muito recomendado.

A prática de integração contínua de código para desenvolvimento de software em um contexto Agile é importante porque melhora a qualidade, reduz o risco de bugs e estabelece um ritmo de desenvolvimento acelerado, confiável e sustentável. Digamos que, com a CI, o “sistema sempre funciona”, o que significa dizer que é possível implementá-lo mesmo durante o desenvolvimento.

Também é importante mencionar que a integração contínua abraça a cultura DevOps, a partir de um conjunto de princípios e práticas operacionais que permitem que as equipes de desenvolvimento de aplicativos executem alterações de código com mais frequência e confiabilidade. 

Há um consenso na indústria quanto a 4 indicadores que fazem realmente a diferença para analisar a maturidade do processo de desenvolvimento de Produtos Digitais:

  • Frequência de Implantação/Deployment: frequência com que o Produto/Aplicação é atualizado no ambiente de Produção, para o cliente final
  • Taxa de Falhas em Mudanças: percentual de mudanças implantadas em Produção que precisam ser revertidas ou corrigidas emergencialmente (hotfix)
  • Tempo de Espera Médio: tempo médio que cada nova versão da aplicação demora entre o time concluir o desenvolvimento e a aplicação ser disponibilizada para o cliente final em Produção;
  • Tempo Médio de Recuperação: calculado somando todo os períodos de indisponibilidade dentro de uma janela de tempo e dividindo este somatório pelo número de incidentes ocorridos dentro da janela

Estes quatro indicadores têm forte correlação com a maturidade do processo de Integração Contínua. Medi-los e aprimorá-los ajudará a refinar o Produto Digital em aspectos críticos de qualidade, segurança e confiabilidade.

A implementação também é conhecida como pipeline CI/CD, e nos introduz o próximo assunto relacionado: a Entrega Contínua (CD).

Continuous Delivery (CD)


Entrega contínua (do inglês Continuous Delivery, sigla CD) é uma abordagem de desenvolvimento onde as equipes produzem software em ciclos curtos, garantindo que o mesmo seja lançado de forma confiável, manualmente, a qualquer momento. Note que a palavra “manualmente” não foi destacada por acaso. Na entrega contínua, o envio frequente de código para um determinado ambiente (como teste ou produção) é feito por meio de liberação manual, e tem como objetivo construir, testar e entregar software com maior velocidade e frequência. A abordagem ajuda a reduzir o custo, o tempo e o risco de entrega das alterações durante o desenvolvimento, ao possibilitar atualizações incrementais para aplicativos ainda em produção.

Aqui vem um ponto importante: não confundir os conceitos de entrega contínua (Continuous Delivery) e implantação contínua (Continuous Deployment): enquanto na entrega contínua a liberação de código é manual, na implantação contínua essa liberação de código é automatizada, e para um ambiente de produção – ou seja, fica disponível em tempo real para seus usuários. Portanto, eles são conceitos semelhantes, mas é importante compreender que são bem diferentes na abordagem. A grosso modo, o Continuous Deployment pode ser naturalmente associado à abordagem DevOps de desenvolvimento de software, a mais “madura” de todas, sendo Continuous Delivery x Continuous Integration partes do processo para se chegar lá de forma contínua e bem sucedida.

Fonte: linuxnix.com



O conceito de entrega contínua é importante para o movimento Agile porque ser capaz de liberar o código de desenvolvimento a qualquer momento significa poder fechar ciclos mais rápidos de feedback. Por exemplo, se um software possui boas métricas embutidas (dica: ele precisa ter), será capaz de obter informações de seus clientes rapidamente a respeito do que mais valorizam no software desenvolvido. A combinação das práticas de Integração Contínua e Entrega Contínua (CI/CD) acaba por criar um processo rápido e eficaz para colocar um produto no mercado antes mesmo da concorrência, além do lançamento de novos recursos e correções de bugs para manter satisfeitos os clientes já conquistados.

A abordagem CI/CD apresenta automação contínua e monitoramento contínuo em todo o ciclo de vida dos aplicativos, desde a integração e fases de teste até a entrega e implementação. O objetivo da cultura DevOps é fundir as funções Dev (desenvolvedor) e Ops (operacional), bem como os processos que gerenciam, para alcançar metas de negócios de forma mais rápida, automatizada e fluida; no entanto, é frequentemente confundida com a abordagem de Entrega Contínua. Em vez disso, como destaca um analista da Gartner, “DevOps não é um mercado, mas uma filosofia centrada em ferramentas que oferecem suporte a uma cadeia de valor de entrega contínua”.

Ou seja, é como se a entrega contínua estivesse contida na cultura DevOps e não o contrário. Tudo isso é impulsionado por estratégias de negócios digitais que estimulam a demanda por maior velocidade e eficácia na entrega de software. No entanto, ambas as metodologias também compartilham características em comum, como Agile e Lean Thinking para entregar pequenas e rápidas mudanças em colaboração com as equipes de TI.

Implantação Contínua (CD)

Enquanto na Entrega Contínua, como vimos acima, a implementação segue um modelo manual conforme a demanda, na Implementação Contínua (Continuous Deployment) a implementação é feita automaticamente todas as vezes. Implantação contínua significa que cada alteração de código feita pelo desenvolvedor passa por um pipeline e, se passar em todos os testes, é automaticamente implementado em produção, executando portanto alterações que acabam visíveis a todos os usuários do software. É por essa razão que o Continuous Deployment só pode funcionar em equipes DevOps altamente maduras, pois a qualidade do lançamento do produto final depende completamente da qualidade do conjunto de testes – criado pelas equipes DevOps – já que tudo é automatizado.

Antes de iniciar uma abordagem de Implantação Contínua, com alterações enviadas automaticamente em produção, primeiro é recomendável começar e fomentar uma boa cultura de Integração Contínua (CI) entre as equipes de desenvolvimento, combinada com práticas de Entrega Contínua (CD), conforme descritas acima. Ou seja, você já deve ter notado que tudo está relacionado aqui: Integração Contínua x Entrega Contínua x Implantação Contínua.

Se estiver em busca de ferramentas de implantação contínua (Continuous Deployment) e por acaso acabou caindo neste post, destacamos as mais populares no momento: AWS CodeDeploy, Octopus Deploy, Jenkins, Github, GitLab e CircleCI. Alguns dos benefícios da abordagem de implantação contínua no desenvolvimento de aplicativos incluem versões menores e, portanto, mais fáceis de entender. Como tudo é automatizado, ninguém precisa se preocupar em fazer uma implementação. Como os novos recursos e melhorias vão direto para a produção quando estão prontos, o ciclo de feedback com os clientes é muito mais rápido.


Gostou do post? Assine a nossa newsletter e receba as atualizações do blog! No próximo post da série sobre Cloud para Iniciantes abordaremos os conceitos relacionados aos testes A/B, Canary Releases e o Projeto Kayenta do Netflix. 

Um comentário em “Integração contínua e entrega contínua (CI/CD) na abordagem DevOps

Deixe uma resposta