Integração contínua vs. Entrega contínua vs. Implementação contínua
Saiba as diferenças entre as práticas contínuas
Sten Pittet
Autor colaborador
IC e CD são duas siglas usadas com frequência em práticas de desenvolvimento moderno e DevOps. IC significa integração contínua, uma prática recomendada de DevOps fundamental onde os desenvolvedores com frequência mesclam alterações de código no 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, entrega contínua e implementação contínua (IC/CD)?
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.
Ver solução
Crie e opere softwares com o Open DevOps
Material relacionado
O que é o pipeline de DevOps?
Implementação contínua
A 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 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 o 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 os benefícios de cada prática?
What are the benefits of each practice?
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.
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.
Passando da integração contínua à implementação contínua
Se você está começando o novo projeto sem usuários ainda, pode ser mais fácil implementar cada commit para a produção. Você pode até começar automatizando as implementações e lançando a versão alfa para uma produção sem clientes. Em seguida, você aumentaria a cultura de teste e se certificaria de aumentar a forma de verificação do código à medida que compila o 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 no automático para produção.
Mas se você já tem um aplicativo existente com os clientes, você deve desacelerar 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 no automático, sem necessidade de se concentrar ainda em fazer testes complexos de ponta a ponta. Em vez disso, você deve tentar automatizar as implementações o mais rápido possível e chegar ao estágio em que as implementações em ambientes de staging são automáticas. O motivo é que, ao ter implementações automáticas, você vai poder se concentrar em melhorar os testes, em vez de ter que parar com frequência as coisas para coordenar o lançamento.
Assim que começar a fazer lançamentos diários de software, você pode examinar a implementação contínua. Porém, certifique que o resto da empresa esteja pronta também: documentação, suporte, marketing, etc. 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
Read our guides
Você pode encontrar alguns guias que se aprofundam mais para ajudar a começar essas práticas.
Compartilhe este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.
Comunidade de DevOps
Leia o blog
