Integração contínua vs. entrega contínua vs. implementação contínua

A gente vai ver neste artigo o que essas três práticas significam e o que é necessário para o uso delas.

Sten Pittet Sten Pittet

CI e CD são duas siglas frequentemente usadas em práticas de desenvolvimento moderno e DevOps. CI significa integração contínua, uma prática recomendada de DevOps fundamental onde os desenvolvedores frequentemente mesclam alterações de código em um repositório central onde compilações e testes automatizados são executados. Mas CD pode significar entrega contínua ou implementação contínua.

Quais são as diferenças entre integração contínua, implementação contínua e entrega contínua?

Integração contínua

Desenvolvedores praticando integração contínua mesclam suas alterações de volta à ramificação principal assim que possível. As alterações do desenvolvedor são validadas criando um build e executando testes automatizados com relação ao build. Assim, você evita o inferno de integração que normalmente acontece quando as pessoas esperam o dia do lançamento para mesclar as alterações na ramificação de lançamento.

A integração contínua coloca uma grande ênfase na automação de testes para verificar se o aplicativo não está quebrado sempre que novos commits são integrados na ramificação principal.

Serviço constante

A entrega contínua é uma extensão da integração contínua, uma vez que implementa de modo automático todas as alterações de código em um ambiente de teste e/ou produção após o estágio de build.

Ou seja: além de testes automatizados, você tem um processo de lançamento automatizado e pode implementar seu aplicativo a qualquer momento clicando em um botão.

Em teoria, com a entrega contínua, você pode decidir lançar diariamente, semanalmente, quinzenalmente ou o que quer que se adapte às suas necessidades de negócios. No entanto, se você quer mesmo obter os benefícios da entrega contínua, você deve implementar na produção o mais cedo possível para lançar pequenos lotes em que é fácil solucionar problemas caso algum surja.

Implementação contínua

Implementação contínua vai um passo além da entrega contínua. Com essa prática, toda alteração que passa em todos os estágios do seu pipeline de produção é lançada para os clientes. Não há intervenção humana, e apenas um teste com falha vai impedir a implementação de uma nova alteração na produção.

A implementação contínua é uma excelente maneira de acelerar o ciclo de feedback com seus clientes e tirar a pressão da equipe, pois não há mais um Dia de Lançamento. Os desenvolvedores podem se concentrar na criação de software e veem seu trabalho entrar em funcionamento minutos depois de pronto.

Como as práticas se relacionam entre si

Para simplificar, integração contínua faz parte de entrega contínua e de implementação contínua. E implementação contínua é como entrega contínua, exceto que os lançamentos acontecem de modo automático.

Quais são as diferenças entre integração contínua, entrega contínua e implementação contínua? | CI/CD da Atlassian

Quais são os benefícios de cada prática?

Explicamos a diferença entre integração contínua, entrega contínua e implementação contínua, mas ainda não analisamos os motivos pelos quais você as adotaria. Há um custo óbvio para implementar cada prática, mas é amplamente superado por seus benefícios.

Prática Do que você precisa (custo) O que você ganha

Integração contínua

  • Sua equipe vai precisar escrever testes automatizados para cada novo recurso, melhoria ou atualização de segurança.
  • Você precisa de um servidor de integração contínua que possa monitorar o repositório principal e executar testes automaticamente para cada novo commit enviado por push.
  • Os desenvolvedores precisam mesclar suas alterações com a maior frequência possível, pelo menos uma vez por dia.
  • Menos bugs são enviados para a produção, pois as regressões são capturadas com antecedência pelos testes automatizados.
  • Compilar a versão é fácil, pois todos os problemas de integração foram resolvidos precocemente.
  • Menos mudança de contexto, uma vez que os desenvolvedores são alertados assim que causam uma falha ao build e podem trabalhar em corrigi-lo antes de passarem para outra tarefa.
  • Os custos de teste são reduzidos drasticamente — seu servidor de integração contínua pode executar centenas de testes em questão de segundos.
  • Sua equipe de controle de qualidade gasta menos tempo testando e pode se concentrar em melhorias significativas na cultura de qualidade.
Serviço constante
  • Você precisa de uma base sólida na integração contínua e seu conjunto de testes precisa cobrir o suficiente de sua base de código.
  • As implementações precisam ser automatizadas. O acionador ainda é manual, mas uma vez que uma implementação é iniciada, não deve haver necessidade de intervenção humana.
  • É provável que a equipe precise adotar marcações de recursos para que recursos incompletos não afetem os clientes na produção.
  • A complexidade da implementação de software foi removida. Sua equipe não precisa mais passar dias se preparando para um lançamento.
  • Você pode lançar com mais frequência, acelerando o ciclo de feedback com seus clientes.
  • Há muito menos pressão sobre as decisões para pequenas mudanças, incentivando assim a iteração mais rápida.
Implementação contínua
  • Sua cultura de teste precisa estar em seu melhor. A qualidade do seu pacote de teste determinará a qualidade das suas versões.
  • Seu processo de documentação precisará acompanhar o ritmo das implementações.
  • As marcações de recurso passam a ser uma parte inerente do processo de lançamento de mudanças significativas para garantir que você possa coordenar com outros departamentos (Suporte, Marketing, RP...).
  • Você pode se desenvolver mais rápido, pois não há necessidade de pausar o desenvolvimento para lançamentos. Os pipelines de implementação são acionados automaticamente para cada alteração.
  • Os lançamentos são menos arriscados e mais fáceis de corrigir em caso de problema à medida que você implemente pequenos lotes de alterações.
  • Os clientes veem um fluxo contínuo de melhorias e aumentos de qualidade todos os dias, em vez de a cada mês, trimestre ou ano.

