Entendendo a Entrega Contínua (Continuous Delivery)

A entrega contínua (CD) utiliza como base a integração contínua (CI), ao automatizar as etapas envolvidas na preparação do software para lançamento em produção.

Sempre que você faz merge de alterações de código num branch designado, o processo de integração contínua executa uma série de verificações, inclusive testes de unidade automatizados, e cria uma build. A entrega contínua amplia esse processo, implantando automaticamente cada build em uma série de ambientes de teste e preparação e executando outros testes automatizados.

Esses testes podem incluir testes de integração, testes de interface do usuário, testes de desempenho (como testes de carga, absorção e estresse) e testes de ponta a ponta. Dependendo do seu setor, você também pode usar a entrega contínua para executar testes de segurança, testes de acessibilidade e testes manuais de aceitação dos usuários ou testes exploratórios. Quando uma build passa por cada estágio com sucesso, ela é considerada pronta para ser lançada em produção.

Assim como na integração contínua, o segredo para uma prática de entrega contínua eficaz é automatizar o processo ao máximo. Isso inclui fornecer feedback sobre cada estágio e alertar a equipe sempre que a build não passar em um estágio, para que você possa resolver o problema rapidamente.

Tanto a entrega contínua quanto a implantação contínua envolvem a implantação automática de builds em ambientes e a execução de testes automatizados. Como resultado, os dois termos às vezes são usados de maneira intercambiável. No entanto, há uma distinção prática entre a entrega contínua e a implantação contínua.

Com a implantação contínua, uma alteração de código é implantada automaticamente em produção sempre que ela passa com sucesso em cada estágio de teste. Por outro lado, a entrega contínua envolve uma etapa manual para o estágio final: a liberação do software para produção.

Embora a implantação contínua possa parecer a meta ideal para qualquer equipe de desenvolvimento de software, há bons motivos pelos quais muitas equipes optam por praticar a entrega contínua.

Leia mais sobre entrega contínua x implantação contínua.

O estágio final de um processo de CI/CD envolve a implantação das alterações de código na produção. Com a entrega contínua, a decisão de liberar para a produção é uma etapa manual, mesmo que o processo de liberação propriamente dito seja automatizado.

Algumas equipes praticam a entrega contínua como um trampolim para a implantação contínua. O acionamento manual da implantação final em produção oferece uma rede de segurança enquanto você cultiva a confiança nos seus testes e verificações automatizados. Nesse caso, você pode optar por praticar a entrega contínua por vários meses antes de passar a implantar automaticamente em produção todas as alterações de código bem-sucedidas.

No entanto, implantar atualizações no software várias vezes por dia ou por hora nem sempre é a melhor opção. Para software com controle de versão, incluindo aplicativos móveis, APIs, softwares embarcados ou produtos de desktop, geralmente faz sentido agrupar as alterações em versões maiores. Os usuários de produtos instalados não esperam ter que atualizar seus aplicativos a cada poucas horas, enquanto o upgrade para uma nova versão da API pode afetar significativamente seus clientes. Escolher entre entrega contínua e implantação contínua é tomar a decisão certa para sua empresa e seus usuários.

Embora as etapas exatas de build, ambientes e testes dependam do seu produto e da sua organização, os princípios gerais a seguir ajudarão você a criar seu processo de entrega contínua:

