O documento discute as abordagens de "Database as Code" para gerenciar bancos de dados no DevOps. Ele explica as abordagens baseadas em estado declarativo versus baseadas em migrações de estado e as vantagens e desvantagens de cada uma. O documento também demonstra ferramentas como SQL Server Data Tools e Redgate ReadyRoll e conclui recomendando abordagens baseadas em estado para bancos complexos e baseadas em migrações para bancos mais simples.

1. IGOR MACEDO
IGOR.MACEDO@ESX.COM.BR
DevOps: Gestão e
publicação de Dados
SQL Server
#VSSUMMIT

2. O QUE É DEVOPS?
#VSSUMMIT
“DevOps is the union of people,
process, and products to enable
continuous delivery of value to
our end users.”

3. CI/CD SHOW

4. CENÁRIOS COMUNS
#VSSUMMIT
Mudanças em banco de dados:
 Não fazem parte do pipeline de deployment
 Possuem um processo de deployment diferente

5. DATABASE É UM COMPONENTE
PECULIAR
#VSSUMMIT
Definição
(estrutura
)
Estado
(dados
persistentes)
+

6. PRIMEIRO PASSO
#VSSUMMIT

7. DATABASE AS CODE
#VSSUMMIT
 Guardar todos os scripts executados no banco?
 Descrever o banco de dados como um código (scripts)?

8. DATABASE AS CODE
#VSSUMMIT
“Integrar o ciclo de vida do banco de dados
(dev, test, deploy, ops, etc)
ao ciclo de vida de toda aplicação”

9. BASEADO NO ESTADO (DECLARATIVO)
#VSSUMMIT
Dev Pro
d
Tes
t
“Como a base de dados deve parecer”

10. BASEADO EM TRANSIÇÕES DE
ESTADO
OU MIGRAÇÕES (IMPERATIVO)
#VSSUMMIT
Dev Test Prod
“Como a base de dados deve mudar”

11. DUAS ABORDAGENS
Estado Migrações
Dev Test Prod
Dev Prod
Qual a sua fonte de verdade?
Não existe bala de prata!
“Como a base de dados deve parecer”
“Como a base de dados deve muda

12. DEMO
#VSSUMMIT
 SQL Server Data Tools (state based)
 Redgate ReadyRoll (migrations based)

13. PROS E CONTRAS
Estado Migraçõ
esMelhor experiência de
desenvolvimento (resolução de
conflitos e merge);
Difícil lidar com migrações de
dados;Baixa coesão entre mudanças de
schema e mudanças em dados;
Dependência da ferramenta que
gera scripts;
Mais produtivo: scripts de
update gerados
automaticamente por uma
ferramenta;
Testes confiáveis;
Deployments repetíveis e
confiáveis;Alta coesão entre mudanças de
Schemas e Dados;
Desenvolvedores tem total
controle sobre o deployment;
Difícil de revisar migrações
quando o volume de
mudanças no banco é muito
grande;Difícil para lidar com conflitos;
Menos produtivo: trabalho
manual de gerar scripts de
update e assegurar sua ordem

14. CONCLUSÃO
Estado Migraçõ
es
“Bom para problemas com
“Bom para lidar com
migração de dados”
• Aplicações complexas que
possuem muita lógica de negócio
no banco de dados (procedures,
functions, etc);
• e/ou com muitas pessoas
trabalhando (merges
complicados);
• e/ou com muitas alterações em
banco;
• e/ou muitas dependências
externas;
• Aplicações que ainda não estão
• Base de dados
predominantemente cadastral
(sem logica de negocio, poucas
prodedures, functions, etc);
• Aplicações com baixa
frequência de mudança no
banco,
• ou mudanças
predominantemente refatoração
de tabelas e migração de dados,
• e/ou times de desenvolvimento
pequeno;

15. IGOR MACEDO
IGOR.MACEDO@ESX.COM.BR
#VSSUMMIT
MUITOOBRIGADO!