Integração contínua

Do que você precisa (custo)

  • Sua equipe vai precisar escrever testes automatizados para cada novo recurso, melhoria ou atualização de segurança.
  • Você precisa de um servidor de integração contínua que possa monitorar o repositório principal e executar testes automaticamente para cada novo commit enviado por push.
  • Os desenvolvedores precisam mesclar suas alterações com a maior frequência possível, pelo menos uma vez por dia.

O que você ganha

  • Menos bugs são enviados para a produção, pois as regressões são capturadas com antecedência pelos testes automatizados.
  • Compilar a versão é fácil, pois todos os problemas de integração foram resolvidos precocemente.
  • Menos mudança de contexto, uma vez que os desenvolvedores são alertados assim que causam uma falha ao build e podem trabalhar em corrigi-lo antes de passarem para outra tarefa.
  • Os custos de teste são reduzidos drasticamente — seu servidor de integração contínua pode executar centenas de testes em questão de segundos.
  • Sua equipe de controle de qualidade gasta menos tempo testando e pode se concentrar em melhorias significativas na cultura de qualidade.

Serviço constante

Do que você precisa (custo)

  • Você precisa de uma base sólida na integração contínua e seu conjunto de testes precisa cobrir o suficiente de sua base de código.
  • As implementações precisam ser automatizadas. O acionador ainda é manual, mas uma vez que uma implementação é iniciada, não deve haver necessidade de intervenção humana.
  • É provável que a equipe precise adotar marcações de recursos para que recursos incompletos não afetem os clientes na produção.

O que você ganha

  • A complexidade da implementação de software foi removida. Sua equipe não precisa mais passar dias se preparando para um lançamento.
  • Você pode lançar com mais frequência, acelerando o ciclo de feedback com seus clientes.
  • Há muito menos pressão sobre as decisões para pequenas mudanças, incentivando assim a iteração mais rápida.

Implementação contínua

Do que você precisa (custo)

  • Sua cultura de teste precisa estar em seu melhor. A qualidade do seu pacote de teste determinará a qualidade das suas versões.
  • Seu processo de documentação precisará acompanhar o ritmo das implementações.
  • As marcações de recurso passam a ser uma parte inerente do processo de lançamento de mudanças significativas para garantir que você possa coordenar com outros departamentos (Suporte, Marketing, RP...).

O que você ganha

  • Você pode se desenvolver mais rápido, pois não há necessidade de pausar o desenvolvimento para lançamentos. Os pipelines de implementação são acionados automaticamente para cada alteração.
  • Os lançamentos são menos arriscados e mais fáceis de corrigir em caso de problema à medida que você implemente pequenos lotes de alterações.
  • Os clientes veem um fluxo contínuo de melhorias e aumentos de qualidade todos os dias, em vez de a cada mês, trimestre ou ano.

Um dos custos tradicionais associados à integração contínua é a instalação e manutenção de um servidor de integração contínua. Mas você pode reduzir significativamente o custo da adoção dessas práticas usando um serviço de nuvem como o Bitbucket Pipelines, que adiciona automação a todos os repositórios Bitbucket. Simplesmente adicionando um arquivo de configuração na raiz do seu repositório, você vai poder criar um pipeline de implementação contínua que seja executado para cada nova alteração enviada para a ramificação principal.

Um pipeline de implementação contínua com o Bitbucket | CI/CD da Atlassian

Passando da integração contínua à implementação contínua

Se você está começando em um novo projeto sem usuários ainda, pode ser mais fácil implementar cada commit para a produção. Você pode até começar automatizando suas implementações e lançar sua versão alfa para uma produção sem clientes. Em seguida, você aumentaria sua cultura de teste e se certificaria de aumentar a forma de verificação do código à medida que compila seu aplicativo. Quando estiver pronto para a integração dos usuários, você vai ter um ótimo processo de implementação contínua, onde todas as novas alterações são testadas antes de ser lançadas automaticamente para produção.

Mas se você já tem um aplicativo existente com os clientes, você deve retardar as coisas e começar com integração contínua e entrega contínua. Comece implementando testes básicos de unidade que são executados automaticamente, sem necessidade de se concentrar ainda em ter testes complexos de ponta a ponta em execução. Em vez disso, você deve tentar automatizar suas implementações o mais rápido possível e chegar a um estágio em que as implementações em seus ambientes de staging são automáticas. O motivo é que, ao ter implementações automáticas, você vai poder concentrar sua energia em melhorar seus testes, em vez de ter que parar periodicamente as coisas para coordenar um lançamento.

Assim que conseguir começar a fazer lançamentos diários de software, você pode examinar a implementação contínua, mas confirme se o resto da organização também está pronto. Documentação, suporte, marketing. Essas funções vão precisar de adaptação à nova cadência de lançamentos, e é importante que elas não percam mudanças significativas que possam afetar os clientes.

Leia os guias

Você pode encontrar alguns guias que se aprofundam mais para ajudar a começar essas práticas.