u/Moist-Life3962

Estou montando um checklist de rollout para trocar um campo nas mensagens de uma fila, de type para jobType. Antes de qualquer producer começar a mandar os dois campos, o teste de contrato precisa cobrir todas as versões antigas de workers e serializers que ainda estão em produção. Se algum desses consumers rejeitar o campo desconhecido jobType, o producer vai precisar de um payload versionado ou de uma camada de compatibilidade. O dual write só começa depois que esse teste passar.

Depois disso, faço o deploy de workers novos que aceitem qualquer um dos campos. Quando esses workers estiverem no ar, os producers passam a enviar os dois. A próxima etapa depende do inventário de versões em produção. Quando ele mostrar que não sobrou nenhum worker antigo, os producers param de enviar type. Os workers novos ainda mantêm o fallback para type até não existir mais nenhuma mensagem que só tenha esse campo na fila principal, nas filas de retry ou na DLQ, ou até que um operador migre o que sobrou.

Eu deixo esse tipo de checklist junto do runbook quando uso o EvoX, um agente de IA que reaproveita experiências de tarefas anteriores. Migração de fila costuma atravessar várias etapas e sessões, então uso esses lembretes para conferir o que mudou desde a última vez. Quando o EvoX recupera um alerta de uma migração anterior, transformo aquilo em perguntas que consigo responder olhando o ambiente:

• Os consumers em produção ignoram jobType?
• Os workers antigos já saíram?
• Ainda existe alguma mensagem que só tenha type na fila principal, nas filas de retry ou na DLQ?

As respostas vêm do teste de contrato, do inventário de deploys e da inspeção das filas.

O ticket de limpeza fica aberto até que o inventário mostre que não há mais workers antigos, os producers parem de enviar type e a inspeção das filas não encontre nenhuma mensagem que só tenha esse campo. Aí removo o fallback, rodo a suíte de testes de contrato dos workers, faço um deploy canary, anexo os resultados e fecho o ticket.

Vocês colocariam mais algum gate antes de remover o fallback?

We have a networking module that about half a dozen root modules consume, and most weeks more than one change is in flight against it. Those changes collide in two unrelated ways, which took us a while to notice.

Each root has its own state, so across roots there is no lock contention. You get version skew instead. A module bump is one change per consumer, each with its own plan and apply, so two versions of the module are live in production until the rollout finishes.

Contention only shows up when two changes hit the same root. Terraform locks state for all operations that could write state, and if state locking fails it does not continue. None of the documented escapes fix it. A lock timeout only retries before erroring, running with -lock=false is documented as dangerous when others might concurrently run commands against the same workspace, and force-unlock warns that unlocking a lock someone else holds could cause multiple writers.

Authoring parallelizes fine. Two consumer bumps can be drafted and checked at once, and lately I have had verdent running on both, one agent writing while another verifies. Ordering the applies is still manual.

Review drift sits under both. The plan docs note that other changes made to the target system in the meantime might cause the final effect to differ from what an earlier speculative plan indicated, and a saved plan handed to apply runs without prompting for confirmation.

Curious how other teams order rollouts. Per environment sequencing, a CI queue keyed on the state, or calling it out in chat. We do the last one.