Codice promozionale con Subversion

Question

sto lavorando sulla migrazione nostro team di sviluppo a Subversion e migliorare la nostra struttura e dei processi repository. Fondamentalmente stiamo andando con l'impostazione standard trunk/branches/tags. Inizialmente pensavo di utilizzare una strategia di rilascio delle filiali (filiali/1.0, filiali/2.0, ecc.), Ma ora mi sto orientando verso un modello di promozione del codice (test e rami di produzione). È un po 'meglio e più intuitivo per come funziona il nostro team, ma i rilasci saranno un po' meno diretti: abbiamo effettivamente bisogno del ramo di prova per diventare il ramo di produzione. (Il ramo di produzione è sempre disponibile per le versioni di manutenzione, ma il ramo di test non deve necessariamente esistere tra la distribuzione di una release e la versione di prova successiva.)

Chiunque stia utilizzando la promozione del codice consiglia il modo migliore implementare la promozione di un ramo dal test alla produzione? Immagino che queste siano le mie opzioni, ma non so se hanno pro/contro principali:

a. Unire completamente il ramo di prova al ramo di produzione, eliminare il ramo di prova
b. Elimina il ramo di produzione, copia il test in produzione, elimina il ramo di test
c. Elimina il ramo di produzione, rinomina il ramo di prova in produzione

Grazie per qualsiasi consiglio!

Answer 1

prima: l'opzione b) ec) sono le stesse in subversion come in subversion i nomi sono in effetti copia ed elimina.

Che ti ha detto hanno solo due scelte:

1. completamente si fondono ramo di prova nel ramo di produzione, eliminare ramo prova

   Questa è la pulito strada in termini di sovversione. Puoi vedere in te svn log quali revisioni si sono fuse in produzione e everybodys workingcopy rimane intatto.

   Ma viene fornito con un prezzo: È necessario eseguire manualmente le unioni e risolvere potenziali conflitti (se si verificano cambiamenti in productionbranch).

   Tuttavia di solito si può fare questo con una piccola quantità di overhead

2. Elimina ramo di produzione, rinominare ramo di prova per la produzione

   Questo è il facile modo , perché basta fare un piccola operazione che è scriptable.

   Svantaggi:

   Si invalidare tutte le workingcopys che sono stati punta al testbranch

   Merge di monitoraggio è molto più difficile, in quanto non è possibile rivedere il vecchio ramo di produzione facilmente (che è diventata la produzione!). Le modifiche dirette nel ramo di produzione vengono perse (senza notifica)!

Anche tenere a mente che si può non si vuole a tutti i commit testbranch in produzione (come mai si prova, se tutto va bene?). Quindi suggerirei vivamente l'opzione A

Answer 2

Ho sempre pensato che le filiali fossero di breve durata e che tutte le mie versioni si trovino nella cartella dei tag. Quando le correzioni sono necessarie per una determinata versione, il tag viene copiato su un ramo, il lavoro viene eseguito e viene creato un nuovo tag. Sono curioso di vedere se qualcuno ha un approccio diverso/migliore.

Answer 3

tuoi rami di produzione dovrebbe rimanere intatto. Chiamali con il loro numero di rilascio. ProductName_Production_ {principale}. {Minore}. {} Minore. Durante la migrazione da test a produzione, si crea un nuovo ramo di produzione con il numero di versione più recente. Elimina il ramo di test, se lo desideri, ma può essere trattato allo stesso modo.

Come parte del processo di compilazione, di solito eseguo il backup della produzione corrente prima di distribuire la produzione successiva, in modo da poter ripristinare l'ultima versione stabile, se necessario. Solo un fyi.

Generalmente non uso rami in questo modo. Mantengo ogni iterazione taggata in modo da averli tutti. Uso i miei ambienti per promuovere il codice dal test, al qa, al test delle prestazioni, alla produzione. Ziping di ogni pacchetto lungo la strada per le funzionalità di rollback.

Answer 4

In realtà non distinguiamo tra ramo di lavoro principale e ramo di test sul livello di controllo del codice, ma per me ha senso.

vorrei davvero andare per un approccio come

• principale
• ramo prova
  • prova
• ramo di produzione (userebbe la cartella tag per questi)
  • produzione1 .0

Quando il test è finito di copiare sopra in una nuova cartella production1.1/ramo.

Answer 5

Creo un tag da qualsiasi ramo o trunk per ogni release.

• tag/1.0_tc1
• tag/1.0_tc2
• tag/1.0_rc1
• tag/1.0_ga

Se RC1 è accettabile semplicemente tag di nuovo come 1.0_ga

Answer 6

Perché la migrazione del codice? Invece, crea la migrazione!

Per oltre 4 anni, abbiamo utilizzato solo le filiali. Abbiamo preso il bagagliaio e creato il nostro primo ramo, chiamato RB-2013.07.0.x. Questo ramo è il ramo di rilascio per luglio 2013. Abbiamo bloccato il camion, quindi nessuno potrebbe apportarvi modifiche. Tutte le modifiche sono state apportate in RB-2013.07.0.x. Una volta completata la versione di luglio, abbiamo bloccato RB-2013.07.0.x, quindi non è stato possibile apportare ulteriori modifiche.

Nel frattempo, abbiamo creato anche il ramo RB-2013.09.0.x, per l'uscita di settembre, dal tronco.Gli sviluppatori hanno lavorato alla release di settembre, mentre lavoravano all'uscita di luglio.

Dopo l'uscita di luglio in PROD, abbiamo quindi unito RB-2013.07.0.x in RB-2013.09.0.x. Non siamo mai tornati al Tronco. Non abbiamo mai migrato nulla. E in oltre 4 anni, non abbiamo mai perso alcun codice e, quando hai guardato il progetto, sapevi esattamente a cosa serviva il ramo.

Se si ha un problema con il prodotto (hot fix), si dovrebbe prendere la versione attuale del prodotto - ad esempio RB-2013.07.0.x e creare un ramo RB-2013.07.1.x, apportare modifiche, distribuire in prod , blocca il ramo e unisci il ramo nei rami superiori - RB-2013.09.0.x. In questo modo, avrai tutto aggiornato.

Ricorda, ogni build che abbiamo creato, abbiamo creato un TAG e lo abbiamo mantenuto nella directory TAGS.

Le build che abbiamo fatto, abbiamo aggiunto il numero di revisione da SVN all'ultima parte del numero di build.
Le build passano da dev, a test, a UAT/pre-prod e quindi a prod. Se si desidera sapere quale codice era presente in ogni build o ramo, andare in SVN ed estrarre l'elenco dei registri.