O principal consultor na consultoria Sabin.io, o Simon Sabin, realizou uma palestra na WinOps 2017, sobre como adicionar mudanças de banco de dados em um modelo de continuous deployment . O ponto principal quando compartilha-se o banco de dados com vários serviços e aplicações é tratá-los como se fossem APIs, da perspectiva do responsável pelo banco de dados.
Sabin sugere que mecanismos como views, triggers e stored procedures possam ser utilizados para modificar estrutura interna do banco de dados e ainda manter compatibilidades com dados das aplicações. Como exemplo, ele propôs um cenário para migrar uma tabela de cartão de crédito de plain text para criptografada, onde as aplicações obteriam informações em plain text através de Data Manipulation View (DML) em uma view, enquanto a tabela atual é criptografada e descriptografada através de uma trigger, como ilustrado o exemplo à seguir:
O banco de dados deve respeitar um contrato implícito com a aplicação onde as mudanças internas (geralmente necessárias para desempenho, segurança e outras melhorias) não deveriam impactar as aplicações. Seguindo a analogia de uma API, incompatibilidades nas mudanças deveriam ser minimizadas e comunicadas com todas as informações para que as aplicações possam se adaptar e implementar mudanças compatíveis antes de realizar as mudanças de fato do banco de dados. Essa abordagem é adaptável para se aplicar consumer-driven contracts para banco de dados.
De acordo com Sabin, essa abordagem é necessária para intermediar duas visões distintas quando estamos lidando com banco de dados compartilhados: desenvolvedores tendem a ver o banco de dados como um "dumb storage", e os administradores de banco de dados (DBA) que vêm os bancos de dados como repositórios de dados críticos para o negócio. Em um mundo ideal cada time deveria ter o próprio banco de dados e também seu próprio DBA, mas isso é cenário difícil de existir.
Quando as aplicações necessitam de schemas ou outras modificações, Sabin recomenda que seja diminuído o tamanho do batch (porque alcançar confiabilidade e consistência em bancos de dados é uma tarefa complexa) e que seja aplicado uma mudança de cada vez, em conjunto com o código da aplicação correspondente. A escolha do mecanismo de migração (seja gold schema ou scripts de migração) dependerá do tipo de mudança. Para Sabin as abordagens são mais complementares do que opostas. Uma abordagem utilizando gold schema onde o target schema (estado desejado) é declarado e com uma ferramenta como o SQLCompare para aplicar as mudanças entre o estado atual e o desejado é adequado para este cenário. Porém para modificações mais complexas poderia ser mais adequado utilizar scripts de migração como o DBDeploy, o Flyway ou o ReadyRoll.
Sabin também deu outras recomendações que incluem adequar o banco de dados com as suas ferramentas e não o contrário, e adicionando informações de deployment no próprio banco de dados, isso torna-se fácil rastrear e diagnosticar os problemas. Lidar com mudanças de banco de dados como parte do pipeline de delivery, essas práticas promovem auditabilidade e conformidade.
Por último, ele sugere que a segurança de dados (em um período em que grandes erros dados continuam a ocorrer) poderia ser fortemente melhorada com uma abordagem de "public" vs "private", por exemplo ter pequenos banco de dados acessíveis com visões para outros maiores e seguros que não são acessíveis diretamente pelas aplicações.
Do mesmo modo como o DevSecOps movement levou um tempo para se consolidar, a ideia de incluir mudanças em banco de dados em um processo integrado de continuous integration existe por um tempo com outras designações (Sabin chama de Data Devops, outros chamam de DataOps, outros Database Lifecycle Management (DLM). Para Eduardo Piairo, outro palestrante na WinOps 2017
Não se refere em definir um novo processo para lidar com mudanças no banco de dados; Mas sobre integrar essas mudanças no ciclo de vida de um serviço em conjunto com a aplicação e a infraestrutura como código.