[firebase-br] Versionamento de Banco - GitHub

Gladiston Santana gladiston em vidy.com.br
Segunda Fevereiro 8 10:55:48 -03 2021


No nosso caso o que gera muitos scripts são os alter table para
adicionar/modificar campos e criar tabelas, estes iniciam da primeira
edição de inauguração até a vigente para garantir que se todas rodarem
teremos um banco consistente que chegou a última versão em termos de
estrutura, depois disso vem os demais objetos (SPs, triggers, functions)
que é um script para cada objeto, neste caso não tenho que iniciar pela
versão de inauguração até a ultima.
Um programa de atualização foi criado onde pega todos os scripts que estão
no diretório de "SP", pega o primeiro script e esvazia o psql dela e
executa ela e repete para todos no mesmo diretório e depois repete o
processo, mas com psql incluso - isso resolve as dependências cíclicas.
Criar o programa de atualização da base de dados é a parte mais dificil, o
fluxo de trabalho para os programadores fica simples porque não importa o
que façam, só poderão colocar em produção se este programa conseguir rodar
e entregar a base atualizada.
Sinceramente não confio em scripts de diferença de banco A para banco B
porque jogamos a responsabilidade nele, que deveria ser
dos desenvolvedores. Quando algo der errado vai ser culpa do "programa".

Não é o nosso caso, mas se nosso modelo fosse implementado numa softhouse,
eu teria o cuidado de fazer atualização primeiro num backup do cliente e se
o processo chegar ao fim então no banco de produção.



Em qui., 4 de fev. de 2021 às 15:26, Marcos R. Weimer <
marcosweimer em gmail.com> escreveu:

> Ola!
>
> Aqui tambem fazemos o script "inteligente" que cria os campos se não
> existir e tal, porém, temos procedures gigantescas.
>
> Digamos que queira comparar a procedure "quente" com uma alterada por
> algum desenvolvedor? Este é o processo que queremos melhorar, está muito
> trabalhoso.
>
> Uma idéia seria ter a SQL de cada tabela, procedure e afins versionada no
> github, o problema seria na hora que sair a versão de produção, ter de
> passar todas estas SQLs montando o script da versão na mão.
>
> Hoje temos um processo que está funcionando bem (a mais de 10 anos), mas a
> idéia é facilitar e otimizar este processo.
>
>
> -=Ma®©oS=-
> Marcos R. Weimer
> Pessoas quietas têm as mentes mais barulhentas - Stephen Hawking
> Viver significa ter algumas alegrias e muito sofrimento - Pepe Mujica
> Muitos daqueles que te chamam de louco queriam ter a sua coragem - Silvio
> Santos
>
>
>
>
>
> Em qui., 4 de fev. de 2021 às 14:58, Gladiston Santana <
> gladiston em vidy.com.br> escreveu:
>
>> Olá Marcos,
>>
>> Há muito tempo eu tenho feito scripts gradativos que testam a existencia
>> dos objetos e na falta deles os cria e segue uma certa ordem domains,
>> tables, alter tables, indices, constraints,...., procedures, triggers...
>> enfim entendeu né. Esses scripts rodam desde a inauguração na base até
>> torná-la a versão vigente.
>>
>> Estes scripts voce pode versionar com git, mas recomendaria um
>> repositório central com a opção 'bare' para que todos possam ter a mesma
>> versão de referência.  Ter alguém que conheça bem o banco de dados e
>> possivelmente centralizar as coisas nele pode ser muito bom porque dá medo
>> de pessoas mal disciplinadas subirem 'lixo' não testado para este
>> repositório de onde outros sincronizarão.
>>
>> Aqui eu criei um programa de atualização que vai aplicando estes scripts
>> do zero até o fim, se nenhum falhar então a tá pronto para ser enviado e
>> compartilhado.
>> Quando tenho que atualizar a produção segue o mesmo princípio, rodo os
>> scripts na sequência desde o script que fez a fundação da base até as
>> últimas atualizações. Apenas há um .exe que automatiza isso para não
>> fazê-lo manualmente. Estes programas foram feitos com o Delphi, mas estou
>> estudando fazê-los em node.js, o qual estou aprendendo, eu tô perdendo
>> tempo em escrever UI para coisas banais que servem para automatizar.
>>
>> Hoje tem ferramentas bem melhores que te ajudam a criar um script com a
>> diferença do banco A para o banco B, mas pessoalmente acho que se vc cuidar
>> disso internamente desde o inicio do desenvolvimento nunca precisará de
>> ferramentas assim.
>>
>>
>> Em qui., 4 de fev. de 2021 às 10:05, Marcos R. Weimer via lista <
>> lista em firebase.com.br> escreveu:
>>
>>> Ola!
>>>
>>> A alguns anos estamos versionando o banco na mão (salvando procedures,
>>> montando scripts...) mas temos um banco grande (muitas tabelas,
>>> procedures,
>>> triggers, views...)
>>>
>>> Então venho perguntar o que estão usando para controlar/versionar o banco
>>> (procedures, triggers e afins), se alguem tiver alguma ferramenta ou algo
>>> do tipo  integrado ao github seria excelente.
>>>
>>>

-- 
A Vidy possui um Sistema de Gestão da Qualidade estruturado e com
Certificação ISO 9001 há mais de 10 anos, mantendo seu foco na Qualidade e
na Melhoria Continua.

Em março de2018 migramos com sucesso para a nova versão da ISO 9001.

Somos a única Empresa Brasileira de Engenharia de Laboratórios com
certificação com o Escopo Completo; desde Projetos, Engenharia, Construção,
Fabricação e Instalação de Laboratórios.


Mais detalhes sobre a lista de discussão lista