DevOps ‐ Database - iNineBD/Track-5Sem2025Main GitHub Wiki
🎯 1. A Importância do Banco de Dados no Cenário DevOps
🎯 2. Atlas: Ferramenta de Versionamento de Schema
🎯 3. Configuração do Ambiente Atlas
🎯 4. Arquitetura do Data Warehouse
🎯 5. Operações de Migração
🎯 6. Benefícios da Implementação
🎯 7. Melhores Práticas
🎯 8. Evolução do Esquema (V1 → V2 → V3)
🎯 9. Conclusão
No cenário moderno de desenvolvimento de software, o DevOps revolucionou a forma como desenvolvemos, testamos e implantamos aplicações. Entretanto, por muito tempo, o banco de dados permaneceu como um gargalo neste processo, sendo frequentemente tratado como um componente à parte do pipeline de CI/CD. Esta abordagem fragmentada criava inconsistências entre ambientes, dificultava rollbacks e comprometia a confiabilidade das aplicações.
Database DevOps representa a extensão natural dos princípios DevOps para o gerenciamento de banco de dados, proporcionando:
Versionamento de Schema: Assim como o código-fonte, o schema do banco de dados deve ser versionado, permitindo rastreabilidade completa das mudanças estruturais.
Automação de Deployments: Migrações automáticas eliminam erros manuais e garantem consistência entre ambientes de desenvolvimento, teste e produção.
Integração Contínua: O schema do banco se torna parte integral do pipeline CI/CD, sendo testado e validado em cada alteração.
Rollback Seguro: Capacidade de reverter mudanças de schema de forma controlada e segura.
A adoção de práticas DevOps para banco de dados resulta em:
- Redução de Tempo de Deploy: Automatização elimina processos manuais demorados
- Maior Confiabilidade: Testes automatizados previnem erros em produção
- Colaboração Aprimorada: Desenvolvedores e DBAs trabalham com ferramentas e processos unificados
- Visibilidade Total: Histórico completo de mudanças facilita auditoria e troubleshooting
- Escalabilidade: Processos padronizados suportam crescimento da equipe e complexidade do projeto
Atlas é uma ferramenta moderna e poderosa para gerenciamento de schema de banco de dados, desenvolvida especificamente para atender às demandas do DevOps moderno. Diferentemente de ferramentas tradicionais, o Atlas adota uma abordagem declarativa e oferece integração nativa com linguagens de programação.
Schema as Code: Permite definir o schema do banco usando arquivos de configuração versionáveis, facilitando revisões e colaboração.
Detecção Automática de Mudanças: O Atlas compara automaticamente o estado atual do banco com o estado desejado, gerando migrações precisas.
Suporte Multi-Database: Compatível com PostgreSQL, MySQL, SQLite, MariaDB e outros SGBDs populares.
Integração com ORMs: Suporte nativo para GORM, Ent, Prisma e outros frameworks populares.
Validação de Schema: Análise estática que identifica problemas potenciais antes da aplicação das mudanças.
O projeto utiliza uma configuração Atlas específica para integração com GORM e PostgreSQL:
env "gorm" {
driver = "go://github.com/iNineBD/Track-5Sem2025Server/src/pkg/models.GetModels"
url = "postgres://<usuario>:<senha>@<host>:<porta>/<database>?sslmode=disable"
dev = "docker://postgres/15/dev?search_path=public"
migration {
dir = "file://migrations"
}
}Análise da Configuração:
- driver: Especifica o driver GORM personalizado que define os modelos da aplicação
- url: String de conexão com o banco PostgreSQL de produção, utilizando o schema 'dw'
- dev: Ambiente de desenvolvimento usando PostgreSQL 15 em container Docker
- migration.dir: Diretório onde as migrações são armazenadas
Para capturar o estado atual do schema do banco:
atlas schema inspect -u "postgres://<usuario>:<senha>@<host>:<porta>/<database>?sslmode=disable" > xxxxxx.hclEste comando gera um arquivo HCL que representa fielmente a estrutura atual do banco de dados.
O projeto implementa um Data Warehouse seguindo o modelo dimensional com estrutura star schema, otimizado para análises de dados de cartões e projetos.
dim_time: Dimensão temporal granular com referências para dia, mês, ano, hora e minuto, permitindo análises temporais detalhadas.
dim_user: Armazena informações dos usuários incluindo credenciais e função (role), essencial para análises por perfil de usuário.
dim_project: Contém dados dos projetos com descrição e referência à plataforma, fundamental para análises por projeto.
dim_card: Define os cartões com nome e descrição, base para análises de produtividade.
dim_platform: Categoriza as plataformas onde os projetos são desenvolvidos.
dim_status: Estados possíveis dos cartões (em andamento, concluído, etc.).
dim_tag: Sistema de etiquetagem para categorização adicional dos cartões.
dim_role: Funções dos usuários no sistema.
fato_cards: Tabela central que registra eventos relacionados aos cartões, conectando todas as dimensões e incluindo métricas quantitativas como qtd_cards.
O modelo implementa chaves estrangeiras rigorosas garantindo integridade referencial entre todas as dimensões e a tabela fato, com políticas NO_ACTION para prevenir exclusões acidentais.
Para criar uma nova migração baseada nas diferenças detectadas:
atlas migrate diff V3 \
--dir "file://migrations" \
--to "file://xxxxx.hcl" \
--dev-url "docker://postgres/15/test"Parâmetros Explicados:
- V3: Nome da versão da migração
- --dir: Diretório de destino das migrações
- --to: Schema de destino (estado desejado)
- --dev-url: Banco temporário para cálculos de diff
Para aplicar migrações no banco de produção:
atlas migrate apply \
--allow-dirty \
--url "postgres://<usuario>:<senha>@<host>:<porta>/<database>?sslmode=disable" \
--dir file://migrations \
--revisions-schema atlas_schema_revisionsParâmetros Críticos:
- --allow-dirty: Permite aplicação mesmo com mudanças não commitadas
- --url: Banco de destino
- --revisions-schema: Schema para controle de versões do Atlas
Cada mudança no schema é documentada e versionada, proporcionando histórico completo das evoluções do banco de dados.
A abordagem declarativa garante que desenvolvimento, teste e produção mantenham schemas idênticos.
Desenvolvedores podem revisar mudanças de schema através de pull requests, aplicando os mesmos processos usados para código.
Capacidade de reverter mudanças problemáticas de forma controlada e previsível.
Migrações automáticas integradas ao pipeline de deployment eliminam intervenções manuais.
Adotar padrões consistentes para tabelas, colunas e constraints facilita manutenção e compreensão.
Preferir múltiplas migrações pequenas ao invés de grandes alterações monolíticas.
Sempre testar migrações em ambiente isolado antes da aplicação em produção.
Realizar backups antes de aplicar migrações significativas.
Manter documentação atualizada sobre mudanças de schema e seus impactos.
| Sistema | BD |
|---|---|
| Sprint 1 | V1 |
| Sprint 2 | V2 |
| Sprint 3 | V3 |
Adição de novas tabelas de dimensão temporal:
dim_time, dim_day, dim_month, dim_year, dim_hour, dim_minute.
Renomeação de colunas:
Padronização para id_* e nome_* (ex: id_project em vez de id).
Nova tabela dim_card:
Armazena informações específicas de cartões.
Modificação em fato_cards:
Adição de id_time (relacionamento com dim_time).
Remoção de created_date e modified_date.
Nova tabela dim_platform:
Armazena plataformas onde os projetos são desenvolvidos.
Modificação em dim_project:
Adição de id_platform (FK para dim_platform).
Ajustes em dim_user:
Adição de email e password (dados de autenticação).
A integração do Atlas no pipeline DevOps representa um avanço significativo na gestão de banco de dados, proporcionando o mesmo nível de controle e automação que já aplicamos ao código-fonte. Esta abordagem não apenas melhora a confiabilidade e eficiência dos deployments, mas também democratiza o acesso às informações de schema, permitindo que toda a equipe contribua de forma mais efetiva para a evolução da arquitetura de dados.
O modelo dimensional implementado no projeto demonstra como estruturas de dados bem planejadas, combinadas com ferramentas modernas de versionamento, criam uma base sólida para análises avançadas e crescimento sustentável da aplicação.
Repositório com documentação da ferramenta : https://github.com/ariga/atlas