Integração Contínua vs. Entrega vs. Implantação
Se você já esteve envolvido com desenvolvimento de software por algum tempo, provavelmente já deve ter se deparado com o termo CI/CD.
Integração, entrega e implantação contínuas são práticas que buscam acelerar o processo de lançamento de software, ao encurtar os ciclos de feedback e automatizar tarefas repetitivas. Essas práticas desempenham um papel fundamental ao fazer com que o princípio ágil de garantir entregas frequentes aos usuários, de software útil e funcional, seja uma realidade.
Para equipes que encontraram seu ritmo e implementaram as ferramentas de CI/CD e processos para dar suporte a um ciclo de lançamento regular, um pipeline de CI/CD em bom funcionamento é uma fonte de orgulho, um sinal de que os desenvolvedores estão usando suas ferramentas para melhorar seu próprio ambiente e o produto final que estão criando.
No entanto, para alguém que ainda não tem familiaridade com a prática, transformar seu processo de build, testes e implantação num sistema automatizado pode parecer assustador e inatingível. Não precisa ser assim. A beleza de se construir um pipeline de CI/CD é que ele pode perfeitamente ser dividido em etapas separadas, cada uma iniciando onde termina a anterior. Vamos explorar em mais detalhes cada uma dessas práticas.
Vejamos o que é CI x CD e quais são as principais características de cada um.
O que é Integração Contínua (CI)?
Integração contínua é a prática de executar as etapas que tradicionalmente aconteciam durante a a fase de “integração”, pouco a pouco mas geralmente ao longo do processo de desenvolvimento, em vez de esperar até que o código esteja completo para só depois reuni-lo e testá-lo.
Supondo que você tenha mais de uma pessoa trabalhando num produto de software - que é a regra para a maior parte dos softwares comerciais e de código aberto - em algum momento você precisa integrar as partes nas quais cada desenvolvedor trabalhou e verificar se o resultado final funciona conforme o planejado. Com a integração contínua, esse ponto acontece pelo menos uma vez por dia, senão mais.
A justificativa é simples. Se você deixar a integração até que todo o código tenha sido escrito, há uma boa chance de que você tenha que gastar uma quantidade considerável de tempo desmembrando e reescrevendo seções de seu código para que o build da solução ocorra sem erros, e ainda mais garantir que ela funcione como planejado. Código é complexo. Mesmo com um design inicial detalhado, é incrivelmente difícil prever exatamente como a lógica vai interagir e evitar qualquer erros. Quanto mais código houver, maior será a complexidade e mais haverá para desmembrar quando algo não funcionar.
Com a integração contínua, seus desenvolvedores compartilham suas alterações fazendo commit delas regularmente para o sistema de controle de código fonte, pelo menos uma vez ao dia. Em seguida, verificam se a solução compila e passa nos testes. Isto significa que, se algo falhar, haverá muito menos alterações a serem feitas para encontrar a fonte do problema. O recebimento mais rápido de feedback também facilita a correção de quaisquer problemas, já que não foi perdido o contexto do que estava sendo feito.
Um bom processo de CI requer alguns ingredientes essenciais:
Use o sistema de controle de código fonte
Um sistema de controle de fontes (também conhecido como controle de versões) é absolutamente essencial. Se você não tiver um, ou apenas parte do seu código estiver no controle de fontes, o primeiro passo é colocar todo o seu código no sistema e garantir que todos passem a usá-lo.
Faça commit cedo e com frequência
Assim que você estiver usando um sistema de controle de fontes, faça com que todos adquiram o hábito de fazer commits o quanto antes e com frequência. O tamanho da tarefa poderá impactar aqui. Dividir cada unidade de trabalho em partes menores torna mais fácil concluir e testar um conjunto de alterações localmente para que elas estejam prontas para o commit.
Compile sua solução a cada commit
Compartilhar regularmente, com todos os participantes do projeto, as alterações que você fez no código é apenas o começo. A próxima etapa é verificar se a solução ainda pode ser compilada depois das alterações mais recentes. Embora isso possa ser feito manualmente, é muito mais fácil e eficiente disparar o processo de build automaticamente, e é aí que entra um servidor de CI.
Automatize os testes
Um build bem-sucedido é um bom sinal, mas para uma maior confiança, vale a pena executar alguns testes. Novamente, é muito mais fácil e eficiente executar testes automaticamente do que manualmente. Embora escrever testes automatizados possa parecer trabalhoso, o trabalho logo se paga quando você puder executá-los a cada build para obter um feedback rápido.
Preste atenção no feedback
Só vale a pena automatizar builds e testes se você for fazer alguma coisa com as informações que receber de volta. Ferramentas de CI oferecem uma variedade de mecanismos de feedback, desde painéis e radiadores até integração com plataformas de mensageria.
Crie uma cultura DevOps
Para realmente usufruir dos benefícios da integração contínua, você precisa criar uma cultura de equipe onde todos assumem a responsabilidade de consertar builds quebrados ou testes com falha. Colocar a culpa em quem fez o último commit é contraproducente, já que isto desencoraja sua equipe de fazer commits das alterações o quanto antes e com frequência, mesmo que seja do interesse de todos.
A combinação de todos esses ingredientes garante um feedback rápido e regular sobre o seu código. Ao verificar se qualquer alteração na base de código, seja ela uma correção de bug, refatoração ou parte de um novo recurso, pelo menos resulta num build limpo que passa nos testes, as equipes poderão evitar que código novo seja criado sobre bases ruins, afastando todo o processo de replanejamento que isto implica. A implementação da integração contínua por si só já é um grande passo para acelerar o processo de entrega de software funcional para seus usuários.
Entendendo a Entrega Contínua (Continuous Delivery)
A entrega contínua fundamenta-se na automação de builds e testes estabelecida com a integração contínua.
Com a entrega contínua, você transforma as etapas manuais usadas para lançar uma versão do seu software em ambiente de produção através de um processo automatizado.
Enquanto que no passado seu produto passava das mãos dos seus desenvolvedores para os testadores e, em seguida, dos testadores para os gerentes de lançamento, com a entrega contínua, sua equipe (que pode incluir pessoas de várias áreas) é dona de todo o processo de construção, testes e lançamento do seu produto. Isto traz várias vantagens:
- Ao evitar os silos tradicionais, sua equipe de desenvolvimento terá uma melhor compreensão das necessidades comerciais e operacionais para entregar seus produtos aos usuários.
- Isto, por sua vez, cria uma oportunidade de trazer práticas de desenvolvimento para o que geralmente era um processo manual e, muitas vezes, bastante longo.
- Automatizar as etapas envolvidas na entrega de um produto até sua implantação não apenas acelera o processo, mas também reduz o risco de erros, deixando-o mais estável e confiável.
As etapas envolvidas na entrega de software para seus usuários - e, portanto, etapas necessárias em um pipeline de entrega - variam de acordo com as necessidades da empresa e do usuário, mas é uma prática comum realizar o deploy em pelo menos um ambiente de pré-produção antes de lançar no mercado.
Estes podem ser ambientes de teste para camadas adicionais de teste, tais como segurança, testes de carga e testes de desempenho; ambientes sandbox para equipes de suporte e vendas se familiarizarem com novos recursos; e ambientes de teste de aceitação para profissionais de QA e de produto verificarem se as alterações funcionam conforme o planejado.
Com a entrega contínua, cada build bem-sucedido é implantado automaticamente em cada um dos ambientes de pré-produção, com a confiança na qualidade aumentando com cada etapa.
Esta é uma meta que vale a pena, mas que requer algum investimento para ser colocada em prática:
Único build
Somente ao promover o mesmo artefato de build através de cada etapa do pipeline você poderá ter certeza que ele passou em todos os estágios anteriores de teste.
Configuração no controle de versões
Manter todos esses arquivos de configuração no sistema de controle de versões ajuda a garantir que as implantações sejam consistentes e possam ser repetidas.
Automação de cada implantação
A implantação em cada ambiente deve ser realizada através de um script, para que possa ser executado automaticamente e, portanto, exatamente da mesma maneira, todas as vezes. O lançamento do serviço deve usar um script pelo mesmo motivo, mas com a entrega contínua, essa etapa final não é automática.
Limpe seus ambientes
Para uma abordagem totalmente consistente, os ambientes devem ser reiniciados para que tenham as mesmas condições em cada nova implantação. Graças aos contêineres, isto hoje é muito mais fácil de implementar, seja numa infraestrutura local ou na nuvem.
Separação de interesses de cada ambiente
A fim de automatizar a implantação do mesmo artefato em cada ambiente, é necessário haver uma separação clara entre a aplicação em si e as variáveis ou parâmetros específicos de cada ambiente.
Manutenção do pipeline
Assim como na integração contínua, só vale a pena investir num pipeline de entrega automatizado se você puder mantê-lo. A CI/CD envolve tanto a cultura da equipe quanto o processo e as ferramentas. Para ser eficaz, sua equipe precisa assumir a responsabilidade pela manutenção do pipeline e corrigir quaisquer problemas que surjam, sejam eles devido a um bug no próprio código ou um problema com as implantações ou testes automatizados.
Com a entrega contínua, sua equipe assume a responsabilidade pela entrega do software e se beneficia do feedback oportuno fornecido ao longo do processo. Tal como acontece na integração contínua, a prática pode ser ampliada e melhorada com o tempo.
Implantação Contínua Explicada
A implantação contínua leva as práticas de integração contínua e entrega contínua à sua conclusão lógica:
se um build passar com sucesso por todas as etapas anteriores do pipeline, ele será automaticamente liberado para produção. Isto significa que, assim que qualquer alteração no seu software passar em todos os testes, ela será entregue aos usuários. A implantação contínua encurta o ciclo de feedback desde a alteração no código até o uso em produção, proporcionando à sua equipe uma visão oportuna do efeito das alterações no mundo real sem comprometer a qualidade.
Embora a automação do processo de implantação do software em produção não seja adequado para todos os produtos e empresas, vale a pena levar em consideração as etapas necessárias para chegar lá, pois cada elemento individual tem um valor próprio:
Confie nos seus testes
A implantação automática de um serviço em produção exige um elevado nível de confiança no seu pipeline, especialmente nos seus testes automatizados. Uma excelente cultura de testagem, onde sua equipe investe em cobertura de testes e desempenho, priorizando a correção de problemas do build e do pipeline em vez de investir em novos recursos, é essencial.
Monitore a produção
Mesmo com todas as medidas acima em operação, a implantação contínua pode parecer uma prática arriscada. O que acontece se um bug não for detectado nos testes e só aparecer em produção? Isto pode por em risco seu tempo, dinheiro e reputação. Embora o mesmo problema possa acontecer com uma implantação manual, nada se compara a um um bug sério sendo lançado automaticamente pelo "sistema" para perder a confiança das partes interessadas. É nesse ponto que ser proativo na busca por sinais de problemas, em vez de esperar pela chegada de relatórios de erros, faz toda a diferença. Monitorar estatísticas para detectar qualquer alteração da norma, especialmente logo depois de um lançamento, pode lhe avisar sobre questões problemáticas antes que elas causem um problema perceptível para seus usuários.
Escolha o que será lançado
Uma reclamação comum dos novatos em implantação contínua é que, se seus desenvolvedores fazem commits muito cedo e com frequência, deixando que as coisas aconteçam sem alguma supervisão manual, seus usuários poderão encontrar recursos inacabados ou pela metade que ainda não estão prontos para serem usados. Em vez de recorrer a branches e perder as vantagens da integração contínua, a solução é usar feature flags. Seus desenvolvedores podem então controlar o que será visível e o que será oculto para o usuário quando ele estiver escrevendo o código.
Otimize seu pipeline
Se algo der errado em produção, você precisa ser capaz de responder rapidamente. Em alguns casos, poderá ser possível reverter o lançamento para a versão anterior. Muitas vezes, no entanto, as coisas não são tão simples. Migrações de banco de dados e correções de problemas conhecidos podem interferir em tudo e não deixar outra opção a não ser o lançamento de uma correção. Pular as etapas no seu pipeline é uma falsa economia, pois é bem provável que você introduza outros problemas que poderiam ter sido detectados se você executasse seus testes normalmente. Em vez disso, é melhor investir na otimização do seu pipeline, desde a velocidade do build até o desempenho dos testes. Isto não apenas significa que você pode implantar alterações rapidamente quando necessário, mas também reduz os ciclos de feedback ao longo do processo.
Controle a distribuição
Embora a implantação contínua signifique a realização de um lançamento automático, caso todas as etapas anteriores forem aprovadas, isto não significa abrir mão de todo o controle. Existem diversas práticas de implantação que podem ser usadas para minimizar o risco e controlar a distribuição. Lançamentos do tipo canário permitem que você inicialmente teste o serviço com uma pequena parte dos seus usuários, enquanto que implantações azul-verde podem ser usadas para controlar a transição para uma nova versão.
A integração, entrega e implantação contínuas todas contribuem com o objetivo de fornecer software de valor e que funcione aos seus usuários com frequência. Adotar uma abordagem "aos poucos e com frequência" para os processos de integração e lançamentos torna todo o processo mais fácil de gerenciar e também significa que as equipes realizam as etapas com mais frequência, melhorando cada vez mais.
Introduzir a automação nesse meio não apenas acelera o processo, mas também o deixa mais confiável. Cada etapa do pipeline é construída sobre a anterior. Você pode escolher o quanto é ideal para você, num determinado momento, para depois retornar e desenvolvê-lo mais adiante.
Principais diferenças entre CI e CD
Integração, entrega e implantação contínuas são estágios sequenciais do processo de entrega de software. Elea ajudam as equipes a lançar software com mais rapidez, encurtar o ciclo de feedback e automatizar tarefas repetitivas. Identificar as principais diferenças entre integração, entrega e implantação contínuas é tão importante quanto entender como essas três etapas funcionam juntas para entregar software aos usuários de maneira confiável e estável.
A integração contínua é a prática de mesclar quaisquer novas alterações de código no branch principal. A entrega contínua automatiza as tarefas manuais necessárias para criar e testar o software (por exemplo, automação de testes). A implantação contínua é uma continuação lógica da prática de automatizar as etapas de compilação e teste e, nesse estágio, o software é implantado automaticamente depois de passar por todos os pontos de verificação necessários.
Em geral, não é uma questão de CI versus CD, mas sim de como todos esses componentes trabalham juntos para criar um pipeline estável e confiável.