Dovresti preoccuparti delle filiali SVN se ne hai solo una?

Se lavoriamo con un solo ramo in Subversion, dovremmo anche preoccuparci? Non possiamo semplicemente lavorare sul bagagliaio per accelerare le cose?

Ecco come sviluppiamo con Subversion:

• C'è un baule
• Facciamo un nuovo ramo di sviluppo
• Sviluppiamo una nuova funzionalità su quel ramo
• Al termine, la funzionalità viene unita nel trunk, il ramo viene rimosso e un nuovo ramo di sviluppo viene creato dal trunk

Quando vogliamo rilasciare alla produzione, creiamo un tag dal tronco. Le correzioni di bug sono fatte su un ramo da quel tag. Questo bugfix viene quindi unito nel trunk.

Questo è il motivo per cui creiamo un nuovo ramo di sviluppo dopo aver completato una funzione. In questo modo, la correzione dei bug è inclusa abbastanza presto nel nostro nuovo codice.

Di seguito è riportato un diagramma che dovrebbe chiarire:

Ora, si ha la sensazione che questo non sia il modo più efficiente di lavorare. Costruiamo localmente prima di impegnarci, il che richiede circa 5-10 minuti. Puoi capire che questo è vissuto come un tempo di attesa piuttosto lungo.

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 funzione successiva (altrimenti rimarrebbero in attesa che uno o due sviluppatori finiscano e si uniscano).

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

Quindi, dovremmo anche preoccuparci del ramo di sviluppo, dato che abbiamo un solo ramo? Ho letto dello sviluppo basato sul tronco e del ramo per astrazione, ma la maggior parte degli articoli che ho trovato focalizzati sulla parte ramo per astrazione. Ho l'impressione che sia per grandi cambiamenti che si estenderanno su diverse versioni. Questo non è un problema che stiamo riscontrando.

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

IMHO che lavora direttamente sul trunk va bene se è possibile eseguire il commit in piccoli incrementi e si dispone di un'integrazione continua in atto, quindi è possibile garantire (in misura ragionevole) che i propri commit non rompano la funzionalità esistente. Lo facciamo anche nel nostro progetto attuale (in realtà non ho lavorato in nessun progetto usando rami specifici per attività di default).

Creiamo un ramo solo prima del rilascio, o se una funzionalità richiede molto tempo per l'implementazione (vale a dire si estende su più iterazioni / versioni). Le dimensioni approssimative di un'attività possono quasi sempre essere valutate abbastanza bene in modo da sapere in anticipo se abbiamo bisogno di un ramo separato per esso. Sappiamo anche quanto tempo rimane prima della prossima versione (pubblichiamo le versioni ogni 2 mesi circa), quindi è facile vedere se un'attività si adatta al tempo disponibile prima della prossima versione. In caso di dubbio, lo rimandiamo fino a quando non viene creato il ramo di rilascio, quindi è OK iniziare a lavorarci sul trunk. Finora dovevamo creare una filiale specifica per attività una sola volta (in circa 3 anni). Naturalmente il tuo progetto potrebbe essere diverso.

Quello che stai descrivendo con lo sviluppo delle tue funzionalità è lo sviluppo parallelo (sviluppo simultaneo destinato a diverse versioni di prodotti) e richiede che i rami lo gestiscano correttamente. È possibile disporre di un ramo per ciascuna versione o per ciascuna funzione se è necessario ricomporre spesso le funzionalità che genereranno una versione specifica.

L'altro modo per farlo, sarebbe quello di lavorare fuori dal tronco per impostazione predefinita, ma creare un ramo se si prevede che l'attività si estenda oltre la versione successiva. Tagga sempre il rilascio ovviamente.

L'approccio che segui dipende davvero da quanta gestione puoi fare in anticipo. Se la versione tipica non ha davvero uno sviluppo parallelo, prenderei il secondo approccio.