Introdução
A transição para Continuous Deployment (CD) é uma jornada que pode parecer desafiadora à primeira vista, mas os benefícios para a sua organização são incontestáveis. Se você está acostumado a ciclos de lançamento prolongados, como mensal, semestral ou até anual, a adoção do CD pode transformar completamente o modo como você entrega software. Ao automatizar todo o processo de deploy, desde a integração contínua até a entrega contínua, é possível alcançar um fluxo de trabalho mais eficiente, ágil e, acima de tudo, confiável. Neste guia, você verá como realizar essa transição, quais passos seguir e como o Continuous Deployment pode impactar positivamente a sua equipe, permitindo lançamentos mais frequentes, reduzindo o tempo de ciclo e aumentando a confiança no processo de deploy automatizado.
Transição de Releases Mensais para Continuous Deployment
Se você está lendo isso, provavelmente está pensando em fazer a transição para Continuous Deployment (CD). Ou talvez você já tenha feito a transição, mas ainda não sinta que está utilizando todo o potencial do seu pipeline de CD.
Fazer a transição de releases mensais (ou semestrais… ou anuais 😵💫) para Continuous Deployment é uma mudança recompensadora que trará benefícios para toda a sua organização. Mas, como em qualquer novo processo de desenvolvimento de software que você adota, há passos concretos que você precisará seguir para alcançar um pipeline de CD totalmente funcional.
Vamos guiá-lo por essas etapas para que sua equipe possa adotar o CD, independentemente da frequência com que você faz deploy de código atualmente. Em seguida, explicaremos como essa mudança pode trazer benefícios tangíveis para sua equipe ao fazer a transição para o Continuous Deployment e alcançar um fluxo de trabalho mais eficiente e ágil.
O que é Continuous Deployment?
Antes de entrarmos em como alcançar o Continuous Deployment, precisamos entender o que é Continuous Deployment e onde ele se encaixa em todo o fluxo de trabalho de Continuous Integration/Continuous Delivery/Continuous Deployment.
Todos os pipelines de CI/CD começam com Continuous Integration (CI). CI é o processo de construir, verificar e executar testes automatizados que o seu código precisa passar para ser mesclado à branch principal.
A partir daí, passamos para Continuous Delivery, que é o processo de garantir que o código na branch principal esteja sempre em um estado implantável para que você possa fazer deploy quando quiser. O código é automaticamente enviado para um ambiente de testes nesta etapa, mas não é implantado para os usuários finais até que você aperte manualmente o botão de “deploy”.
O passo final é o Continuous Deployment. Continuous Deployment é o processo de implantar automaticamente o código para os seus usuários finais se ele tiver passado por todos os testes e etapas até a produção. Quando falamos sobre transição para CD neste artigo, estamos falando de Continuous Deployment. Este é o objetivo final para a maioria das organizações que desejam lançar código várias vezes ao dia.
Pense no CI/CD como o processo de eliminar a cerimônia de release de código. Os dias de grandes releases no final do mês, com uma quantidade massiva de mudanças, ficaram para trás. Com CD, releases pequenos e deploys acontecem com tanta frequência (idealmente várias vezes ao dia) que se tornam parte do tecido da sua empresa.
Como Alcançar o Continuous Deployment
Faça uma transição gradual
Ao conversar com líderes de engenharia, a maioria concorda que a transição para CI/CD deve ser gradual. (Portanto, não espere implantar continuamente 3 novas funcionalidades no segundo dia de adoção do CI/CD — isso vai acabar muito, muito mal.)
É recomendável começar com mudanças menores e pequenos blocos de trabalho. Em vez de tentar passar de realizar releases três vezes por ano para várias vezes por dia, defina uma meta para realizar releases a cada duas semanas, depois semanalmente, depois diariamente, e, eventualmente, você estará fazendo releases várias vezes ao dia.
Almeje o Continuous Delivery primeiro, depois mova-se para o Continuous Deployment
Nossa outra sugestão é se aproximar primeiro do Continuous Delivery antes de chegar ao Continuous Deployment. Claro, Continuous Deployment é o objetivo final, mas o Continuous Delivery é um pouco mais fácil de estabelecer (e precisa estar bem estabelecido para que o Continuous Deployment aconteça, de qualquer forma).
Lembre-se de que o Continuous Delivery é o processo de garantir que seu código na branch principal esteja sempre em um estado de implantação — ou seja, você pode fazer deploy quando quiser, mas ele não será automaticamente implantado. A partir daqui, você ainda terá que apertar manualmente “deploy” para liberar o código para os usuários finais. Recomendamos almejar o Continuous Delivery antes do Continuous Deployment por algumas razões.
Primeiro, passar direto para o Continuous Deployment é um grande salto para equipes acostumadas a releases manuais e a revisar manualmente seu código antes de ser lançado para os usuários. O Continuous Delivery é uma adaptação mais fácil, pois permite que você verifique tudo antes de ser liberado para seus usuários finais.
Além disso, tornar-se confortável com o Continuous Delivery antes do Continuous Deployment dá a chance de validar e confiar em seus testes. Quando você configura o Continuous Deployment, seus usuários finais veem todo e qualquer código que tenha passado pelos seus testes, então você precisa ter certeza de que seus testes são sólidos (ou seja, que eles não estão deixando passar código com bugs e/ou que os bugs que passam não são críticos).
Com o Continuous Delivery, você tem a chance de ver como o seu código está funcionando e validá-lo manualmente depois de ter sido testado. Se você notar muitos erros e bugs no seu código no ambiente de produção, isso provavelmente significa que algo está errado com seus testes. Assim, começar com Continuous Delivery lhe dá a chance de validar e garantir que seus testes estão realmente cumprindo seu papel e não deixando passar código com bugs antes de você avançar para o Continuous Deployment.
Comece com mudanças simples e de baixo risco
Nosso último conselho é começar com mudanças simples e atualizações de baixo risco ao se ajustar ao CI/CD. Admitidamente, ajustar-se ao CI/CD leva tempo, confiança e adesão de toda a sua organização. Automatizar seus testes e deploys pode parecer assustador no início — especialmente para aqueles responsáveis por construir os testes. Começar com pequenas mudanças de código e atualizações de baixo risco permite que sua equipe se ajuste ao processo e ganhe confiança nele antes de passar para releases de funcionalidades maiores.
Uma vez que você se sinta confortável com Continuous Integration e Continuous Delivery, o Continuous Deployment o aguarda. Aqui estão alguns passos práticos que você pode seguir para configurar um pipeline de CI/CD adequado (mesmo nas bases de código mais antigas e complexas):
Passo 1: Configure seu pipeline
O primeiro passo óbvio é configurar um pipeline de CI. Isso requer a construção de seus testes e a configuração de um pipeline que garante que seu código pode ser mesclado uma vez que tenha passado por esses testes.
Passo 2: Testes
O segundo passo é ter um conjunto de testes (que você confie!) em vigor.
Uma vez que seu código passe por esses testes automatizados com CD, ele será liberado. Portanto, você precisa garantir que seus testes sejam confiáveis o suficiente para que você não precise revisar manualmente seu código depois, porque você não apertará manualmente “deploy” uma vez que seu código passe por eles.
No início, seus testes não precisam ser extremamente complexos, pois o CD não será usado para mudanças complexas de imediato. O foco deve estar em testes de ponta a ponta que, no mínimo, confirmem que o site ou plataforma funciona conforme o esperado pela equipe. Por exemplo, esses testes básicos de ponta a ponta garantiriam que os usuários possam acessar, fazer login e realizar ações essenciais dentro da plataforma.
Eventualmente — quando você tiver um pipeline de CI/CD totalmente desenvolvido e estiver usando-o para quase todos os deploys, independentemente do tamanho e impacto — você vai querer ter testes mais complexos e abrangentes. Mas para o propósito de hoje de apenas começar com CI/CD, testes básicos são tudo o que você precisa.
Passo 3: Configure logging centralizado ou gerenciamento de erros
Isso garante que, quando um erro acontecer (ou seja, quando um código com bugs passar por todos os seus testes automatizados e for liberado para seus usuários finais), você seja capaz de rastrear de onde ele veio e corrigi-lo rapidamente. Não estamos de forma alguma sugerindo isso para criar uma cultura de culpa. É simplesmente um passo necessário quando você está automatizando grande parte do seu processo de teste e deploy.
Além disso, a boa notícia sobre CI/CD é que você está implantando mudanças de código menores e incrementais várias vezes ao dia, em vez de grandes mudanças de código com um impacto massivo de mudanças uma vez por mês. Assim, usar uma plataforma de gerenciamento de erros com CI/CD é um processo muito mais simples, já que as releases são tão pequenas que é mais fácil encontrar exatamente onde está o problema.
Passo 4: Use feature flags
Já mencionamos que a transição para Continuous Deployment pode ser um grande ajuste para equipes acostumadas a revisar manualmente cada detalhe.
Automatizar o processo de testes e deploys acelera tudo, eliminando a necessidade de intervenção humana, o que permite que seus desenvolvedores passem mais tempo codificando. No entanto, abrir mão dessa intervenção manual pode ser assustador. Usar feature flags junto com o CI/CD é como adicionar uma camada extra de segurança, uma rede de proteção que aumenta a confiança da equipe nos deploys automáticos.
As feature flags permitem que os desenvolvedores ativem ou desativem funcionalidades sem a necessidade de fazer um novo deploy do código. Elas funcionam como uma rede de segurança para qualquer equipe de desenvolvimento que utiliza CI/CD, já que facilitam o processo de desativar uma funcionalidade que não está se comportando corretamente. Assim, caso um código com defeito passe pelos testes automatizados e chegue às mãos dos seus usuários, você pode simplesmente desligar a funcionalidade e seus usuários voltarão a utilizar a funcionalidade anterior — tudo isso sem a necessidade de fazer um novo deploy ou atualizar a aplicação.
Implementação de CI/CD em Sistemas Legados
A adoção de CI/CD em uma base de código completamente nova é geralmente mais simples, pois permite a escolha de ferramentas e processos desde o início, além de possibilitar a criação de testes do zero. No entanto, é perfeitamente possível implementar CI/CD em bases de código existentes e mais antigas, mesmo que sejam sistemas legados.
Muitas organizações já conseguiram migrar grandes bases de código para um pipeline de CI/CD funcional. Esse processo envolve a transição de releases esporádicas, como a cada poucos meses, para um pipeline de Continuous Delivery, que possibilita realizar releases com muito mais frequência, como semanalmente. Durante essa transição, aprendem-se lições valiosas sobre o que testar, como otimizar as builds, e como automatizar os deploys, preparando o caminho para a implementação de um pipeline de Continuous Deployment totalmente funcional.
Os Benefícios do Continuous Deployment
Aumenta a frequência de deploys e diminui o tempo de ciclo
O Continuous Deployment nos permitiu colocar código em produção em apenas 15 minutos. Esse é um grande aumento na frequência de deploys em comparação ao ciclo de lançamento de 3,5 meses que tínhamos com o Taplytics. Agora, podemos lançar e iterar mais rápido, responder ao feedback dos usuários em tempo real e fazer deploys de código várias vezes ao dia.
Aumenta a produtividade dos desenvolvedores
Quando seus desenvolvedores não precisam testar e implantar o código manualmente, eles ganham muito mais tempo para realmente escrever código. O Continuous Deployment (CD) alivia significativamente os desenvolvedores do processo de QA e deploy, permitindo que eles concentrem seu tempo e energia no desenvolvimento de novas funcionalidades e melhorias.
Melhora a qualidade do trabalho dos desenvolvedores
Automatizar os testes e deploys com CI/CD fez com que nossos desenvolvedores realmente refletissem sobre o trabalho que estão fazendo. Eles precisam se perguntar “Este código está bem testado?” e “Ele está bem planejado?” já que dependem do sistema de verificações que eles mesmos criaram para os testes automatizados.
Facilita a depuração
Qualquer release feita com CD é pequena o suficiente para que seja muito fácil identificar bugs. Em releases grandes, com mudanças extensas, pode levar semanas para encontrar um bug. Com o CD, se algo der errado, você sabe a qual release o bug pertence, e a correção do problema leva menos tempo.
Menos estresse, mais confiança
Como fazemos deploys de pequenas e incrementais mudanças com CD, os riscos são muito menores e nossos desenvolvedores não sofrem mais com a “ansiedade pós-lançamento” que sentiam com os lançamentos mensais. Sem os grandes lançamentos, podemos enviar o código com confiança, sabendo que, provavelmente, nenhuma de nossas mudanças irá impactar ou quebrar toda a nossa plataforma. E se houver algum problema no código, sabemos que podemos facilmente reverter as mudanças ou desativar a funcionalidade com feature flags.
Conclusão
A transição para o Continuous Deployment é uma grande mudança que requer o comprometimento de toda a sua organização para funcionar. Embora possa levar algum tempo para se ajustar e possa haver um período de tentativas e erros na configuração do pipeline, o período de adaptação vale a pena. Uma vez que seu pipeline de CD esteja configurado e funcionando corretamente, você estará implantando com mais frequência e automatizando mais do que jamais imaginou ser possível.
Treinamentos relacionados com essa postagem
