2011/11/9 Dickson S. Guedes <[email protected]>: > Eu achei muito interessante Leo. Confesso que cheguei a tentar uma > técnica semelhante, mas chegou num ponto em que ocorriam muitos > conflitos pois alguns campos não deveriam subir, e na hora do merge > apareciam ou para remover ou para adicionar, os rebases até ajudaram > em alguns casos mas nao tive tempo de melhorar a arquitetura em si.
Guedes, corrija-me se estiver errado, mas esta questão de quais campos devem ou não ser aplicados na produção está mais relacionada a estratégia de branches e tags que vc está utilizando, não? Considerando que eu tenhamos três desenvolvedores trabalhando no modelo e cada um com o seu próprio ramo (/branch/), nós não geramos versões para homologação ou produção (tag/baseline) mesclando um ramo que ainda não foi homologado pela equipe de ADs. Talvez a solução seja por aí... > Como você disse, o apgdiff resolve mas não tudo, mas a maneira como > você encaixou as peças parece ter ficado bem interessante! Parabéns! Obrigado, mas como vc já percebeu ainda não é a solução definitiva e confesso que ollhando para as ferramentas porcas que temos no mercado estou ficando cada vez mais com essa solução. > Acabou que optei por utilizar patches de alteração em banco (um pouco > semelhante ao processo do migrations do Rails, mas usando SQL e com > uma ferramenta que automatiza algumas coisas), Ah! Aqui vem o mundo perfeito! Gostaria de poder contar com o versionamento dos "migrations-like", mas infelizmente nem todos frameworks que trabalhamos suportam esta abordagem. Nas minhas aplicações (usando web2py) não temos este problema porque o único arquivo versionado é justamente aquele que mantém os models. As aplicações usando hibernate também não tem este problema, mas infelizmente temos um enorme legado em asp, php (sim, doctrine resolveria, mas não dá pra usar) e tantos outros. A propósito, qual o nome da ferramenta que "automatiza algumas coisas"? > uso tambem o pgTAP para > os testes, para validar essas alterações. São controlados via git e > cada commit esta associado à tickets em ferramentas de trackers, por > questão de rastreabilidade em milestones, por exemplo. Vi uma palestra sua em algum pgday sobre pgTAP e adoraria "encaixar" esta ferramenta de testes em algum canto do nosso framework de versionamento, mas preciso pensar e ultimamente está difícil fazer isso. Abraço! -Leo -- Leonardo Cezar http://postgreslogia.wordpress.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