• Comece com a CI: implantar a integração contínua antes da entrega contínua faz sentido na maioria dos casos. Como a CI afeta principalmente a equipe de desenvolvimento, tem-se uma oportunidade de se acostumar a automatizar o processo de build, teste e implantação antes de envolver as partes interessadas externas.
• Projete seu processo de CD para obter feedback rápido: a descoberta antecipada de problemas torna seu processo de desenvolvimento mais eficiente. Alguns estágios podem ser executados em paralelo, como testes automatizados de interface do usuário em builds para diferentes plataformas. Da mesma forma, testes de desempenho de execução mais longa ou com uso intensivo de recursos podem ser adiados até que a build passe nos estágios anteriores.
• Envolva-se com as partes interessadas: DevOps – a filosofia por detrás da CI/CD incentiva as equipes de desenvolvimento a romper os silos e considerar todo o processo de desenvolvimento de software. Ao projetar seu pipeline de CD, envolva todas as pessoas que participam do processo de lançamento atual, desde operações e segurança até marketing e suporte.
• Automatize seus testes: Testes automatizados são essenciais para entrega contínua, pois fornecem validação confiável e rápida de que seu software se comporta conforme o esperado. Se você não tiver testes automatizados, priorize as áreas de maior impacto e aumente a cobertura dos testes de maneira incremental.
• Reutilize o mesmo artefato de build: para evitar a introdução de inconsistências, implante o mesmo artefato de build do estágio de CI em cada ambiente de pré-produção e no próprio ambiente de produção.
• Atualize ambientes de teste automaticamente: em condições ideais, os ambientes de teste devem ser atualizados para cada nova build no seu processo de CI/CD. Os containers e uma abordagem de infraestrutura como código facilitam o desmantelamento e a criação de novos ambientes conforme necessário.
• Considere as necessidades das partes interessadas: a exceção ao ponto anterior são os ambientes de preparação usados pelas equipes de suporte, vendas ou marketing para se familiarizarem com os novos recursos. Essas equipes podem preferir que os ambientes sejam atualizados mediante solicitação para evitar a interrupção do trabalho em andamento.
• Adote o DevSecOps: a equipe de segurança das informações ou segurança cibernética é vista frequentemente como uma barreira para lançamentos frequentes, devido ao tempo envolvido na execução de uma auditoria de segurança e aos longos relatórios que acompanham o processo. Adote uma abordagem de DevSecOps e inclua os requisitos de segurança no seu pipeline desde o início.
• Considere os requisitos de testes manuais: dependendo dos seus negócios, incorpore alguns testes exploratórios manuais para ajudar a identificar modos de falha inesperados. Em vez de exigir testes manuais de cada alteração de código, considere a possibilidade de ter etapas opcionais ou pipelines alternativos que sejam executados semanal ou mensalmente.
• Automatize o lançamento: embora a entrega contínua signifique que a decisão de lançar para o ambiente de produção seja manual, o lançamento em si deve ser automatizado. Você deve ser capaz de implantar qualquer boa build em tempo real com um único comando.

A entrega contínua permite que as equipes liberem o software com mais rapidez e frequência, reduzindo o número de bugs que chegam à produção. O segredo para conseguir isso é garantir que seu código esteja sempre pronto para ser lançado, testando continuamente as alterações e resolvendo os problemas assim que forem descobertos.

Além disso, a entrega contínua oferece vários benefícios adicionais:

• Fazer lançamentos com mais frequência significa que você acelera o tempo de lançamento no mercado, obtendo novos recursos, correções e aprimoramentos para os usuários mais rapidamente.
• O processo de teste contínuo significa que você obtém feedback rápido sobre seu trabalho. Se uma alteração recente introduzir uma vulnerabilidade, fizer com que o aplicativo trave em determinadas circunstâncias ou fizer com que uma chamada de API falhe, você descobrirá o problema muito antes do que faria com um processo tradicional de teste de lançamentos.
• Descobrir os problemas mais cedo torna o processo de desenvolvimento mais eficiente. Não só a alteração ainda está relativamente fresca em sua mente, como também há menos risco de que outras alterações de código que dependem do código defeituoso tenham sido adicionadas.
• A automação de tarefas repetitivas de build, teste e lançamento garante que elas sejam executadas de maneira consistente e reduz o risco de erros, liberando os membros da equipe para se concentrarem em agregar valor.
• Investir em testes automatizados ajuda você a testar seu software de maneira mais completa. Isso pode incluir a realização de testes consistentes em várias plataformas, a verificação do cumprimento dos requisitos de acessibilidade ou a definição de uma base para o desempenho do seu produto ou serviço.
• A atualização automática de ambientes e a implantação de builds ajudam você a usar a infraestrutura com mais eficiência, seja em servidores locais ou numa farm de builds hospedada na nuvem.
• A automação de implantações em locais de teste garante que as equipes de produto, marketing e suporte possam visualizar novos recursos sem esforço manual adicional das equipes de desenvolvimento ou operações.
• A entrega contínua torna seu processo de lançamento robusto e repetível, ao mesmo tempo em que lhe dá controle sobre exatamente quando lançar. Com um processo de CD implantado, você pode optar por fazer pequenas melhorias semanalmente, diariamente ou até mesmo a cada hora.

