Oi pessoal, bem vindos a nossa exploração de hoje aqui no the
deep Dive. Vamos analisar juntos umas
práticas bem bem modernas. Sabe que estão mudando o jeito
de fazer software deployment contínuo e entrega contínua.
A gente está usando como base o livro engenharia de software
Moderna, do Marco Túlio Valente. Olha, quem já passou por
lançamento de software talvez lembre daquela tensão, né?
Aquelas noites sem dormir, o medo de quebrar algo em
produção. O objetivo aqui é justamente
entender como essas práticas contínuas é tentam mudar isso.
Vamos desvendar o deploma de contínuo, A Entrega contínua.
Vê as diferenças porque falam tanto delas e como funcionam na
prática, segundo a nossa fonte aqui.
Muitas equipes já usam integração contínua, o CI.
O código é integrado direto no repositório principal, né?
Mas assim, só integrar não garante que o software tá pronto
para o usuário, certo? Às vezes é algo completo que
ainda falta a polir. É aí que o próximo passo fica
importante. O que rola depois que o código
tá integrado e os testes básicos passaram.
Exato. É.
É nesse ponto que entra o diploma entre contínuo o CD.
Ele pega essa base da integração contínua, onde o código já é
verificado direto, né? E leva a automação pra um outro
nível. A filosofia é bem simples na
teoria, mas olha poderosa na prática.
Todo o comitê aprovado no brent principal, geralmente o master
ou o man. E que passa em toda esteira de
testes, vai automaticamente para a produção.
Automaticamente, tipo, sem ninguém apertar um botão de vai.
Exatamente. E essa é a grande virada, sabe?
Não tem uma pessoa ali decidindo, Ah, esse pedaço de
código pode ir. Se ele passou por todo o
processo automatizado de validação, que tem que ser bem
completo, bem rigoroso, ele vai para a produção e a gente tá
falando de um processo que pode levar horas ou às vezes, sei lá,
minutos, dependendo. Da complexidade da
infraestrutura, a velocidade com que uma mudança chega no usuário
final é nossa, diminui drasticamente.
O material detalha um pouco esse fluxo, né?
Como seria tipo um ciclo normal nesse modelo?
Sim, sim. O fluxo é bem claro.
Começa com o desenvolvedor ali na máquina dele, podando
testando localmente normal. Aí ele faz o comit para o
repositório central. Nisso, o servidor de CICD entra
em ação. Primeiro, ele compila roda os
testes mais rápidos, os unitários, para garantir que a
lógica daquele pedacinho está OK, isso a cada comit.
Ok, até aí parece bastante com OCI que a gente já conhece, onde
que o deployment contínuo se diferencia mesmo?
A diferença crucial vem logo depois, de tempos em tempos,
talvez algumas vezes por dia, o servidor pega os comities
recentes que passaram nessa primeira fase e ainda não foram
para a produção. E aí ele dispara uma bateria de
testes bem mais parruda, digamos, testes de integração
pra ver se as partes conversam, né?
Testes de interface simulando o usuário, teste de performance
pra ver se não ficou lento, segurança, enfim, uma suíte
completa para garantir a qualidade e a estabilidade do
todo. E se tudo der certo, se passar
em tudo? Se e somente se todos esses
testes automatizados passarem sem falha nenhuma.
Aí sim, esses comits são automaticamente deploiados em
produção. O código novo entra no ar e os
usuários começam a usar a nova versão quase que imediatamente,
sem aquele evento de lançamento. É uma esteira mesmo, do comit
até a produção. Nossa, isso soa muito eficiente,
mas confesso que dá um frio na barriga.
Liberar código assim direto pra produção?
Como que isso não vira um caos de bug chegando pro usuário?
É, essa é a preocupação natural, né?
E a resposta está na robustez do processo.
Todo OCID não funciona sem uma cultura de testes assim muito
forte e uma automação que seja confiável de verdade.
A confiança para liberar automático vem dessa garantia
que a suíte de testes dá se algo quebrar.
A ideia é que os testes peguem antes e se mesmo assim passar
alguma coisa. Como as atualizações são
pequenas e frequentes, geralmente é bem mais fácil
achar o problema e corrigir, fazer um roubeck ou um fixo
rapidinho. Do que naqueles lançamentos
gigantes. Entendi.
Faz sentido? E quais são os grandes
benefícios que a fonte destaca para justificar essa mudança
toda? Imagino que a velocidade seja o
principal a. Velocidade ou a redução no tempo
de ciclo, né? O tal do lead time, esse é com
certeza, um dos mais óbvios e de maior impacto.
Pensa no modelo antigo, várias funcionalidades F1F 2F 3.
Precisam ficar prontas, ser testadas juntas para formar um
pacotão de release que sai, sei lá, a cada mês.
Trimestre concedi assim que AF um tá pronta e passou nos
testes, pum vai pra produção logo depois da f 2 vai e assim
por diante. O resultado é um fluxo contínuo
de pequenas entregas, sabe, em vez daqueles blocos enormes e
espaçados. Isso parece que muda
completamente a dinâmica dos lançamentos mesmo.
Totalmente. E isso leva a outro benefício
chave, transformar os releases em não eventos.
Acaba aquela tensão do dia d sabe aquela mobilização, o
estresse, isso some. Como as liberações são pequenas,
frequentes, automáticas, elas viram parte da rotina.
Se uma funcionalidadezinha não fica pronta para aquele ciclo,
não É o Fim do mundo, ela entra no próximo, talvez no dia
seguinte. A pressão na equipe diminui
muito. E o impacto disso nos
desenvolvedores? O livro fala algo sobre
motivação, né? Fala sim e é um ponto super
relevante. No modelo de ciclos longos, o
desenvolvedor pode trabalhar meses em algo sem ter a menor
ideia se aquilo vai ser útil, se o usuário vai gostar, concedir o
feedback é quase na hora, você faz algo pequeno e em horas ou
dias. Já consegue ver por métricas,
logs ou até feedback direto como os usuários estão usando aquilo?
Saber que seu trabalho está gerando impacto rápido e ter
essa resposta é um fator de motivação muito forte.
Além da motivação, essa capacidade de lançar rápido
também deve abrir portas pra experimentar mais, imagino.
Exatamente, o cidi ajuda demais na experimentação e no
aprendizado rápido. As equipes podem lançar uma
ideia nova, talvez para um grupo pequeno de usuários, no começo
usando o featur flags, por exemplo, muito rápido.
Aí coletam dados reais de uso, analisam o impacto e decidem,
com base em evidência, se vale continuar, ajustar ou até
descartar a ideia sem ter perdido meses de trabalho.
É aquele ciclo de construir, medir, aprender.
Só que bem mais ágil. Então, olhando o quadro geral, o
diploma de contínuo parece ser bom mais que só automação, é uma
mudança mais profunda, né? Sem dúvida alguma o cid meio que
força ou talvez exija uma mudança cultural grande.
Ele obriga ex equipes a pensar em entregas pequenas
incrementais, a priorizar a qualidade automatizada, a
colaborar mais de perto. Deve teste.
Ops, o coração do devots, né? E assumir uma responsabilidade
conjunta pela produção passa se a valorizar.
O feedback contínuo e a capacidade de se adaptar rápido.
Não é só ferramenta, é mindset. É processo colaborativo.
O material até traz o exemplo do Facebook para ilustrar isso.
É uma prática. Os números que ele cita são
impressionantes. Sim, o estudo citado na fonte é
de cair o queixo. Na época, falava que cada
desenvolvedor no Facebook. Colocava em produção em média,
3.5 atualizações por semana e cada uma tinha em média umas 92
linhas de código mudadas. São milhares de deploys rolando
toda semana de forma bem descentralizada. 3 atualizações
e meia por desenvolvedor por semana isso é quase um deploy
por dia útil para cada um. Como eles conseguem gerenciar
isso tudo e manter a estabilidade?
Meu Deus? É.
Analisando esse exemplo, fica claro que, além da automação e
dos testes, tem uma habilidade que os desenvolvedores precisam
ter, que é saber quebrar o trabalho em partes muito
pequenas. Mesmo uma funcionalidade grande
e complexa precisa ser fatiada em incrementos minúsculos coisas
que possam ser feitas, testadas de forma completa e
automatizada, integradas e liberadas sozinhas em questão de
horas ou poucos dias. Sem essa disciplina de fatiar
fino o fluxo rápido do CDI simplesmente não funciona.
É uma mudança na forma de pensar o desenvolvimento, OK?
A imagem do deploy mente continho tá ficando mais clara,
automação total até a produção, ciclos super rápidos, feedback
constante parece ideal pra sistemas web, onde a atualização
é meio invisível pro usuário. Mas o próprio livro faz uma
ressalva importante, né? Ele disse que isso não serve
para todo mundo. Correto, o CD puro, esse com o
deploy automático e frequente para o usuário final.
Eles barrem em alguns tipos de sistema.
A fonte cita exemplos bem claros, software desktop, tipo
IDs, navegadores, Aplicativos móveis que você baixa da
lojinha. E software embarcado que roda
direto no hardware tipo firmware da impressora do carro.
E por que OCD não seria bom nesses casos, qual o problema?
O problema está mais na experiência do usuário e na
logística mesmo da atualização. Imagina receber notificação todo
dia para atualizar seu navegador ou o app da rede social no
celular ou o driver da impressora?
Seria muito chato, né? O processo de instalar nesses
sistemas não é invisível. Como carregar uma página web?
Geralmente precisa de uma ação do usuário, interrompe o que ele
está fazendo, gasta internet, às vezes tem que reiniciar.
Fazer isso na frequência altíssima do CDI seria
impraticável e irritar demais os usuários.
Faz todo sentido. Ninguém quer ser interrompido
toda hora. Então qual a alternativa para
esses softwares que querem agilidade?
O feedback rápido? Mas não podem usar o deplemento
continuo puro. É aí que entra A Entrega,
continua ou continius delivery? Veja que, sutil a diferença no
nome, o livro descreve como uma versão mais fraca ou uma
adaptação do diploma de continuo, pensada justamente
para esses cenários. A ideia é manter a maior parte
dos ganhos de agilidade interna, mas ter mais controle sobre
quando a versão nova chega para o usuário.
E como funciona essa adaptação? Qual a diferença chave entre
diploma de contínuo e entrega contínua?
A diferença fundamental está ali no último passo, o deploy para a
produção. Na entrega contínua.
A equipe de desenvolvimento trabalha com a mesma mentalidade
do CD, ou seja, cada comit que passa em todos os testes poderia
ir para a produção. O software está tecnicamente
pronto, está testado, empacotado validado.
A automação vai até o ponto de gerar o pacote pronto para
liberar. Mas ele não é liberado
automaticamente, então? Exato.
Na entrega contínua, a decisão final de quando liberar essa
versão que tá pronta para os usuários finais?
Essa decisão é manual, é deliberada, tem um portão final
ali. Geralmente uma pessoa, um
comitê, tipo gerente de produtos, gerente de release ou
até uma decisão de negócio mesmo, aperta o botão de deploy.
E essa decisão pode se basear em várias coisas além da parte
técnica. Campanha de marketing, janela de
mercado, feedback de beta testers, coordenação com outras
coisas. Ah, então a automação prepara
tudo, deixando a porta de saída, mas alguém tem que ir lá e abrir
a porta manualmente. É uma boa analogia?
Sim. A fonte até sugere uma distinção
útil nos termos, deployment é o ato de liberar para o usuário
usar delivery. Entrega é preparar e validar
para estar pronto para o deployment no deployment
contínuo CD. Tanto delivery quanto deployment
são contínuos e automáticos na entrega contínua, que às vezes
também chamam de CDO, que confunde um pouco.
Mas aqui a gente tá falando de contínuos delivery.
O delivery é contínuo e frequente, muitas vezes
automatizado, mas o deplamento final é controlado manual e
acontece numa cadência menor, definida pelo negócio ou pela
estratégia. Essa distinção ajuda muito a
clarear as coisas, né? Basicamente, A Entrega contínua
mantém a agilidade interna, qualidade garantida pelos
testes, mas desacopla o ritmo de desenvolvimento do ritmo de
lançamento para o usuário. Perfeito?
É isso mesmo, você tem a maior parte dos benefícios internos,
código sempre testável, integração constante, menos
risco de merge, feedback rápido interno, mas mantém o controle
do time da exposição para o cliente final.
E isso é essencial para certos produtos.
E a fonte traz exemplos de como isso funciona no mundo real para
sistemas que não são web. Traz sim, e eles mostram bem
essa cadência mais controlada. O Google Chrome, por exemplo.
Com certeza eles usam práticas contínuas internamente, mas as
versões estáveis para o público saem a cada 6 semanas, mais ou
menos. A IDE eclipse, que é um software
desktop super complexo, antes tinha um release gigante por
ano. A fonte menciona que a partir de
2019, eles mudaram para um ciclo de 13 semanas para entregar
valor mais rápido e até o app Android do Facebook, que não dá
para atualizar tão na surdina quanto a web, encurtou o ciclo
de 8 semanas para só uma semana. Analisando esses exemplos, fica
claro que, mesmo fora da web, a pressão por ciclos mais curtos é
gigante. Exatamente, a tendência é geral.
E o que é fascinante é que as motivações para essas mudanças
no Chrome, no eclipse, no Facebook, para Android são as
mesmas do depoamento contínuo na web, entregar valor mais rápido,
pegar feedback mais cedo para guiar o futuro, manter as
equipes engajadas com entregas frequentes e, claro, ser
competitivo no mercado que muda toda hora.
A diferença não tá no porquê, mas no como.
Eles adaptam a prática, né? Usam A Entrega contínua para se
encaixar nas restrições do produto e do público.
Achando um equilíbrio entre a agilidade interna e a
conveniência para usuário? Muito bom então pra gente
amarrar tudo que a gente conversou aqui.
Com base no material, temos o diploment contínuo, onde a
automação leva o código do deve até o usuário final, rápido e
frequente, ótimo pra web. E A Entrega contínua?
Que automação prepara o software para ser lançado a qualquer
hora, mas a liberação final é manual, menos frequente, mais
adequada para desktop, mobile, embarcados.
É uma ótima síntese. As 2 abordagens têm o mesmo
objetivo central, mais velocidade e confiabilidade na
entrega de software usando automação, testes rigorosos,
ciclos curtos. A escolha entre 1 e outra
depende muito do contexto do produto e do quanto o usuário
final tolera atualizações frequentes, né?
E fica bem claro que adotar qualquer uma delas não é só
instalar ferramenta, mas sim abraçar uma filosofia de
trabalho diferente. Definitivamente, como a gente
falou, essas práticas puxam ou até exigem uma transformação
cultural. Elas quebram Barreiras entre
equipes, promovem responsabilidade compartilhada.
Colocam a qualidade automatizada no centro e, no fim das contas,
capacitam as organizações a responderem muito mais rápido às
mudanças. As oportunidades no mundo onde
tudo muda o tempo todo, essa agilidade e adaptação que OCDEA
entrega continua trazem, são cada vez mais vitais.
Excelente, foi uma análise muito, muito esclarecedora
desses conceitos que são chave na engenharia de software
Moderna. Obrigada por acompanhar a gente
nessa exploração focada no deploimento contínuo e na
entrega contínua usando os insights de engenharia de
software Moderna até o próximo episódio.