Integrazione continua con sviluppo di più diramazioni in Subversion

Question

Nel progetto su cui sto lavorando, stiamo utilizzando SVN con la strategia 'Stable Trunk'. Ciò significa che per ogni bug rilevato, il QA apre uno bug ticket e lo assegna a uno sviluppatore. Poi, uno sviluppatore corregge il bug e controlli in un ramo (off tronco, chiamiamolo questo il bug branch) e quel ramo si conterrà solo correzioni per quel particolare bug ticket

Quando abbiamo deciso di fare un comunicato, per ogni correzioni di bug che vogliamo rilasciare al cliente, uno sviluppatore unirà tutte le correzioni da diversi bug branch a trunk e procederà con il normale ciclo di QA.

Il problema è che usiamo trunk come il codice di base per il nostro lavoro CI (Hudson, in particolare), e quindi, per tutti i commit al bug branch, che salterà la build giornaliera fino a quando non viene fusa per trunk quando abbiamo deciso di rilascia la nuova versione del software. Ovviamente, ciò sconfigge lo scopo di avere CI.

Qual è il modo corretto per risolvere questo problema?

Answer 1

Come si nota, uno Lo scopo dell'utilizzo di un ramo è quello di separare le fluttuazioni di codice specifiche dallo sviluppo di ticket e dallo sviluppo di feature lontano dal trunk. Ma una volta completata la funzionalità o il ticket, è necessario unirlo nuovamente. In Subversion, i rami sono meglio usati per tracciare insiemi di funzionalità correlate (come quelli per una versione), non per singole funzionalità. Altrimenti si finirà rapidamente con un numero ingestibile di filiali.

Inoltre, perché ritardare l'integrazione? Più a lungo aspetti tra una release e l'altra, più alta è la probabilità che la tua modifica isolata entri in conflitto con un'altra modifica fatta da quel momento e/o produca ulteriore instabilità nel tuo sistema una volta riunito.

La mia strategia preferita è quella di fare qualcosa di simile:

[begin work on 0.4 branch] 
     | 
     | 
     v    
(*)---(*)-------(a)--(b)---(c)-- <-- Trunk is "unstable". 
     \  |   |  Contains all commits. 
    ver \ [merge from trunk]  Developers commit to trunk. 
<-- 0.3 \  v   v 
      +---(a)--------(c)-- <-- Branch is "stable". 
            Contains selected commits from trunk. 
            Know beforehand what's going onto branch. 

Ora, una volta che sei pronto per il rilascio:

[trunk] 
(*)---(*)---(*)----------------------------[development continues]---> 


[0.4 branch]      No further development on branch unless 
(*)---(*)---(*)---[0.4-release]  spot fixes are needed. Then re-tag (0.4.1) 
         ^  and re-release. 
          |   
          | 
         [make tag on branch; release from stable branch, 
         not unstable trunk] 

So che lei ha chiesto circa il modo migliore per costringere il vostro continuo sistema di integrazione per fare questo. Ma suggerirei rispettosamente che, dato che Hudson è riconosciuto come un sistema di CI relativamente affidabile, il fatto che tu stia avendo molti problemi a calzare il tuo modello di sviluppo in esso è un possibile segno che non è un processo che si presta bene a CI innanzitutto.

La nostra pratica tipica consiste nell'avere due build di base per progetto: uno contro il tronco e uno contro il ramo di rilascio corrente. In questo modo si sa che:

• Tutto ciò che è in fase di aggiornamento viene integrato in modo corretto (trunk)
• Qualunque sia la vostra destinazione di rilascio è, se si smesso di lavorare ora si avrebbe comunque un corretto e funzionante (non solo completamente descritto) build.

Answer 2

Invece di creare rami per le correzioni di bug, perché non provare a creare rami per la versione prima della correzione di bug e quindi applicare la correzione al trunk.

In questo modo, se si desidera fornire ai propri clienti la correzione del bug, si fornisce loro la versione del bagagliaio. Se non si desidera fornire loro la correzione del bug, è possibile fornire loro la versione del ramo prima dell'applicazione della correzione.

In questo modo, è possibile fare in modo che Hudson costruisca la linea di collegamento e le generazioni notturne includeranno tutte le correzioni dei bug.

Answer 3

Unire una notte a un "tronco instabile-malvagio" che unisce tutti i rami dell'insetto al tronco malvagio.

Oppure imposta configurazioni notturne su ogni ramo di errore (che sembra un sacco di build notturne).

A mio parere, questo sembra un sacco di ramificazioni per una soluzione di controllo del codice sorgente centralizzata. Forse hai bisogno di un sistema di controllo delle versioni distribuito e di un server di compilazione su ogni workstation, che sembra realizzare la stessa cosa (check in isolati per ogni sviluppatore e build giornalieri su ciò che gli sviluppatori eseguono)

Answer 4

Questo sembra doloroso e eccessivamente complicato (da un punto di vista di divisione/fusione).

Sarei pronto per il rilascio e gli sviluppatori devono effettuare il check-in nel bagagliaio. Tutto ciò che deve essere risolto come hot fix può essere unito al ramo di rilascio.

Answer 5

rispondo questo molto, ed ecco come IBM consiglia con ClearCase (UCM), e lo faccio nel mondo reale:

- Project 
    |- development mainline 
    |- TAG: version-1.0 
     |- version-1.0-bugfix#123 
     |- version-1.0-bugfixes 
    |- TAG: version-1.0-sp1 
     |- version-1.0-sp1-bugfix#234 
     |- version-1.0.sp1-bugfixes 
    |- TAG: version-1.0-sp2 

Tutto ciò che non preceduto da TAG è un ramo.

Answer 6

Ecco quello che facciamo (ispirato da Version Control for Multiple Agile Teams di Henrik Kniberg):

• sviluppo è fatto in un ramo di sviluppo e le caratteristiche spinti al tronco quando "fatto fare"
• tronco è il "fatto "ramo
• al momento del rilascio, ci tag tronco
• quando un difetto esce, si crea un ramo di rilascio dal tag
• difetti è patch nel ramo di release
• patch viene fusa dal ramo di release per il tronco subito dopo il rilascio (per includerlo nelle versioni future)

CI funziona su tutti i rami (rami di sviluppo, tronco, rami di rilascio).