A implantação de um processo de entrega contínua pode trazer alguns desafios:

• Cooperação entre equipes: você provavelmente precisará da cooperação de várias partes da sua organização, como equipes de operações, infraestrutura e segurança. Embora a quebra de silos possa ser desafiadora no curto prazo, ela leva a uma melhor colaboração e eficácia no longo prazo.
• Investimento de tempo: automatizar seus processos de build, teste e lançamento leva tempo. Entretanto, adotar uma abordagem iterativa e desenvolver seu processo ao longo do tempo torna isso mais gerenciável. A coleta de métricas, como taxas de defeitos e tempos de build, e sua comparação com os procedimentos manuais é uma forma eficaz de demonstrar o retorno sobre o investimento às partes interessadas.
• Desafios de escalabilidade: ao dimensionar seu processo de entrega contínua, você provavelmente desejará começar a executar várias builds e testes em paralelo. Nesse ponto, o número de servidores disponíveis pode se tornar um fator limitante. Depois de otimizar o desempenho do seu pipeline, considere a possibilidade de mudar para a infraestrutura hospedada na nuvem com o objetivo de escalar sua farm de builds conforme necessário.

Criar um processo de entrega contínua pode parecer assustador, mas, quando feito corretamente é capaz de acelerar drasticamente os lançamentos de software enquanto minimiza os bugs.

A adoção da mentalidade de DevOps é fundamental para a implantação eficaz da entrega contínua. Em vez de encarar o processo de desenvolvimento de software como uma esteira rolante unidirecional, com requisitos, códigos e relatórios passados de uma equipe para a outra, o DevOps defende a colaboração e o feedback rápido de ciclos curtos e iterativos.

Mudar sua "definição de feito" pode ajudar você a adotar essa mentalidade. Em vez de considerar a tarefa concluída quando você entrega seu código para teste, seu novo recurso ou alteração de código somente é concluído quando é lançado em produção. Se um problema for encontrado em qualquer estágio do pipeline, comunicar esse feedback imediatamente e colaborar para realizar uma correção faz com que a resolução seja mais rápida do que a elaboração de relatórios longos que precisariam passar por uma comissão de alterações para ter aprovação. É disso que se trata a entrega contínua.

Para receber mais dicas que ajudarão você a começar a usar a entrega contínua, leia nosso guia de práticas recomendadas de CI/CD.

A entrega contínua faz com que o lançamento de software seja mais fácil e mais rápido, permitindo que você possa implantá-lo em ambiente de produção com muito mais frequência. Em vez de ter um grande lançamento trimestral ou anual, atualizações menores são entregues com frequência. Isto significa que os usuários receberão novas funcionalidades e correções de bugs mais cedo, mas não apenas isto. Também significa que você saberá como seu software é usado e poderá ajustar seus planos de acordo com esse feedback.

Enquanto algumas organizações preferem manter o controle sobre a etapa final do processo de lançamento, para outras, a conclusão lógica de um pipeline de CI/CD é automatizar o lançamento para que o serviço vá ao ar, usando uma prática conhecida como implantação contínua (continuous deployment). Você pode saber mais sobre isso na próxima seção do nosso guia de CI/CD.

O TeamCity é uma plataforma de CI/CD com amplo suporte para uma grande variedade de ferramentas de build, frameworks de teste, containers e provedores de infraestrutura de nuvem. Não importa se você deseja hospedar suas máquinas de build localmente, na nuvem ou usar uma combinação de ambos, o TeamCity coordenará as tarefas de build para proporcionar eficiência máxima.

A lógica de pipeline personalizável do TeamCity significa que você pode escolher quando executar processos em paralelo - como testes em diferentes plataformas - e quando exigir a conclusão bem-sucedida antes de passar para o próximo estágio. Notificações configuráveis fornecem as informações necessárias onde quer que você esteja trabalhando, ajudando a evitar interrupções desnecessárias. Por fim, os resultados detalhados o ajudam a garantir que o caminho para a produção permaneça claro.