Usamos Phinx para gerenciar nossos scripts de migração de banco de dados no RelayRobin. Assim como todas as outras ferramentas de migração existentes, isso permite uma lista previsível de alterações para construir o esquema do nada até o estado mestre mais recente.
Mas sempre há o problema de fusões de VCS, criando lacunas na lista de alterações, pisando uns nos outros, etc. E outro grande problema específico da empresa é a prova de bala de atualizações de nó de cluster contínuo – seria ótimo se o código do aplicativo em execução pudesse ser comparado a versão do esquema no banco de dados em relação à versão esperada. Dessa forma, os nós desatualizados podem recusar normalmente o serviço no esquema que é muito novo ou muito antigo.
A forma como eu adoraria lidar com as migrações é aplicando um modelo semelhante ao Git. Cada etapa de migração é uma forma de alterar o esquema de um estado para outro, como um commit do Git que é uma representação do delta entre os instantâneos do repo. A parte “inativa” de qualquer etapa de migração é o reverso das alterações delta do esquema. O aplicativo deve declarar qual estado do esquema (identificado por algum tipo de ID simbólico, provavelmente) ele requer para persistir. Mais ou menos como o ponteiro de commit “HEAD” ou “master” em um repositório Git apontando para o estado mais recente naquela cadeia de deltas.
Portanto, quando dois desenvolvedores alteram o esquema independentemente, o que acontecerá é que o ponteiro “HEAD” na base de código irá disparar um conflito de mesclagem. E quem quer que esteja resolvendo o conflito terá que criar uma migração “mesclada” – se o esquema bifurcou do estado comum A para os estados B e C, essa migração saberá como aplicar alterações para trazê-los de volta ao estado comum D.
A grande vitória nessa abordagem também é a presença desse ponteiro de estado de esquema “HEAD”. Ele permite que o aplicativo detecte e falhe rapidamente quando está se comunicando com um estado de banco de dados obsoleto (durante uma atualização de cluster, falha na migração, etc). E isso evita muitos bugs sutis.
Este é apenas um conceito incompleto de uma abordagem baseada em gráficos para migrações de banco de dados e também tem alguns problemas. Mas seria bom chegar mais perto de resolver os problemas com as ferramentas de gerenciamento de migração de banco de dados existentes.