Fornito con una strategia di controllo della versione per SVN

Naviga le tue risposte
9

Off the clock ho intenzione di provare e trovare una strategia per il controllo della versione per la mia azienda; al momento utilizziamo SVN ma non esiste una struttura: fondamentalmente abbiamo solo un trunk e ci impegniamo solo a farlo. Recentemente il gestore 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 è completamente separato. In effetti c'è solo una cartella, chiamata "Dev" (ci sono in realtà 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 concetto di rami / tag / trunk o altro. La persona che lo ha creato inizialmente (a lungo andato, ovviamente) sembrava non sapere come impostare SVN affatto, e da allora nessuno si è preso la briga di imparare come fare le cose correttamente per paura di rompere qualcosa. Non utilizziamo alcun tipo di CI (o test automatizzati, sfortunatamente).

In primo luogo, 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 stored procedure, due client a riga di comando per i progetti esterni che vengono richiamati dal Siti Web e una cartella condivisa con oggetti aziendali comuni e simili. Ognuno di questi dovrebbe essere il proprio progetto con una configurazione branch / tag / trunk, o dovrebbe essere così: 

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

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

In secondo luogo, eseguiamo versioni regolari ("inviate" nel nostro linguaggio) al nostro server di sviluppo e al server live. Da quello che ho letto il modo migliore per gestire questo è che tutto lo sviluppo va in trunk /, i rami sono "temporanei" e usati per aggiungere una nuova funzionalità che potrebbe interessare il trunk, e i tag sono per le versioni? Quindi, spingiamo ogni mese diciamo, e sto lavorando a un modulo completamente nuovo. Avrei ramificato il trunk e usato quel ramo per il mio codice, scrivendolo e provandolo e quant'altro. Una volta terminato il modulo, lo ricollegherei in trunk (e magari cancellerei il ramo), e quando saremo pronti per la distribuzione lo etichettiamo (diciamo "May2011"). Se abbiamo una correzione di bug dopo la sua attivazione, essa verrebbe corretta nel tag May2011 e unita nel trunk (quindi anche trunk avrà la correzione) e quindi May2011 verrebbe espulso nuovamente con la correzione? È questa l'intenzione del tagging?

    
posta Wayne Molina 12.05.2011 - 18:05
fonte

3 risposte

5

Se vuoi un processo di compilazione unificato, assicurati di inserire rami / tag / tronco nella radice, in questo modo: 

branches/
tags/
trunk/
  dev/
    ...

Se non hai bisogno di un processo di compilazione unificato, puoi inserire rami / tag / tronchi in ogni progetto, se lo desideri. Tuttavia, potrebbe essere difficile migrare a 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 compilazione unificato. Inoltre, non penso che dovresti avere un progetto "dev". Dovresti avere dei progetti direttamente sotto il tronco e poi diramare il tronco in un ramo dev. Usa i tag per le versioni. Ad esempio, lo farei in questo modo: 

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/
    
risposta data 12.05.2011 - 18:28
fonte
1
  1. Per quanto riguarda la struttura del codice all'interno di svn, questa è una scelta davvero personale.

Suggerirei che se i progetti sono correlati o condividono il codice, allora vogliono un trunk comune. Se sono indipendenti, vogliono trunks separati o anche repository separati. Se è necessario fornire a una terza parte una copia della cronologia di 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 codice condiviso e vorresti che rami / tag includano quel codice condiviso.

  1. La tua descrizione di tag e branch usa suoni eminentemente sensibili ed è come mi aspetterei che venga usato svn. Questa è davvero l'intenzione di etichettare come ho capito. Il BTW nei tag e rami svn è in realtà la stessa cosa, ma la terminologia viene applicata non appena è stata applicata.

Personalmente aggiungerei anche l'avvertenza che qualsiasi cosa impegnata per il baule deve essere costruita, deve essere atomica e non dovrebbe interrompere alcun test unitario. I rami sono per lavori incompiuti in corso. Mi aspetto che il trunk possa essere un potenziale candidato per il rilascio in qualsiasi momento.

    
risposta data 12.05.2011 - 18:20
fonte
0

Il seguente è il modo migliore per creare 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 puoi controllare i singoli progetti da soli.

Se vuoi controllare tutti e 3 i progetti e fare una build unificata con qualche script / sistema di build monolitico, allora investiga usando un modulo master con svn:esternals mappando tutti gli altri progetti nel master trunk .

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

    
risposta data 12.05.2011 - 19:09
fonte

Leggi altre domande sui tag

In un'architettura microservizi ad accoppiamento libero, come si tiene traccia delle proprie dipendenze? Strutture di organizzazione dell'applicazione PHP intelligenti?