Estimativa de uma migração de banco de dados

“Adicionar uma coluna” é uma migração de uma linha. A estimativa não se refere à coluna.

As migrações de esquema operam em dois tempos. Um é o do SQL: geralmente rápido, geralmente mecânico. O outro é o cronograma operacional: por quanto tempo a tabela fica bloqueada, o que acontece em caso de gravações simultâneas, como reverter o processo se algo der errado e qual é o plano de contingência caso a execução se prolongue além da janela de implantação. A equipe decide sobre o SQL porque é isso que está no ticket. O trabalho, porém, ocorre de acordo com o segundo cronograma.

Em uma mesinha, os dois relógios são iguais e a história é realmente insignificante. Em qualquer mesa que realmente importe, eles não são. A estimativa precisa levar em conta o preenchimento, a estratégia de implantação e a reversão — algo que alguém precisa ter ensaiado antes que a implantação chegue nem que seja perto da produção.

O que é dito na sala

Backend: “É só um ALTER, a migração é concluída em um segundo.”

SRE: “Na tabela de pedidos? Com os bloqueios ativados? Às 15h?”

DBA: “Como estamos preenchendo as linhas existentes?”

SRE: “Qual é o procedimento de reversão se a implantação falhar no meio do processo?”

Destaque: “O caminho de leitura permite que a coluna fique nula por uma hora?”

Perguntas que vale a pena fazer antes de votar

• Qual é o tamanho da tabela: milhares, milhões, centenas de milhões de linhas?
• Ferramenta de migração online ou comando ALTER no próprio banco de dados?
• Estratégia de preenchimento: síncrona, tarefa em lote, gravação dupla?
• O que o caminho de leitura faz durante a janela de implementação?
• Reversão: apenas para frente, ou podemos reverter o esquema?
• Alguém já seguiu o manual de procedimentos de plantão para essa migração?

Se metade da sala está votando em “o SQL” e a outra metade em “a implantação”, você não tem um problema de números; você tem duas histórias que fingem ser uma só. Separe-as: a alteração no esquema é um ticket, e o plano de atualização retroativa e de implantação é outro.

Faça uma estimativa para a implementação e a reversão, não para o ALTER. É no segundo relógio que reside o risco.

Consulte como estimar uma migração de dados para a versão válida para todos os sistemas e os outros exemplos práticos de estimativa. Inicie uma sessão gratuita de Planning Poker assim que o plano de implementação estiver esboçado.