Como sincronizar implantações (principalmente alterações de objetos de banco de dados) em vários ambientes [duplicado]

Eu sou o engenheiro do DevOps e um engenheiro de software de uma equipe em que, meses atrás, os desenvolvedores passaram de um banco de dados Oracle central para o banco de dados em uma VM do CentOS em seus laptops individuais. A mudança de um banco de dados central foi reduzir a dependência dos DBAs e também eliminar problemas decorrentes de dados inconsistentes.

O plano para compartilhar e garantir a sincronização do banco de dados com todos da equipe era que cada pessoa compartilhasse scripts de alteração com todos. O problema é que usamos o Skype para comunicação (apenas configuramos o slack, mas ainda precisamos começar a usá-lo totalmente) e, embora às vezes as pessoas publiquem o texto dos scripts de alteração de banco de dados, isso pode ser esquecido por alguns. O outro problema é que alguns desenvolvedores deixam de postar as alterações. Além disso, novas versões são implantadas na produção sem serem implantadas nos ambientes de teste e demonstração.

Isso representou um sério desafio para nós, especialmente para mim, que recentemente nos tornamos responsáveis ​​por garantir que nossas implantações de demonstração estivessem sincronizadas com as implantações de produção. A maioria dos problemas de sincronização se baseia na falta de sincronização do banco de dados devido à falta de scripts de alteração ou objetos de banco de dados ausentes. Oracle é o nosso banco de dados de preferência.

Uma implantação típica no ambiente Demo é um processo muito doloroso que envolve o teste de um aplicativo e, conforme ocorrem problemas devido à falta de colunas da tabela de banco de dados, funções, procs armazenados, precisamos procurar os objetos de banco de dados ausentes, aplicá-los ao banco de dados e depois continue até que todos os problemas sejam resolvidos.

Como posso resolver esse problema para garantir implantações suaves, indolores e que consomem menos tempo? A migração de nossos aplicativos para o Docker pode ajudar com os problemas de sincronização do banco de dados e a falta de disciplina associada dos desenvolvedores? Que processo podemos implementar para melhorar nessa área?

Eu integraria o gerenciamento de esquema ao próprio aplicativo (ou junto).

Qualquer alteração no esquema deve ser confirmada ao longo do código do aplicativo (e, portanto, marcada também).

Já existem várias possibilidades listadas nesta pergunta: quais práticas ou ferramentas permitem a implantação contínua de bancos de dados

Com esse tipo de ferramenta, o uso de um banco de dados na memória, como h2 ou um banco de dados central, e o aplicativo verificar a versão do esquema (armazenada no banco de dados) quando iniciado permitem obter um esquema atualizado do banco de dados na inicialização do aplicativo.

Isso não resolverá o seu problema de disciplina e poderá criar novos, pois geralmente vem com uma versão estrita do esquema, impor a versão pode ser feita com ganchos de pré-confirmação, mas é um trabalho árduo.

Em nossa empresa, gerenciamos nosso código de aplicativo dentro de um VCS (Git) e a maioria dos aplicativos com os quais trabalhamos instala seu banco de dados principal a partir dos scripts de configuração fornecidos com o aplicativo.

Se precisarmos estender ou personalizar um aplicativo para um de nossos clientes, que envolve a necessidade de estender o banco de dados ou fazer personalizações do banco de dados, acompanharemos nosso código com um script de configuração que executará as operações do banco de dados através da camada / invólucro do banco de dados do aplicativo /motorista.

Dessa forma, uma vez que o código seja mesclado no repositório VCS, todo desenvolvedor que fizer check-out desse código recuperará essas alterações no banco de dados. Além disso, após a mesclagem do código, essas alterações no banco de dados terminam em todos os ambientes (nós de teste, UAT e produção) e, dessa forma, todas as alterações no banco de dados serão implementadas sem problemas.

Este é um método fácil de implementar. Você também pode mergulhar nas ferramentas de controle de origem específicas para bancos de dados, se precisar de possibilidades de gerenciamento mais avançadas.