[quote=Fabrício Cozer Martins]
A questão é nem porque tem muita gente trabalhando no mesmo projeto, mas sim porque com integrações contínuas e interatividade grande entre os ciclos de desenvolvimento, fazem com que não se perca tempo até serem feitas homologações na release A, pois eles sabem que novas releases irão ser entregues em breve.[/quote]
É isso que eu não entendo. Onde que está se “perdendo tempo”. Pra mim, tempo perdido é ter fazer um merge que podia ser evitado porque quis se ganhar tempo antes. Simplesmente não faz sentido :?
Sua resposta foi tão útil quanto se eu perguntasse:
-"Por que as pessoas se queimam no sol?"
E você respondesse:
-“Na praia tem muita gente queimada”
Espero que você possa colaborar mais que isso…[/quote]
Delicado como um elefante com a pata quebrada em uma loja de cristais …
primeiro ninguem é obrigado a responder nada em um forum, ja que ninguem é pago para isto.
bom, só vou continuar respondendo pq to de saco cheio de escrever este artigo e preciso pensar em alguma outra coisa …
imagine um projeto bem grande, por exemplo o proprio windows, ou o kernel do linux.
existe uma grande base de usuários utilizando o Windows XP (branch do sistema)
enquanto eles ja estão desenvolvendo o Windows Vista (outro branch)
eles seguem desenvolvendo o Vista, mas algum chato, resolve achar bugs no windows XP.
Estes bugs são corrigidos no XP, mas como a base de código original era a mesma, algumas das correções precisam também ser aplicadas no Windows Vista.
Como o Urubatan falou, isso é comum. Com iterações muito grandes eu preciso gerenciar minha mão de obra, não dá pra deixar 5 desenvolvedores de férias um mês porque o trabalho deles no release 1 acabou e eu preciso entregar para começar o release 2, além disso tem o problema da manutenção.
Claro que se as iterações não fossem grandes não haveria problema mas infelizmente tem coisas (e lugares) que não muda.
Sobre o exemplo, como eu falei antes, a coisa não era apenas conferir o número do release, vou colar aqui:
Eu precisava saber o binário, o cenário era bem incomum para o mercado brasileiro mas era assim. É como, contyinuando o exemplo do Windows, você ligasse para a Microsoft e eles precisassem verificar uma versão de DLL instalada, não dá pra simplesmente ouvir o usuário.
Desculpe se te ofendi. Não foi minha intenção :oops:
Também não penso que estejamos aqui por obrigação, e por isso mesmo só disse que esperava que você pudesse colaborar mais com o tópico.
Melhorou sim Porém nos exemplos vejo branches que não devem convergir nunca, mesmo porque daqui a alguns anos ainda haverá muita gente usando Windows XP ou kernel 2.4.x. Neste caso a abordagem é muito boa, já que o período entre os releases é na escala de anos.
Agora, num projeto onde os releases são mais frequentes, não vejo sentido em tal abordagem, já que ao invés de dar suporte à versão anterior é mais produtivo trabalhar na próxima.
Talvez um exemplo bom disso seja o servidor web Apache. Entre a versão 1.3 e a 2.0, o projeto se dividiu e continuaram surgindo versões 1.3.x e 2.0.x. No entanto, entre os releases 2.0.x e 2.0.y não há necessidade de tal divisão. Portanto, deve haver um critério para usar uma abordagem ou outra.
Olá…
Aqui na minha empresa eu sou a responsável por todo o CM do projeto, trabalhamos com metodologia Ágil SCRUM.
Nós temos como política o desenvolvimento em cima do tronco…as branches são abertas apenas quando precisamos de um desenvolvimento paralelo muito grande e que se feito no tronco acaba impactando o desenvolvimento do resto da equipe…
Conceitualmente a branch é feita para isso mesmo…
Todos os desenvolvedores acham desconfortável trabalhar numa branch por causa do impacto que causa no momento do Merge, sempre sai alguma coisa errada, sempre passa algo meio que desapercebido… é fato… como responsável pela CM, eu costumo concentrar o Merge… geralmente faço toda sexta-feira… porque todos os dias e todas as horas é preferivel não ter branch…
Quanto a abertura de Tag essa é feita quando uma versão do desenvolvimento é fechada para ser entregue ao cliente, como sabemos também a tag é uma parada no tempo , ela não pode ser alterada e fica fácil se for necessário voltar a versão antiga de entrega.
Aqui agente trabalha com subversion… por causa das várias revisões que essa ferramenta faz… integramos o subversion ao trac, e trabalhamos abrindo os famosos tickets tanto para desenvolvimento, quanto para correções… é uma ferramenta free e fácil de usar… Para o java usamos o Eclipse com um plugin do svn o que facilita bastante os updates , commits, merge, etc.
Vamos trocando informações
Boa Sorte!!!
alguem poderia me explicar de fato, o que é release, sinceramente sempre ouvia esta palavra, e ouço muito no deste release noCVS, mas realmente não sei. o que é?
O /trunk é bleeding edge, mas tem que estar sempre compilando (estável)
usamos um branch por funcionalidade, e o desenvolvedor é responsável por deixar esse branch atualizado com o trunk (merge trunk >>> branch)
a política é que o merge pro trunk só dá conflito no feature branch, nunca no trunk
merges e commits no trunk, só o lider do projeto
tags a cada release pro cliente, com branchs de manutenção dessas tags
Porém nos exemplos vejo branches que não devem convergir nunca, mesmo porque daqui a alguns anos ainda haverá muita gente usando Windows XP ou kernel 2.4.x. Neste caso a abordagem é muito boa, já que o período entre os releases é na escala de anos.