O que uma atualização do Rails realmente quebra

Uma atualização são quatro riscos diferentes vestindo o mesmo número de versão. Eles falham em momentos diferentes, em lugares diferentes, com raios de impacto diferentes, e tratá-los como uma coisa só é o motivo de as atualizações parecerem imprevisíveis.

Os quatro tipos de quebra

Quebra no carregamento. Uma constante mudou de lugar, um método foi removido, um initializer chama algo que não existe mais, e a aplicação se recusa a subir. É o tipo mais amigável: é barulhento, imediato e impossível de ir para produção por acidente.

Quebra nos testes. A aplicação sobe, mas o comportamento mudou. Um padrão foi invertido, a ordem de um callback mudou, um serializador grava uma string diferente. A sua suíte pega isso se o comportamento estiver coberto.

Quebra em execução. A aplicação sobe, os testes passam, e então uma requisição real segue um caminho que nenhum teste segue. É o tipo caro, porque quem descobre são os usuários.

Quebra de dados. A versão nova grava algo que a versão antiga não consegue ler: um cookie de sessão, uma entrada de cache, o payload de um job na fila. Ela só aparece enquanto as duas versões rodam ao mesmo tempo, e é isso que um deploy gradual garante.

flowchart TB
  U["Atualização do Rails"] --> L["Carregamento: não sobe"]
  U --> T["Testes: suíte fica vermelha"]
  U --> R["Produção: os usuários acham"]
  U --> D["Dados: antigo e novo discordam"]
  L --> C1["Mais barato. Achado em segundos"]
  T --> C2["Barato, se estiver coberto"]
  R --> C3["Caro. Precisa de rollback"]
  D --> C4["Caro e grudento. Sobrevive ao rollback"]

Por que o último é diferente

Os três primeiros se resolvem corrigindo o código. Faça o rollback e o problema vai junto.

A quebra de dados não volta com o rollback. Se a versão nova gravou uma entrada de cache num formato que a antiga não consegue interpretar, o rollback deixa essa entrada lá, e o código antigo agora quebra com dados que ele não gravou. O rollback piorou as coisas.

Cada mitigação mais adiante neste curso existe por causa dessa assimetria. Dual boot, inverter padrões um de cada vez e a janela de duas versões são, todos, jeitos de nunca deixar a quarta categoria acontecer, porque é a única que você não consegue desfazer com um novo deploy.

Como esta aplicação está hoje

Rails 8.1.3.1 sobre Ruby 4.0.1, 31 gems no Gemfile, config.load_defaults 8.1 em config/application.rb e nenhum arquivo config/initializers/new_framework_defaults, o que significa que todos os padrões desta versão já estão ligados. Não há nada pendente.

Essa é a posição boa, e não é a normal. Muitas aplicações carregam um arquivo de padrões com metade das linhas ainda comentadas: uma lista de atualizações concluídas no papel, e não na prática.

flowchart LR
  A["Bundle atualizado"] --> B["Sobe"]
  B --> C["Suíte verde"]
  C --> D["Padrões virados"]
  D --> E["Realmente atualizado"]
  A -.->|"onde a maioria<br/>das aplicações para"| C

A ordem que decorre disso

Primeiro subir, depois os testes, depois os padrões, depois produção, e nunca dois deles no mesmo deploy. Cada passo diz algo de que o passo seguinte precisa, e juntar dois deles faz uma falha deixar de apontar para uma causa.