Elaborazione di una strategia di controllo della versione per SVN

Cercherò di elaborare una strategia per il controllo delle versioni per la mia azienda; attualmente utilizziamo SVN ma non esiste una struttura: fondamentalmente abbiamo solo un trunk e ci impegniamo solo per quello. Recentemente il responsabile dello sviluppo ha avviato un secondo repository che funge da "tag", ma deve essere unito manualmente al "trunk" poiché non fa parte dello stesso repository ma è totalmente separato. In effetti c'è solo una cartella, chiamata "Dev" (in realtà ci sono diverse cartelle "Dev" in date diverse ma solo "Dev" è la principale) e sotto c'è tutto il resto; tutti gli altri progetti. Non è organizzato per progetto, non ha il concetto di rami / tag / trunk o altro. La persona che lo ha impostato inizialmente (da tempo, ovviamente) sembrava non sapere affatto come impostare SVN, e da allora nessuno si è preso la briga di imparare a fare le cose correttamente per paura di rompere qualcosa. Non utilizziamo alcun tipo di CI (o test automatici, purtroppo).

Innanzitutto, dovremmo averlo separato per progetto? Ad esempio, abbiamo: due siti Web ASP.NET (non applicazioni Web, siti Web), un servizio Web, una cartella di distribuzione per tutti gli script di tabella e le procedure memorizzate, due client della riga di comando per progetti esterni che vengono chiamati dal Siti Web e una cartella condivisa con oggetti business comuni e simili. Ognuno di questi dovrebbe essere il proprio progetto con un'impostazione branch / tag / trunk, o dovrebbe essere così:

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

e tutti i rami e tutto hanno una copia dell'intera cartella Dev? Questo approccio potrebbe essere più facile da ingoiare poiché spesso abbiamo situazioni in cui è necessario apportare modifiche alla libreria di codice condivisa e almeno uno (di solito entrambi) dei siti Web.

In secondo luogo, eseguiamo rilasci regolari ("push" nel nostro linguaggio) sul nostro server di sviluppo e server live. Da quello che ho letto il modo migliore per gestire questo sarebbe che tutto lo sviluppo va in trunk /, i rami sono "temporanei" e utilizzati per aggiungere una nuova funzionalità che potrebbe influenzare trunk e i tag sono per le versioni? Quindi, spingiamo ogni mese, diciamo, e sto lavorando a un modulo nuovo di zecca. Vorrei diramare trunk e utilizzare quel ramo per il mio codice, scrivendolo e testandolo e quant'altro. Al termine del modulo, lo ricollegherei nel trunk (e forse eliminerei il ramo) e quando siamo pronti per la distribuzione, lo taggeremmo (diciamo "Maggio2011"). Se abbiamo una correzione di bug dopo che diventa attiva, sarebbe stata riparata nel tag May2011 e unita in trunk (quindi anche trunk ottiene la correzione), e poi May2011 verrebbe espulso di nuovo con la correzione? È questa l'intenzione di taggare?

Se vuoi un processo di generazione unificato, assicurati di mettere i rami / tag / trunk alla radice, in questo modo:

branches/
tags/
trunk/
  dev/
    ...

Se non hai bisogno di un processo di generazione unificato, puoi inserire rami / tag / tronchi all'interno di ciascun progetto, se lo desideri. Tuttavia, potrebbe essere difficile migrare verso una build unificata dopo averli inseriti in ciascun progetto. Una build unificata presenta vantaggi, come l'eliminazione della necessità di pubblicare componenti condivisi tra i progetti: fanno tutti parte della build.

Personalmente, mi piace un processo di generazione unificato. Inoltre, non penso che dovresti avere un progetto "dev". Dovresti avere progetti direttamente sotto il trunk, quindi diramare il trunk in un ramo di sviluppo. Usa i tag per le versioni. Ad esempio, lo farei così:

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

1. Per quanto riguarda la struttura del codice all'interno di svn, questa è una scelta davvero personale.

Vorrei suggerire che se i progetti sono correlati o condividono il codice, vogliono un trunk comune. Se sono indipendenti, vogliono tronchi separati o persino repository separati. Se è necessario fornire a terzi una copia della cronologia svn per un progetto, è molto più semplice se si trova in un repository separato.

Quindi nel tuo caso sembra che il layout che hai abbozzato sopra sia ragionevole, dato che hai un codice condiviso e vorresti che rami / tag includessero quel codice condiviso.

1. La tua descrizione di tag e branch usa suoni eminentemente sensibili ed è come mi aspetterei che svn venisse usato. Questa è davvero l'intenzione di taggarla per come la capisco. BTW nei tag e nei rami svn sono in realtà la stessa cosa, ma la terminologia viene applicata così come l'hai applicata.

Personalmente aggiungerei anche l'avvertenza che qualsiasi cosa impegnata nel trunk deve costruire, deve essere atomica e non deve interrompere alcun test unitario. Le filiali sono per lavori in corso non finiti. Mi aspetto che il bagagliaio sia un potenziale candidato al rilascio in qualsiasi momento.

Di seguito è riportato il modo migliore per disporre un repository 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

In questo modo è possibile controllare singoli progetti da soli.

Se vuoi dare un'occhiata a tutti e 3 i progetti e fare una build unificata con alcuni script / sistemi di build monolitici, allora investiga usando un modulo master con svn: externals mappando tutti gli altri progetti nel master trunk .

Questo è più complicato a prima vista ma è il modo più sostenibile e idiomatico per risolvere questo problema con Subversion.