Apresentando uma estratégia de controle de versão para SVN

Fora do horário, vou tentar criar uma estratégia para controle de versão para minha empresa; atualmente usamos SVN, mas não há estrutura para isso - basicamente só temos um tronco e nos comprometemos a isso. Recentemente, o gerente de desenvolvimento iniciou um segundo repositório que atua como nossa "tag", mas deve ser mesclado manualmente com o "trunk", pois não faz parte do mesmo repositório, mas é totalmente separado. De fato, existe apenas uma pasta chamada "Dev" (na verdade, existem pastas "Dev" diferentes em datas diferentes, mas apenas "Dev" é a principal)) e, por baixo, tudo o resto; todos os outros projetos. Não é organizado por projeto, não tem conceito de ramos / etiqueta / tronco ou qualquer coisa. A pessoa que o configurou inicialmente (há muito tempo, é claro) parecia não saber como configurar o SVN e, desde então, ninguém se preocupou em aprender a fazer as coisas corretamente por medo de quebrar alguma coisa. Não usamos nenhum tipo de IC (ou teste automatizado, infelizmente).

Primeiro, devemos separá-lo por projeto? Por exemplo, temos: Dois sites da Web do ASP.NET (não aplicativos da Web, sites da Web), um serviço da Web, uma pasta de implantação para todos os scripts de tabela e procedimentos armazenados, dois clientes de linha de comando para projetos externos chamados pelo Sites da Web e uma pasta compartilhada que possui objetos de negócios comuns e similares. Cada um desses deve ser seu próprio projeto com uma configuração de branches / tag / trunk, ou deve ser assim:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

e tem todos os ramos e tudo tem uma cópia de toda a pasta Dev? Essa abordagem pode ser mais fácil de ser adotada, pois geralmente temos situações em que precisamos fazer alterações na biblioteca de códigos compartilhada e em pelo menos um (geralmente ambos) dos sites.

Segundo, fazemos lançamentos regulares ("pushes" em nossa linguagem) para nosso servidor dev e live server. Pelo que li, a melhor maneira de lidar com isso seria que todo o desenvolvimento entra no tronco /, os ramos são "temporários" e são usados ​​para adicionar um novo recurso que pode afetar o tronco, e as tags são para lançamentos? Então, pressionamos todos os meses, digamos, e estou trabalhando em um novo módulo. Gostaria de ramificar o tronco e usá-lo para o meu código, escrevendo e testando-o e o que seja. Quando o módulo é concluído, eu o mesclaria de volta ao tronco (e talvez exclua a ramificação) e, quando estivermos prontos para implantar, marcá-lo-emos ("May2011", digamos). Se tivermos uma correção de bug após a ativação, ela será corrigida na tag May2011 e mesclada no tronco (para que o tronco obtenha a correção também), e então May2011 seria lançado novamente com a correção? É essa a intenção de marcar?

Se você deseja um processo de compilação unificado, coloque ramos / tags / tronco na raiz, assim:

branches/
tags/
trunk/
  dev/
    ...

Se você não precisar de um processo de compilação unificado, poderá colocar ramificações / tags / troncos em cada projeto, se desejar. No entanto, pode ser difícil migrar para uma compilação unificada depois de colocá-las em cada projeto. Uma compilação unificada tem vantagens, como eliminar a necessidade de publicar componentes compartilhados entre projetos - todos fazem parte da compilação.

Pessoalmente, gosto de um processo de compilação unificado. Além disso, não acho que você deva ter um projeto "dev". Você deve ter projetos diretamente sob o tronco e, em seguida, ramificar o tronco em um ramo de desenvolvimento. Use tags para lançamentos. Por exemplo, eu faria assim:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

1. No que diz respeito à estrutura de código no svn, essa é realmente uma escolha pessoal.

Eu sugeriria que, se os projetos estiverem relacionados ou compartilharem código, eles desejam um tronco comum. Se eles são independentes, eles querem troncos separados ou até repositórios separados. Se você precisar fornecer a terceiros uma cópia do svn history para um projeto, será muito mais fácil se ele estiver em um repositório separado.

Portanto, no seu caso, parece que o layout que você esboçou acima seria razoável, pois você compartilhou o código e deseja que branches / tags incluam esse código compartilhado.

1. Sua descrição do uso de tags e ramificações parece eminentemente sensível e é como eu esperaria que o svn fosse usado. Essa é realmente a intenção de marcar como eu a entendo. BTW em tags e ramificações svn são realmente a mesma coisa, mas a terminologia é aplicada como você a aplicou.

Pessoalmente, também acrescentaria a ressalva de que qualquer coisa comprometida com o tronco deve ser construída, deve ser atômica e não deve interromper nenhum teste de unidade. Ramos são para trabalhos inacabados em andamento. Eu esperaria que o tronco fosse um potencial candidato a lançamento a qualquer momento.

A seguir, é a melhor maneira de criar um repositório Subversion

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

Dessa forma, você pode verificar projetos individuais por si mesmos.

Se você quiser verificar todos os 3 projetos e fazer uma construção unificada com algum script / sistema de construção monolítico, investigue usando um módulo mestre com svn: externals mapeando todos os outros projetos no mestre trunk .

Isso é mais complicado à primeira vista, mas é a maneira mais sustentável e idiomática de resolver esse problema com o Subversion.