Deploy na sexta-feira, projeto 90% pronto, dedos gigantes e o maravilhoso mundo dos hotfixes

Finalmente chegou.

Depois de meses de rumores, vazamentos e especialistas analisando uma foto borrada com 14 pixels, a Apple lançou o novo iPhone.

• Novo processador.
• Nova câmera.
• Mais inteligência artificial.
• Mais recursos.

E, provavelmente, uma nova forma de fazer você olhar para o seu iPhone de 11 meses e pensar:

"Acho que esse aqui já está meio velho."

Mas vamos imaginar uma coisa.

E se o novo iPhone tivesse sido desenvolvido como um verdadeiro projeto Go Horse?

Segunda-feira, 8h03

Reunião de emergência.

O Product Manager entra na sala:

Precisamos lançar o novo iPhone sexta-feira.

O Tech Lead olha para o calendário.

Sexta-feira desta semana?

Sim.

Mas estamos na segunda.

Eu sei.

E o projeto?

Está 90% pronto.

E os outros 10%?

Colocamos na próxima atualização.

Pronto.

Projeto aprovado.

Essa é uma das maiores invenções da engenharia de software:

entregar o projeto antes de terminar o projeto.

Não está incompleto.

É entrega incremental.

O ciclo de desenvolvimento

O projeto começa mais ou menos assim:

Ideia
  ↓
Reunião
  ↓
Outra reunião
  ↓
Protótipo
  ↓
Vazamento
  ↓
Internet descobre tudo
  ↓
Correria
  ↓
Desenvolvimento
  ↓
"Funciona aqui"
  ↓
Produção
  ↓
Apple Event
  ↓
Hotfix

E pronto.

Temos um produto.

O problema da obsolescência

Tecnicamente, seu iPhone antigo continua funcionando e isto é um problema.

Ele funciona perfeitamente.

Só que agora existe um novo.

Com uma câmera um pouco melhor, um processador mais rápido, mais IA e uma nova cor.

Você olha para o seu aparelho e pensa:

"Esse negócio já está ultrapassado."

Não está.

Mas agora ele tem dois anos.

Na tecnologia, dois anos equivalem aproximadamente a 14 anos humanos.

É a obsolescência emocional.

QA? Testa aí no seu iPhone

Imagine a equipe de QA:

Encontramos um bug.

Qual bug?

Quando abre a câmera, gira o aparelho, recebe uma ligação, ativa a IA e coloca o aparelho em cima da mesa, existe uma chance de o aplicativo fechar.

Qual a frequência?

0,0003%.

Então está aprovado.

No Go Horse, existe uma regra simples:

Se ninguém conseguiu reproduzir, não é bug.

É comportamento intermitente.

E os dedos?

Existe também um pequeno problema de ergonomia.

Cada geração parece encontrar mais coisas para colocar na tela.

Botão.

Câmera.

Gesto.

Controle.

Menu.

Outro menu.

IA.

Até que o próximo iPhone provavelmente venha com os seguintes requisitos mínimos:

iPhone Pro
iOS atualizado
Internet
Bateria
Mão Pro
Dedos gigantes

Porque em algum momento será necessário aumentar a tela e quem sabe até dobrar ela.

Será necessário também aumentar a mão.

Como resolver filas no lançamento

Todo lançamento tem um problema:

muita gente quer comprar.

Isso gera filas.

Filas geram tumulto.

Tumulto gera custo.

Então surge a solução arquitetural:

aumentar o preço.

Se 100 mil pessoas querem comprar e somente 20 mil conseguem pagar, pronto.

Problema resolvido.

Não temos mais 100 mil pessoas na fila.

Temos 20 mil compradores.

E 80 mil pessoas dizendo:

"Ano que vem eu compro."

DevOps aplicado à logística.

Não escalamos a infraestrutura.

Reduzimos a demanda.

Deploy na sexta-feira

O ambiente de desenvolvimento está perfeito.

Homologação também.

Então alguém pergunta:

Podemos fazer o deploy?

Pode.

Testou?

Testei.

Funcionou?

Na minha máquina.

Pronto.

Produção.

Cinco minutos depois:

Gente, alguém sabe quem tem acesso à produção?

Silêncio.

João?

João está de férias.

E começa a sequência de atualizações

O produto foi lançado.

Todo mundo comemora.

Só que agora começam as atualizações.

iOS 27.0

Lançamento oficial.

Tudo lindo.

iOS 27.0.1

Pequenas correções de bugs e estabilidade.

Tradução:

"Alguma coisa quebrou."

iOS 27.1

Melhorias e novos recursos.

Tradução:

"Não deu tempo de colocar tudo na versão anterior."

iOS 27.2

Mais correções e melhorias.

Tradução:

"As correções criaram outros problemas."

E assim seguimos.

Projeto entregue.

90% pronto.

Os outros 10% serão entregues em parcelas.

É quase um financiamento de software.

O projeto nunca termina

Todo desenvolvedor sabe que não existe versão final.

Existe:

produto-final.zip

produto-final-v2.zip

produto-final-v2-corrigido.zip

produto-final-v2-corrigido-agora-vai.zip

produto-final-v3.zip

produto-final-v3-definitivo.zip

E quando finalmente funciona:

Não mexe.

Observabilidade

É aí que entra uma diferença importante entre Go Horse e DevOps.

No Go Horse:

Acho que está funcionando.

No DevOps:

99,97% das requisições estão abaixo de 300 ms.

No Go Horse:

Alguém reclamou.

No DevOps:

O erro aumentou 4,8% depois do último deploy.

No Go Horse:

Quem mexeu nisso?

No DevOps:

Temos logs, métricas, traces e histórico de deploy.

A diferença é simples.

Um depende de memória.

O outro depende de evidência.

Rollback

Deu problema?

No DevOps:

Faz rollback.

No Go Horse:

Dá para voltar?

Dá.

Então volta.

Não dá mais.

Por quê?

Eu sobrescrevi.

Silêncio.

Tem backup?

Tinha.

Onde?

No computador do João.

João está de férias.

A grande verdade

Talvez o problema não seja lançar rápido.

Nem ter bugs.

Nem precisar fazer atualizações.

Software complexo vai ter problemas.

O problema é quando o improviso vira processo.

Quando:

"Funciona na minha máquina"

vira estratégia de testes.

Quando:

"Depois a gente corrige"

vira planejamento.

Quando:

"Entrega 90%"

vira definição de pronto.

E quando:

"Quem tem acesso à produção?"

é uma pergunta válida em qualquer empresa.

E o próximo iPhone?

Provavelmente será mais rápido.

Terá uma câmera melhor.

Mais IA.

Mais recursos.

Uma nova cor.

E provavelmente será apresentado como:

O melhor iPhone que já fizemos.

Até o próximo.

Porque o ciclo continua:

Novo iPhone
    ↓
Usuário compra
    ↓
Usuário se acostuma
    ↓
Novo iPhone
    ↓
"Esse aqui já está velho"
    ↓
Compra novamente

Isso talvez não seja obsolescência programada.

É algo mais sofisticado:

obsolescência percebida com CI/CD.

E se alguém perguntar quem aprovou o projeto?

"Funcionava na minha máquina."