Dovresti preoccuparti dei rami SVN se ne hai mai uno solo?

10

Se lavoriamo solo con un ramo in Subversion, dovremmo preoccuparci? Non possiamo lavorare sul tronco per velocizzare le cose?

Ecco come sviluppiamo con Subversion:

  • C'è un trunk
  • Creiamo un nuovo ramo di sviluppo
  • Sviluppiamo una nuova funzione su quel ramo
  • Una volta terminata la funzione, viene unita nel trunk, il ramo viene rimosso e viene creato un nuovo ramo di sviluppo dal trunk

Quando vogliamo rilasciare in produzione, facciamo un tag dal bagagliaio. I bugfix sono fatti su un ramo di quel tag. Questa correzione è quindi unita nel trunk.

Ecco perché creiamo un nuovo ramo di sviluppo dopo che una funzione è stata completata. In questo modo, il bugfix è incluso abbastanza presto nel nostro nuovo codice.

Di seguito è riportato un diagramma che dovrebbe chiarire:

Ora, c'è la sensazione che questo non sia il modo più efficace di lavorare. Costruiamo localmente prima del commit, che richiede circa 5-10 minuti. Puoi capire che questo è vissuto come un lungo periodo di attesa.

L'idea di un ramo di sviluppo è che il trunk sia sempre pronto per il rilascio. Ma questo non è più vero nella nostra situazione. A volte, una funzionalità è quasi pronta e alcuni sviluppatori inizieranno già a codificare la prossima funzione (altrimenti rimarranno seduti in attesa che uno o due sviluppatori finiscano e si uniscano).

Quindi, quando la feature 1 è finita, viene unita nel trunk, ma con alcuni commit della feature 2 inclusa.

Quindi, dovremmo preoccuparci anche del ramo dello sviluppo, dato che abbiamo sempre un solo ramo? Ho letto dello sviluppo basato sul trunk e del branch-by-astrat- ting, ma la maggior parte degli articoli che ho trovato si concentrano sulla parte branch-by-astrstration. Ho l'impressione che si tratti di grandi cambiamenti che si estenderanno su diverse versioni. Questo non è un problema che stiamo avendo.

Che ne pensi? Possiamo lavorare sul bagagliaio? Lo scenario peggiore è (penso) che dovremmo fare un tag dal trunk e selezionare i commit di cui abbiamo bisogno, perché alcuni commit / funzionalità non sono ancora pronti per la produzione.

    
posta Peter 06.07.2011 - 17:32
fonte

2 risposte

6

L'IMHO che lavora direttamente sul trunk va bene se è possibile eseguire commit in piccoli incrementi e si dispone di un'integrazione continua, in modo da poter garantire (in misura ragionevole) che i commit non interrompano la funzionalità esistente. Lo facciamo anche nel nostro attuale progetto (in effetti non ho lavorato a nessun progetto utilizzando i rami specifici dell'attività per impostazione predefinita).

Creiamo solo un ramo prima del rilascio o se una funzionalità richiede molto tempo per essere implementata (ad esempio, si estende su più iterazioni / versioni). La dimensione approssimativa di un compito può quasi sempre essere stimata abbastanza bene in modo da sapere in anticipo se abbiamo bisogno di un ramo separato per esso. Sappiamo anche quanto tempo è rimasto prima della prossima versione (pubblichiamo le pubblicazioni circa ogni 2 mesi), quindi è facile vedere se un compito rientra o meno nel tempo disponibile prima della prossima versione. In caso di dubbio, lo rimandiamo fino alla creazione del ramo di rilascio, quindi è possibile iniziare a lavorarci sul trunk. Finora avevamo bisogno di creare una filiale specifica per una sola volta (in circa 3 anni). Ovviamente il tuo progetto potrebbe essere diverso.

    
risposta data 06.07.2011 - 17:49
fonte
1

Quello che stai descrivendo con lo sviluppo delle tue funzionalità è lo sviluppo parallelo (sviluppo simultaneo per il targeting di diverse versioni di prodotto) e richiede che le filiali gestiscano correttamente. Potresti avere un ramo per ogni versione o per ogni funzione se devi spesso ricomporre le funzionalità che renderanno una particolare versione.

L'altro modo per farlo, sarebbe di lavorare fuori dal trunk di default ma creare un ramo se ti aspetti che il tuo compito superi la prossima release. Contrassegni sempre il rilascio, naturalmente.

L'approccio che devi seguire dipende molto dalla quantità di gestione che puoi fare in anticipo. Se la versione tipica non ha uno sviluppo parallelo, prenderei il secondo approccio.

    
risposta data 06.07.2011 - 18:14
fonte

Leggi altre domande sui tag