Em 9 de novembro de 2011 11:50, Leonardo Cezar <[email protected]> escreveu: > 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?
Exato. Estou exemplificando um cenário, que provavelmente não é o mesmo de todos, mas pode ser proximo ou com algumas semelhanças. A estratégia é montar um branch com uma versão candidata. Esta versão candidata é formada por um conjunto de correções que estão associadas à tickets em um bugtracker, por exemplo. Um milestone contém um pacote dessas correções e então é montada uma versão de testes contendo essas correções. Via um processo de merge/cherry-pick/rebase por exemplo eh montada uma release candidate. É neste processo que algumas coisas começam a ficar um pouco chatas, principalmente na questão da precedencia das coisas. O problema é muito mais uma questão de estrategia de versionamento e branches, como voce disse, do que da diff em si. Eu costumo usar muito o apgdiff até hoje, mas estou cada vez mais, utiilzando-o menos (nossa ficou confuso). > 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í... Sim, é. Em se tratando de git e suas estratégias de branching, trabalhar com dependencias passa a ser algo muito menos doloroso, mas ainda é necessário ter cuidado com re-trabalho, que é o que gostaria de evitar ao máximo. >> 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. É uma excelente estratégia Leo. E acaba que cada um cria sua própria ferramenta, baseado nas suas necessidades e experiência. Talvez seja a hora de juntar cabeças para construir algo modular que funcione bem e que siga um determinado paradgma de versionamento? >> 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. Nem sei se é tão perfeito assim, mas eu gosto da estratégia de ter patches de alterações que sobem ou não conforme o empacotamento de uma nova release. > A propósito, qual o nome da ferramenta que "automatiza algumas coisas"? Não sei, não dei nome ainda. ":P >> 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. Sim, em 2009 em São Paulo... Quanto ao pgTAP podemos trocar umas idéias. Criei um modelo que tem me deixado satisfeito até o momento. Tenho 650 arquivos de testes e 17770 testes. A grande questão diz respeito a _cobertura_ de testes. Não tenho como saber o quanto do meu banco esta coberto, ainda. Um abraço! -- Dickson S. Guedes mail/xmpp: [email protected] - skype: guediz http://guedesoft.net - http://www.postgresql.org.br _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
