O que é entrega contínua?

No cerne do DevOps está uma mudança de mentalidade. Em vez de ver o processo de desenvolvimento de software como uma cadeia de produção de mão única, com requisitos, código e relatórios transmitidos de uma equipe para a outra de forma linear, o DevOps defende a colaboração e o feedback rápido a partir de ciclos curtos e iterativos.

Mudar sua definição de "pronto" pode ajudar na adoção dessa mentalidade: em vez de considerar que sua parte está concluída quando você entrega seu código para a equipe seguinte da cadeia, seu novo recurso ou alteração no código só é considerado pronto quando for lançado para ser colocado 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.

Ao olhar para todo o ciclo de vida de desenvolvimento de software, em vez para apenas uma parte dele, você terá uma melhor compreensão do que é necessário para entregar software aos usuários e ainda a oportunidade de abrir mais linhas de comunicação com as outras equipes envolvidas.

A entrega contínua é sobre identificar os pontos problemáticos que retardam esse processo de entrega e construir um pipeline automatizado para fazer com que os lançamentos sejam mais rápidos e mais confiáveis, de forma que que você esteja sempre pronto para fazer um lançamento a qualquer momento. Com o pipeline instalado, você deverá ser capaz de implantar e colocar no ar qualquer build de boa qualidade com um único comando.

A integração contínua oferece os fundamentos para isto, com commits pelo menos diários de alterações de código, seguidos por um processo automatizado de build e testes para garantir feedback rápido aos desenvolvedores. Se um build ou teste falhar, é prioridade de todos resolver o problema.

Ao detectar os bugs no início, você pode corrigi-los enquanto o código ainda está fresco em sua mente e evitar que outras funcionalidades sejam criadas sobre código ruim, fazendo com que seja necessário desfazê-las posteriormente. Com a entrega contínua, o build contendo as mudanças mais recentes do processo de CI é automaticamente promovido através de uma série de ambientes de pré-produção. Embora o push final para a produção seja acionado manualmente, ele ainda segue um processo de script, facilitando a repetição de forma que você possa realizar lançamentos com a frequência necessária.

A construção do seu pipeline de CI/CD é uma oportunidade de colaborar com as várias partes interessadas no seu processo de lançamento, para que você possa levar em consideração suas necessidades e integrá-las ao design do pipeline. Esperamos que você já tenha se envolvido com seus colegas de QA, ao projetar testes automatizados.

Acrescentar uma etapa para testes manuais exploratórios num ambiente de teste adequado (o mais próximo possível da produção) ajudará a identificar falhas que você não tenha previsto (e que poderão assim serem cobertas por testes automatizados). É um passo importante para a entrega contínua.

A equipe de segurança cibernética ou infosec costuma ser vista como uma barreira aos lançamentos frequentes devido ao tempo envolvido na execução de uma auditoria de segurança e aos longos relatórios que seguem. Adotar uma abordagem DevSecOps irá ajudá-lo a inserir requisitos de segurança no seu pipeline.

As etapas de construção, ambientes e testes de que você precisa dependem da arquitetura do seu software e de suas prioridades organizacionais. Se você está construindo um sistema baseado em microsserviços, você pode aproveitar as vantagens da arquitetura para rodar testes em serviços individuais em paralelo antes de combiná-los para integrações mais complexas e testes de ponta-a-ponta.

Testes exploratórios manuais podem parecer um exagero para cada correção de bug que passa pelo pipeline. Nesse caso, ter etapas opcionais ou canais alternativos com base no tipo de alteração pode ser mais eficiente para a entrega contínua.

Uma vez que você tenha decidido as etapas do seu pipeline, incluindo quais testes serão executados em cada um, é hora de escrever o script do processo para garantir que seja confiável e repetível. Para evitar introduzir inconsistências, o mesmo artefato de build da fase de CI deve ser implantado em cada ambiente de pré-produção e no próprio ambiente de produção.

Idealmente, os ambientes de teste devem ser reiniciados para cada novo build. Usar contêineres com uma abordagem de infraestrutura como código significa que você pode fazer criar scripts para essas etapas, destruindo e recriando novos ambientes conforme necessário.

Se seu pipeline inclui ambientes de preparação para que equipes de suporte, vendas ou marketing se familiarizem com os novos recursos, você talvez prefira controlar manualmente o processo quando eles forem atualizados com um novo build, evitando interromper o trabalho em andamento. Quanto ao processo de colocar em produção a versão final, o processo de implantação poderá ainda ser programado em um script, para manter o processo rápido e consistente.

A entrega contínua promete lançamentos mais rápidos sem comprometer a qualidade, mas tornar isso uma realidade requer a cooperação de diversas partes de uma organização.

A quebra de silos é não apenas um desafio no curto prazo, mas também um benefício no longo prazo, pois essa colaboração vai ajudá-lo a trabalhar de forma mais eficiente.

Implementar entrega contínua requer bastante investimento de tempo e pode ser um verdadeiro desafio. Adotar uma abordagem iterativa e construir seu processo ao longo do tempo torna tudo mais gerenciável e permite que você demonstre as vantagens do processo para as principais partes interessadas. A coleta de métricas sobre os tempos de build e teste, comparando-as aos procedimentos manuais é uma maneira simples de mostrar o retorno do investimento, assim como as taxas de defeitos.

Medir o valor da entrega contínua pode ser útil ao planejar seus requisitos de infraestrutura. À medida em que você escala seu processo de lançamento, você provavelmente irá querer começar a executar múltiplos builds e testes em paralelo. Nesse contexto, as máquinas disponíveis podem se tornar um fator limitante. Uma vez que você tenha otimizado o desempenho do seu pipeline, você talvez queira considerar a mudança para uma infraestrutura hospedada em nuvem, para que você possa escalar a solução, conforme necessário.

Construir um pipeline de CI/CD pode parecer uma tarefa assustadora que requer muito esforço inicial por parte da equipe. No entanto, quando bem feita, a CI/CD pode permitir que sua equipe configure o processo de entrega de software consumindo um décimo do tempo. Para tanto, é importante seguir algumas práticas recomendadas de CD para acertar o processo.

Entrega contínua é o processo de automação das várias etapas necessárias para enviar um software para produção. No entanto, isso não envolve automatizar totalmente o lançamento do software: é aí que entra a implantação contínua. Podemos pensar na entrega contínua e na implantação contínua como partes diferentes do mesmo processo de CI/CD.

Leia mais sobre a comparação entre entrega contínua e implantação contínua

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).