[firebase-br] Versionamento de Banco - GitHub

[Marcos R. Weimer]

Aqui temos um app que atualiza o banco, o negocio está funcionando.

Digamos que a procedure X esta retornando um cálculo errado, quando foi
modificada? qual o motivo? hoje saimos caçando as issues e pull request, a
idéia era atacar diretamente o ponto e identificar com mais agilidade.

Posso fazer triggers de banco que a cada alteração gravem em um log ou algo
do tipo... mas mesmo assim seria custoso a busca pelas alterações ou algo
do tipo, o que buscamos é otimizar, para código fonte existe várias
ferramentas de versionamento, compare e afins, mas e para o banco?

É tão problemático assim ou o banco sempre fica em "segundo plano" ?






-=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 seg., 8 de fev. de 2021 às 10:58, Gladiston Santana <
gladiston em vidy.com.br> escreveu:

> 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.
>
>
>
>
>