Alterar um sistema existente em segurança

Identifique os contratos em torno da alteração

O software existente tem componentes que o invocam, dados armazenados, tarefas agendadas e procedimentos operacionais. Algumas dependências não são visíveis no ficheiro que pretende editar. Um agente pode produzir uma alteração correta no contexto local que viola um destes contratos.

Antes da implementação, identifique os componentes que leem e escrevem os dados afetados. Examine as rotas, as tarefas em segundo plano, os relatórios e as integrações externas. Verifique se outras equipas ou versões antigas dos clientes dependem do comportamento atual.

Peça ao agente que apresente as evidências que sustentam este mapa. Um resultado de pesquisa é um ponto de partida útil, mas chamadas dinâmicas e consumidores externos podem exigir que um responsável confirme a dependência.

Torne observável o comportamento atual

Num módulo mal documentado, acrescente verificações específicas do comportamento que tem de permanecer estável. Estas verificações descrevem o contrato atual. Não demonstram que todos os comportamentos existentes são desejáveis.

Se o comportamento atual entrar em conflito com um requisito, registe o conflito. Não preserve uma falha de segurança apenas porque um teste a registou. Obtenha a decisão necessária para distinguir o comportamento pretendido de um defeito.

Use dados de teste realistas e não sensíveis. Inclua estruturas de dados antigas e registos incompletos quando estes possam existir. Um novo esquema testado apenas com dados recém-criados pode ocultar problemas de migração.

Reveja a transição entre versões

Considere uma mudança fictícia do nome customer_name para display_name. Uma mudança imediata pode impedir o funcionamento de uma instância antiga da aplicação durante o deployment. Atualizar ambos os ficheiros num pull request não torna o deployment atómico.

Uma abordagem faseada pode preservar a compatibilidade:

1. Acrescente o novo campo sem remover o antigo.
2. Defina como as novas operações de escrita mantêm a consistência dos valores necessários.
3. Preencha os registos existentes com um processo que possa ser reiniciado.
4. Verifique se o preenchimento está completo e como se comportam os componentes que leem os dados.
5. Passe esses componentes para o novo campo.
6. Remova o campo antigo apenas quando já não houver componentes que o utilizem.

O método exato depende da base de dados e dos padrões de escrita. A escrita em dois locais pode introduzir inconsistências se uma das operações falhar. Pode ser necessária uma transação na base de dados ou outro método explícito de sincronização. Não aplique este exemplo sem verificar as garantias do sistema.

Martin Fowler descreve esta transição geral como parallel change, também denominada expand-and-contract. A ideia central é garantir uma transição compatível antes da remoção.

Planeie a recuperação separadamente do rollback

O rollback do código repõe uma versão anterior da aplicação. Não anula automaticamente uma migração de dados. A versão antiga pode não compreender os novos dados. Uma migração destrutiva pode remover informação que o rollback do código não consegue recuperar.

Identifique a ação de recuperação para cada passo. Pode ser seguro retomar um processo de preenchimento de registos que permita reinício. Uma transformação incorreta pode exigir uma correção a partir dos dados de origem preservados. Uma operação destrutiva pode exigir um procedimento de restauro verificado.

Pergunte quem é responsável pela decisão de recuperação e quanto tempo esta pode demorar. Não trate «temos cópias de segurança» como evidência de que a recuperação cumpre o requisito do serviço.

Mantenha a alteração fácil de rever

Separe a limpeza sem relação com a alteração funcional. Inclua no pull request o plano de compatibilidade, os resultados da verificação e as condições para a remoção. Assinale o ponto a partir do qual o rollback exige trabalho adicional.

Um agente pode ajudar a examinar os componentes consumidores e a preparar o código de migração. Continua a ser necessário que a pessoa responsável aceite o plano de transição e recuperação. A conceção final é apenas uma parte de uma alteração segura.