Continuous Delivery ou CD é uma abordagem no desenvolvimento de software que busca automatizar e simplificar o processo de entrega de código em ambientes produtivos de forma rápida, segura e confiável. do desenvolvimento, o principal objetivo do Continuous Delivery é permitir que as equipes entreguem a alteração de código em produção de maneira eficiente e com baixo custo, garantindo que o software possa ser implementado de forma automatizada e sem problemas, sendo requerido apenas uma aprovação manual. Bom, nessa etapa geralmente a gente passa por todo o ciclo de integração contínua e aqui a gente está falando basicamente já de dentro do ciclo do desenvolvimento de software aquela segunda parte que a gente chama de shift-right. Então no shift-right a gente já tem ali as etapas de provisionamento, por exemplo, no ambiente de produção. O que a gente está falando aqui é que com o Continuous Delivery a gente consegue fazer essa entrega, a gente consegue fazer esse deployment, todavia a gente precisa de um registro em alguma ferramenta, como por exemplo um giro ou um serviço sinal, e essa etapa de aprovação ela acontece de forma manual então uma vez que eu esteja pronto para fazer a implementação do meu software em produção a gente vai abrir um registro de change, de gemude vai passar de repente por algum por alguma equipe que vai analisar o risco de implementação, vai passar de repente por algum por alguma equipe que vai analisar o risco de implementação o horário, qual que é o ambiente que a gente está mexendo pode ser uma equipe de repente de governança ou pode ser de repente algum especialista algum príncipe ou alguém com um cargo técnico um pouco maior dentro da empresa, vai fazer toda uma assunção de risco, vai aprovar e a partir daí é que a gente vai estar pronto para poder fazer o deployment em produção. Continuous Deployment. Continuous Deployment, também CD, assim como Continuous Delivery, passa por todos os processos de integração e teste, porém para implementação e produção não é requerida uma aprovação manual. Isso significa que novas funcionalidades, correções de bugs e melhorias são implementadas automaticamente para os usuários assim que estiverem prontas e testadas. Por questões de governança e qualidade, a TIM já ainda é registrada, porém a aprovação acontece também de forma automatizada servindo apenas como registro. Bom, então foi o que eu comentei. Se a gente for parar para analisar friamente qual que é a principal distinção entre Continuous Delivery e Continuous Deployment. Em um, a gente vai ter uma etapa, um gate ali, onde requer uma aprovação manual. No outro, a gente consegue fazer 100% de forma automatizada e por ser de forma automatizada, geralmente a gente consegue fazer ali implementações no meio do dia, a gente consegue fazer duas, três, quatro, cinco implementações no meio do dia ali, quebrando duas, três, quatro, cinco implementações no meio do dia ali, quebrando nosso software em pequenas partes, né? E, obviamente, tendo toda a garantia de que a gente passou por todas as etapas, fazer a implementação desse software em produção sem passar por nenhum tipo de aprovação manual. E aí a gente só faz um registro em alguma ferramenta para a gente conseguir o teu tracking, conseguir o teu registro. Geralmente a gente registra ali qual que foi, por exemplo, o commit, o código do PR que a gente está submetendo para a produção. Mas depois a gente conseguir ali por questões de auditoria, a gente conseguir saber exatamente o que foi implementado, quando foi implementado, em que momento foi implementado. Vamos ver alguns benefícios aqui de forma geral do deployment contínuo. Bom, como eu disse, a gente tem uma automação completa. Então, as equipes, elas configuram ali uma pipeline de deployment, de implantação, com um conjunto de etapas automatizadas que o código deve passar antes de ser implementado em produção. Então, essas etapas, elas devem incluir testes automatizados, revisão de código, aprovações manuais ou não, mas aqui a gente pode estar falando de repente de code review, uma etapa de desenvolvimento e homologação, então produção a gente já conseguiria passar de forma automática, por exemplo. Deployments contínuos. Novas versões de softwares, elas são lançadas continuamente, muitas vezes ao longo do dia, garantindo que os usuários tenham acesso às últimas funcionalidades e correção o mais rápido possível. Então foi como eu comentei, se a gente conseguir ter a garantia de que o nosso software é confiável, de que passou por todas as etapas, aquilo que a gente desenvolveu e testou é aquilo que está indo para a produção, a gente consegue ter um altíssimo nível de que provavelmente aquele software vai parar de pé e não vai dar nenhum tipo de problema. Feedback rápido. Como as implantações são feitas de forma automática, qualquer problema que surgir em produção pode ser identificado e corrigido rapidamente, garantindo uma rápida interação e melhoria contínua. Os rollbacks podem ser realizados de forma automática. problema numa implementação, sistemas de implantação contínua, eles geralmente incluem mecanismos para fazer rollback de forma automática e reverter aquela alteração para uma versão anterior, para uma versão estável. E testes em produção. Embora os testes automatizados sejam realizados antes da implantação, a implantação contínua também permite testes em produção, uma vez que as alterações são lançadas para um conjunto ou um subconjunto de usuários antes de serem disponibilizadas para o todo. Aqui a gente pode se aprofundar mais para frente, existem N formas, metodologias, estratégias para a gente fazer deployment em produção mas uma delas por exemplo seria a gente fazer um caner ou fazer um teste AB onde a gente habilita um pool específico de usuários para receber aquelas funcionalidades faz toda uma validação com observabilidade valida se está girando o erro ou não se está tendo erro a gente já consegue reverter essa alteração e entender porque deu erro para isso obviamente a gente tem que ter bastante métrica, tem que ter uma observabilidade bem bacana já no ambiente ou a gente poderia de repente habilitar um teste AB, onde a gente pega um pool de clientes somente e habilita essa funcionalidade para eles. Então, existem any forms, mas o fato é que quando a gente fala de Continuous Deployment, o nosso leque para fazer essas implantações e conseguir ter estratégias distintas para a gente saber se a gente permanece ou não com aquela versão é um leque infinitamente maior do que sem esse tipo de mecanismo, né?