Manter versões / ramos em um ritmo “ágil”? [fechadas]

Question

Temos um produto de software que evolui ao ritmo das necessidades dos clientes e de um roteiro mais geral.

Porque estamos em um ambiente de projeto SCRUM, isso acontece muito regurlarly que um novo recurso faz o seu caminho para o produto, e, em seguida, somos confrontados com a escolha de:

• implementar esse recurso em um ramo já liberado (não é realmente o ponto de ter um ramo, então)
• fazer um novo ramo - mas, em seguida, temos uma filial a cada três semanas, e não é apenas maintanable mais

Não lançar o novo recurso não é uma opção, os clientes não querem esperar por um plano de longo prazo marco para obter os recursos que eles querem, e não é sempre faisible para mover o recurso em um módulo cliente - às vezes nós necessidade de mudar o núcleo do produto ...

Alguém tem algum comentário sobre uma boa prática dado esse tipo de restrições?

Answer 1

Eu sugiro o seguinte, que usamos no meu ambiente atual:. Deleite o recurso não planejada como se fosse uma correção de segurança

• Cada liberação planejada (por exemplo, 3.0, 3.1) recebe o seu próprio número de versão, e sua própria tag no código-fonte. Depois de ser lançado, você não tocá-lo.
• Novos recursos depois de um movimento de liberação planejada para o lançamento planejado próximo (por exemplo 3.2)
• Se você deve modificar uma versão de lançamento do código, é uma "libertação não planeada" e recebe um número de versão patch (por exemplo, 3.1.1, 3.1.2). Todas as alterações:
  • Get implementado em um novo ramo baseado fora do último patch para que a liberação (por exemplo, 3.1.1 é criado a partir de 3.1.0, 3.1.2 é criado a partir 3.1.1)
  • Você imediatamente se fundiu ao tronco, para que eles também entrar no próximo lançamento planejado
• Depois de implementar o recurso não planejada, você liga o ramo em uma tag (aka não tocá-lo anymore) e voltar a trabalhar no tronco.

Desta forma, cada recurso não planejada recebe um ramo, mas apenas o tempo suficiente para fazer uma nova versão e se fundem em tronco. Você faz quase todo o seu trabalho em um lugar - tronco - e não têm lotes de fusão trabalho a fazer

.

Answer 2

Um novo ramo como ( 'new_feature_branch') está lá para materializar um esforço de desenvolvimento que não é compatível com o actual ramo (como 'release_branch')

Portanto, se seu release_branch atual não é muito ativo, você pode usá-lo para o novo recurso (desde que você definir uma etiqueta antes desenvolvimento deste novo recurso, no caso de você precisar cancelar esse processo e ir de volta ao estado anterior, este novo recurso)

Fazer um novo ramo pode ser uma boa solução, desde que está de volta mesclado em uma base regular (a cada 3 semanas) sobre o ramo de lançamento, e depois à esquerda para fora. É especialmente recomendado se você tem algumas atividades na release_branch (como alguns correção de bugs quente). em seguida, os dois esforços devem ser mantidos separados.

Basicamente, tudo se resume a sua merge fluxo de trabalho definição.

Comentários Deixe se você quiser me ao pormenor algumas opções que você sinta que não fez o suficiente endereço em profundidade.

Answer 3

No meu escritório que são tipicamente trabalhando fora de 3 ramos em qualquer ponto no tempo.

• Release: Este é o lugar onde o código que é actualmente destacados é marcado e armazenado. Se nós precisamos de fazer quaisquer correções de erros críticos é neste ponto que o trabalho é feito. Quando implantado nós tipicamente incrementar a parte correcção da tag (ou seja 1.19.0 -> 1.19.1).
• QA: Este é o lugar onde o código que está se preparando para os clientes é marcado e armazenado. Este ramo é usado quando estamos começando no novo trabalho e ter algum código que está sendo testado pela GQ, em preparação para a próxima entrega.
• principal:. Este é o lugar onde todos os novos trabalho é feito

Em raras ocasiões em que precisamos estar desenvolvendo em uma quarta linha (devido aos horários de libertação muito apertados), vamos, ocasionalmente, abrir a nossa linha de sandbox de código. Embora mais tipicamente vamos ter uma única obra desenvolvedor em isolamento e não check-in até a linha principal tenha sido apagado.

Com a estratégia de ramificação acima, temos sido capazes de fazer grandes alterações de recursos com uma entrega no final de cada sprint.

Answer 4

Não parece que você está realmente vivendo em um ambiente Scrum. Scrum requer a equipe a ser feito no final de cada Sprint, que é suposto não duram mais do que quatro semanas (provavelmente mais uma a duas semanas). Então, a cada duas semanas, você deve ter um rodando o sistema potencialmente destacável totalmente testado,,, de qualquer maneira.

A única forma que conheço para fazer isso é ter abrangentes suites, totalmente automatizados de ambos os testes do cliente e desenvolvedor (como prescreve Extreme Programming).

Eu não sei por que você precisaria ramos neste caso, mas eu também não entendo por que não seria sustentável. Na minha experiência, o shorterlived um ramo, o melhor.