Integração Contínua vs. Entrega vs. Implantação
Os desenvolvedores geralmente se referem à integração contínua (CI) e à entrega ou implantação contínua (CD) como CI/CD. Entender as diferenças entre essas práticas de DevOps pode ajudar você a simplificar o trabalho necessário para a configuração do seu próprio processo de CI/CD, permitindo que você usufrua das vantagens obtidas com a melhor qualidade e estabilidade.
A integração contínua e a entrega ou implantação contínua são etapas essenciais no fluxo de trabalho para criação, teste e implantação de softwares. O objetivo é oferecer mudanças menores e frequentes aos usuários, permitindo feedback regular sobre o que você está criando. Tanto o CI quanto o CD dependem da automação para aumentar a eficiência e a confiabilidade.
Antes de desenvolver seu processo de CI/CD, é essencial entender as diferenças entre entrega contínua, implantação contínua e integração contínua.
Principais diferenças entre CI e CD
Vamos começar analisando as principais características de CI e CD, juntamente com suas diferenças.
Integração contínua (CI)
Integração contínua (CI) é a prática de verificar automaticamente as alterações do seu código para obter feedback rápido sobre seu trabalho. Com a CI, cada vez que você faz commit de uma alteração, seu servidor de CI executa uma build e roda testes automatizados. Esses testes geralmente incluem testes de unidade, testes de integração e outras verificações, como linting ou análise estática. Se alguma etapa do processo de CI falhar, você receberá feedback automático para poder resolver o problema. O processo recomeça quando você faz commit de uma correção.
Entrega contínua e implantação contínua (CD)
A entrega contínua e a implantação contínua (CD) começam onde a CI termina. Ambas envolvem a implantação de um artefato de construção em um ou mais ambientes de teste para testes automatizados adicionais, como testes de ponta a ponta, GUI, desempenho e segurança. Uma build deve passar em todos os testes antes de ser considerada pronta para lançamento.
Assim como acontece com a CI, se um teste falhar durante qualquer fase da CD, o processo será interrompido, e os detalhes serão relatados para que você possa investigar e corrigir o problema. Quando uma nova build estiver pronta, o processo começará novamente do início, passando por todas as etapas de CI antes de entrar na fase de CD.
Entrega contínua vs. implantação contínua
A diferença entre entrega contínua e implantação contínua está no estágio final de lançamento para produção.
Com a entrega contínua, lançar o artefato de compilação em produção requer entrada manual. O processo de lançamento geralmente é totalmente automatizado, mas alguém precisa decidir se e quando uma build específica será lançada. Em contraste, na implantação contínua, a build é lançada em produção automaticamente todas as vezes que os estágios anteriores do processo forem concluídos.
Escolhendo entre entrega contínua e implantação contínua
Decidir se a entrega contínua ou a implantação contínua é mais adequada depende do seu contexto.
Para produtos de software, como aplicativos móveis ou APIs, lançar uma nova versão para cada commit bem-sucedido pode não ser o ideal. Em vez disso, você pode preferir lançar conforme uma programação ou esperar até ter um número mínimo de alterações prontas para serem implantadas.
Nesse caso, você pode usar a entrega contínua para verificar as alterações à medida que elas são feitas e prever as versões em um ambiente de pré-produção. A entrega contínua também pode fornecer uma oportunidade para testes de aceitação manual antes de cada lançamento.
Por outro lado, a implantação contínua funciona bem para aplicativos e serviços baseados na Web, em que atualizações frequentes – diárias ou até mesmo de hora em hora – são o padrão.
A implantação contínua permite que você forneça atualizações diretas e receba feedback em tempo hábil. Você também pode usar a implantação contínua para executar experimentos e validar suposições com usuários do mundo real, sabendo que pode mudar de direção rapidamente com uma nova versão, conforme necessário.
Por fim, é importante observar que você pode integrar alguns testes manuais de aceitação e exploratórios em um processo de implantação contínua.
Em vez de exigir verificações manuais antes de cada lançamento, você pode implantar periodicamente alterações em um ambiente de preparação e executar esses testes em um ciclo semanal (ou mais longo).
Enquanto isso, as alterações que passarem por todas as verificações automatizadas podem continuar a ser lançadas para produção. Se você descobrir um problema no preparo, seu pipeline automatizado garante que você possa implantar rapidamente uma correção na produção.
Como a integração contínua, a entrega e a implantação funcionam juntas
A CI/CD representa dois estágios no processo de build, teste e lançamento de software.
Um pipeline de CI/CD é uma ferramenta que aumenta progressivamente a confiança no seu código.
Cada etapa bem-sucedida aumenta sua confiança até que você esteja satisfeito em liberar o código para os usuários. Entretanto, se alguma etapa falhar, você interrompe o processo de build e precisa ou corrigir o bug ou reverter as alterações. Depois de resolvido, o processo é reiniciado do início.
Como a primeira fase do processo de build, teste e lançamento, a CI se concentra no feedback rápido por meio de verificações. O feedback rápido sobre alterações no seu código ajuda você a trabalhar de forma mais eficiente, reduzindo a necessidade de troca de contexto. Em vez de esperar horas ou dias pelos resultados dos testes manuais, você recebe alertas em minutos sobre quaisquer problemas introduzidos pelas suas alterações.
Se a build que contém suas alterações passar nos testes de CI, a sua implantação em ambientes de pré-produção será justificada. Neste ponto, você pode executar testes mais longos e que exigem mais recursos.
Automatizar o máximo possível de etapas de CD encurta ainda mais o ciclo de feedback e torna o fluxo de trabalho mais eficiente. Além de automatizar testes, por exemplo, você pode atualizar ambientes de pré-produção e implantar builds neles automaticamente.
Passando da CI para a CD
Se você é novato em CI/CD, em vez de se concentrar em escolher entre integração contínua e entrega ou implantação contínuas, sugerimos decidir por onde começar e até você onde quer ir.
Tanto a CI quanto a CD envolvem várias etapas, o que significa que você pode desenvolver seus processos gradualmente.
Encontrando seu ponto de partida
Se você já automatizou algumas partes do seu processo de build ou lançamento, ou se escreveu testes automatizados, isso pode fornecer um ponto de partida natural. Caso contrário, comece considerando quais partes do seu processo de build, teste e lançamento são mais demoradas ou propensas a problemas na produção devido a testes inadequados.
Muitas equipes optam por começar com CI porque ele exige menos coordenação com outras partes da organização, e o feedback rápido dos testes automatizados de unidade e integração ajuda a melhorar a qualidade do código.
Além disso, reconhecer os benefícios da CI ajuda a promover uma cultura de testes automatizados, o que é vital para uma CI/CD eficaz e incentiva uma maior expansão da cobertura de testes automatizados.
Por outro lado, se você atualmente gerencia a coordenação de lançamentos e o desenvolvimento de código, automatizar primeiro o estágio final da CD (o lançamento para produção) pode economizar tempo a longo prazo.
Embora a CI forneça uma base sólida para CD, a escolha entre entrega contínua e implantação contínua depende dos seus requisitos. Mesmo que seu objetivo de longo prazo seja a implantação contínua, uma estratégia típica é começar com a entrega contínua. Depois de estabelecer confiança em seus workflows, você pode dar o salto para automatizar a versão final para produção.
Melhorando seus processos de CI/CD
A CI e a CD funcionam melhor quando você divide as tarefas de desenvolvimento em entregas menores e faz commits das suas alterações regularmente.
Se sua meta é a implantação contínua, você precisa considerar como gerenciar recursos que ainda não estão prontos para lançamento, mesmo que tenha havido commit de alterações para eles. Você pode conseguir isso usando sinalizadores de recursos ou uma estratégia de branching que isola o trabalho em andamento do branch de lançamento, ao mesmo tempo em que garante que você faça build e teste de cada alteração de código automaticamente.
Resumo
Para recapitular:
- A integração contínua (CI) envolve a execução de testes automatizados e a verificação de que seja feito uma build da sua solução sempre que você fizer commit de uma alteração.
- Tanto a entrega contínua quanto a implantação contínua (CD) envolvem a implantação automática de artefatos de build em ambientes de teste e preparação para executar testes adicionais. Normalmente, essas etapas são executadas após a integração contínua.
- Na entrega contínua, você decide quando liberar um determinado artefato de build para produção e inicia o lançamento manualmente.
- Na implantação contínua, cada alteração de código que passa pelos estágios anteriores com sucesso é automaticamente liberada para produção.
- A CI e a CD são práticas complementares projetadas para identificar problemas rapidamente e dar a você confiança em suas alterações antes de lançá-las.
- Um processo robusto de CI/CD com testes automatizados permite que você implante correções com mais rapidez e confiança se você lançar algum bug para a produção.
- Um processo de build, teste e lançamento totalmente automatizado consiste de ambos os processos CI e CD, mas você pode começar com apenas um ou outro e criar seu processo de forma incremental.
- Muitas equipes começam com a integração contínua, pois os testes automatizados geralmente são de responsabilidade dos desenvolvedores.
- No entanto, se você também for responsável pelos lançamentos, automatizá-los primeiro pode ajudar a economizar tempo para que você possa se concentrar na criação do seu processo de CI.