Sprints e merges(svn)

Olá Jhonatas,

existe um conceito na agilidade bem importante em relação a esta questão dos merges em projetos que é a integração contínua. A ideia é que seu time entregue qualquer coisa que agregue valor para o cliente a todo momento. Ou seja, não necessariamente você faz 1 merge para enviar todas as alterações que resolvem 1 história ou 1 bug como um todo. Qualquer pequena alteração referente a história ou bug que já agregue valor para o cliente e que ele consiga testar/usar de alguma forma pode e deve ser enviado para o repositório de código.

Então se durante a sua sprint seu cliente passou um bug que é realmente mais prioritário que outras tarefas do sprint backlog e parte do seu time começa a resolvê-lo ao mesmo tempo que outras tarefas, conforme o código que resolve o bug é feito e pode ser testado você já vai mergeando com o repositório de código. Não precisa esperar até o final da sprint.

Assim, o ideal é que todos os dias, ou quem sabe até de hora em hora, o seu time entregue algo de valor para o cliente. Tanto que muitos times hoje em dia acabam preferindo usar o git ao invés do svn pela questão de fazer merges ser mais simples no git do que no svn.

Lucas obrigado pela resposta.

Essa questão de integração contínua é algo que temos conversado com a equipe mas que não está sendo fácil incluí-la nesse projeto em específico. Um outro projeto que vamos iniciar, a ideia é já incluí-lo em nosso processo, mas também é algo que está sendo lapidado. Sobre o git concordo plenamente, creio que ele auxiliaria na resolução desses problemas recorrentes com o merge do svn.

Mas de qualquer forma, no contexto atual creio que será um pouco complicado para esse projeto colocar os itens mencionados. Sendo assim, estamos tentando adaptar o que temos em mãos para minimizar o impacto com os merges. A ideia de realizá-los constantemente achei interessante. No nosso caso o trunk sempre representa uma versão estável e para isso dar certo temos que ter certeza que ele não está quebrado, ou seja, só pode ir para o trunk algo que passou pelos testes(é o nosso conceito de pronto atualmente!!). Ai a equipe que está trabalhando em uma determinada sprint traria essas alterações do trunk(merge) para o branche daquéla sprint, os conflitos seriam resolvidos e ao final seria realizada uma liberação.

Ainda estamos amadurecendo a ideia...

Agradeço novamente Lucas, abraço!

Boa noite meninos!

Fiquei na duvida, de que se vc trouxer um merge do trunk para o branch não sobrescreveria alguma outra coisa, ou traria um "conflito" extra. Não sei se mais alguma coisa é feita direto no trunk ai, mas se for o caso, vc pode gerar um problemas novo.(rs).. Onde trabalho, so trabalhamos com merge do branch para o trunk (nunca do contrario), e qnd precisamos gerar algum merge "emergencia" e por algo em produção (versão beta) direto no cliente sem testes, confesso que me da um frio na espinha (sim, eu sou tester e não concordo, porem qnd o cliente aperta mts vezes as pessoas passam por cima dos processos..rs). Já ouvi falar do git, e mesmo sem usa-lo ainda, acho q facilitaria muita coisa principalmente em questão de desenvolvimento ágil. Eu (particularmente) aplicaria a correção direto no branch, ao invés do merge. Minha ideia da visão de negócio que participo hj. ;)

Umas das ideias que temos é de sempre manter o trunk íntegro, ou seja, ele deve estar apto para ir para a produção. Nesse caso, sempre que temos uma sprint, um branche é aberto para ela. Vamos supor que no meio dessa sprint, um bug urgente é aberto. Tem-se algumas alternativas, como abrir um novo branche e nele realizar essa correção, reintegrando-o ao trunk após passar nos testes e liberação ao cliente ou, o que acaba ocorrendo é corrigir esse bug diretamente no trunk, o que realmente tentamos evitar ao máximo. Como essa correção foi realizada no trunk, umas das questões é como trazê-lo e quando para o branche atual, já que se eu demorar muito para fazer o merge, mais conflitos podem aparecer. Se eu fizer ao contrário, ou seja, só no final da sprint, pegar o branche que representa ela e fazer o merge para o trunk, eu poderei estar quebrando o trunk, já que conflitos poderão ocorrer e terei de resolver diretamente no trunk até estabilizá-lo. Então, o que fazemos as vezes é resolver os conflitos no branche para dai sim, após essa resolução, levá-lo para o trunk. Essa forma como fazemos hoje confesso que ainda não está madura, sempre dá um certo medo mas até certo ponto tem funcionado. Nesse projeto em específico não temos testes unitários/integração e muito menos integração contínua. Tudo isso favorece mais ainda que erros ocorram. Dessa forma estamos trabalhando para nos novos projetos incluir alternativas que minimizem determinados problemas.

Quando realizamos algumas pesquisas vimos várias alternativas sobre a forma de trabalho com o svn. Algumas dependem se existe times paralelos cada um trabalhando em seu branche, e cada situação acaba tendo seus pontos positivos mas também cuidados que devem ser tomados! Com certeza a forma como fazemos abre margem para alguns problemas e se tiverem algumas sugestões, serão bem vindas!

Obs: Se eu trouxer do trunk para o branche não creio que irá sobrescrever algo, mas que conflitos poderão ser gerados e terão de ser resolvidos. Eu vejo que teria problemas caso a correção se desse em um mesmo local onde está sendo trabalhado no branche, ai esse conflito teria de ser resolvido para ver qual a versão correta ou como fazer esse merge da melhor forma. Sinceramente eu prefiro mesmo que para bugs urgentes ou pequenas correções, sempre criar um branche para ela, mas as vezes as circunstâncias acabam forçando algo diretamente no trunk!