Você deveria se preocupar com os ramos SVN, se você só tem um?

Se trabalharmos apenas com um ramo no Subversion, deveríamos nos preocupar? Não podemos simplesmente trabalhar no porta-malas para acelerar as coisas?

É assim que desenvolvemos com o Subversion:

Há um tronco
Criamos um novo ramo de desenvolvimento
Desenvolvemos um novo recurso nesse ramo
Quando o recurso é concluído, ele é mesclado no tronco, a ramificação é removida e uma nova ramificação de desenvolvimento é feita a partir do tronco.

Quando queremos liberar para produção, fazemos uma etiqueta a partir do tronco. As correções são feitas em uma ramificação a partir dessa tag. Esse bugfix é então mesclado no tronco.

É por isso que criamos um novo ramo de desenvolvimento após a conclusão de um recurso. Dessa forma, a correção de bug será incluída em breve em nosso novo código.

Abaixo está um diagrama que deve esclarecer:

Nossa estratégia de Subversion

Agora, há um sentimento de que essa não é a maneira mais eficiente de trabalhar. Construímos localmente antes de confirmar, o que leva de 5 a 10 minutos. Você pode entender que isso é um tempo de espera bastante longo.

A idéia de um ramo de desenvolvimento é que o tronco esteja sempre pronto para lançamento. Mas isso não é mais verdade em nossa situação. Às vezes, um recurso está quase pronto e alguns desenvolvedores já começam a codificar o próximo recurso (caso contrário, eles esperariam que um ou dois desenvolvedores terminassem e se fundissem).

Então, quando o recurso 1 é concluído, ele é mesclado no tronco, mas com algumas confirmações do recurso 2 incluídas.

Então, devemos nos preocupar com o ramo de desenvolvimento, pois só temos um ramo? Eu tenho lido sobre desenvolvimento baseado em tronco e ramificação por abstração, mas a maioria dos artigos que encontrei focam na parte ramificação por abstração. Tenho a impressão de grandes mudanças que durarão vários lançamentos. Este não é um problema que estamos tendo.

O que você acha? Podemos apenas trabalhar no porta-malas? O pior cenário é (acho) que teríamos que fazer uma tag do tronco e escolher os commits necessários, porque alguns commits / recursos ainda não estão prontos para produção.

svn branching tagging

— Peter
fonte

Eu acho que seria melhor se você tivesse mais de um ramo. Um para cada recurso. Dessa forma, se você começar a trabalhar em um recurso grande que demorará um pouco de tempo, não atrasará as correções de bugs e tal para as versões já lançadas.

— Amy Anuszewski

Uma ramificação para cada recurso parece torná-lo mais complicado, enquanto tentamos reduzir a complexidade. Além disso, se houver uma correção de bug (isto é, para a 1.0), ela poderá ser feita em um ramo criado a partir da tag. Em seguida, podemos marcar esse ramo (criando um 1.1), liberá-lo e mesclar a correção do bug no tronco. O desenvolvimento do grande recurso continuaria no tronco.

— Peter

Respostas:

O IMHO que trabalha diretamente no tronco é bom se você puder confirmar em pequenos incrementos e se tiver uma integração contínua, para garantir (em uma extensão razoável) que seus commits não quebrem a funcionalidade existente. Também fazemos isso em nosso projeto atual (na verdade, eu não trabalhei em nenhum projeto usando ramificações específicas de tarefas por padrão).

Criamos apenas uma ramificação antes do lançamento, ou se um recurso demorar muito para ser implementado (ou seja, abrange várias iterações / lançamentos). O tamanho aproximado de uma tarefa quase sempre pode ser estimado suficientemente bem, para que possamos saber com antecedência se precisamos de uma ramificação separada para ela. Também sabemos quanto tempo resta para o próximo lançamento (publicamos lançamentos aproximadamente a cada 2 meses), para que seja fácil ver se uma tarefa se encaixa ou não no tempo disponível antes do próximo lançamento. Em caso de dúvida, adiamos até a criação do ramo de lançamento, então não há problema em começar a trabalhar nele no tronco. Até agora, precisávamos criar um ramo específico da tarefa apenas uma vez (em cerca de 3 anos). Claro que seu projeto pode ser diferente.

— Péter Török
fonte

Eu estou com Peter. Temos uma ramificação para cada versão suportada, mas, caso contrário, funcionamos no tronco. Também usamos a integração contínua, mas lembre-se de que isso significa apenas que ele será compilado e não que não quebrou a funcionalidade existente, mesmo com testes de unidade.

— 31711 Ian

@Ian, é claro que nenhum teste pode garantir na vida real que o código seja 100% livre de erros ... com recursos limitados, buscamos um nível razoável de segurança (cuja definição é específica do domínio e do projeto). Observe também que o IC também pode executar testes de integração etc., não apenas testes de unidade.

— Péter Török

Isso funciona até falhar. Se você precisar implementar uma correção antes que o novo recurso esteja pronto ... Ou se um release de novo recurso não estivesse tão pronto para o horário nobre quanto você pensasse, seria muito mais difícil fazer o backup dessa alteração do código se você não usar a ramificação.

— SoylentGray

@Chad, as correções para a versão mais recente são feitas no ramo de versão correspondente, sem interferência do tronco. E testamos novos recursos bastante extensivamente para sabermos quando eles estão prontos para o horário nobre. Concedido, temos relativamente poucos recursos grandes em nosso projeto. E como é um aplicativo Web do servidor, é bastante fácil adicionar um sinalizador de banco de dados para ativar / desativar seletivamente os recursos. YMMV.

— Péter Török

LOL ok Entendi mal e pensei que você tinha o tronco (com uma exceção) Eu também usei esse método para um grupo pequeno e para lançamentos pequenos freqüentes, ele não funcionou bem para fazer lançamentos grandes regularmente (3-6 meses ) intevals.

— SoylentGray

O que você está descrevendo com o desenvolvimento de seus recursos é o desenvolvimento paralelo (desenvolvimento simultâneo direcionado a diferentes lançamentos de produtos) e exige ramificações para lidar com isso corretamente. Você pode ter uma ramificação para cada release ou para cada recurso se precisar recompor os recursos que farão um lançamento específico.

A outra maneira de fazer isso seria trabalhar fora do tronco por padrão, mas criar uma ramificação se você espera que sua tarefa ultrapasse a próxima versão. Você sempre marca o lançamento, é claro.

A abordagem adotada depende realmente de quanto gerenciamento você pode fazer antecipadamente. Se o lançamento típico não tiver desenvolvimento paralelo, eu adotaria a segunda abordagem.

— Jeremy
fonte

Eu concordo e OP confirmada com: 'Às vezes, uma característica está quase pronto, e alguns desenvolvedores já vai começar a programar o próximo recurso ...'

— Chris

Sim, mas nunca precisamos recompor. Os recursos são implementados cronologicamente e, por exemplo, os recursos 1 a 4 precisam estar no próximo release (por exemplo, 1.0). O único momento em que isso pode ser problemático é quando o desenvolvimento é iniciado no recurso 5, que é para o lançamento posterior (2.0). Então, devemos garantir que essas alterações não sejam levadas junto na tag / release (1.0). Fazer uma ramificação antes do lançamento poderia realmente consertar isso.

— Peter