Best practice con il codice sorgente ramificato e il ciclo di vita dell'applicazione

Siamo un piccolo negozio ISV e di solito spediamo una nuova versione dei nostri prodotti ogni mese. Usiamo Subversion come repository di codice e Visual Studio 2010 come nostro IDE. Sono consapevole che molte persone stanno sostenendo Mercurial e altri sistemi di controllo della sorgente distribuita, ma a questo punto non vedo come potremmo trarne vantaggio, ma potrei sbagliarmi.

Il nostro problema principale è come mantenere sincronizzati i rami e il tronco principale.

Ecco come facciamo le cose oggi:

1. Rilascia nuova versione (crea automaticamente un tag in Subversion)
2. Continua a lavorare sul trunk principale che verrà rilasciato il mese prossimo

E il ciclo si ripete ogni mese e funziona perfettamente. Il problema sorge quando è necessario rilasciare una versione di servizio urgente. Non possiamo rilasciarlo dal trunk principale (2) poiché è in forte sviluppo e non è abbastanza stabile per essere rilasciato con urgenza.

In tal caso, facciamo quanto segue:

1. Crea un ramo dal tag che abbiamo creato nel passaggio (1)
2. Risoluzione del problema
3. Test e rilascio
4. Riporta la modifica al trunk principale (se applicabile)

Il nostro problema più grande è la fusione di questi due (filiale con principale). Nella maggior parte dei casi non possiamo fare affidamento sulla fusione automatica perché ad esempio:

• sono state apportate molte modifiche al trunk principale
• l'unione di file complessi (come file XML di Visual Studio ecc.) non funziona molto bene
• un altro sviluppatore / team ha apportato modifiche che non capisci e non puoi semplicemente unirle

Quindi quello che pensi sia la migliore pratica per mantenere sincronizzate queste due diverse versioni (branch e main). cosa fai?

Penso che il tuo approccio alla ramificazione e alla fusione sia OK, ma se il problema principale è che la base di codice è piuttosto instabile, questo è ciò su cui devi concentrarti e ridurre al minimo.

La cosa principale da garantire è che la base di codice abbia una buona separazione delle preoccupazioni . Le dipendenze tra i vari componenti devono essere isolate e ridotte. Questo dovrebbe risolvere la maggior parte dei tuoi problemi. Seguiranno anche pratiche come il principio della responsabilità singola.

Se è necessario un grande cambiamento architettonico, questo dovrebbe avvenire nel suo stesso ramo e quindi ricollegarsi al principale una volta completamente testato e "stabile" (entro limiti ragionevoli). Questo può essere doloroso e stimolante, ma dovrebbe anche essere raro. Se sono in atto buone pratiche di test, il rischio è ridotto al minimo.

Può anche aiutare a passare a un sistema di controllo di versione distribuito. Questo dovrebbe darti un tronco stabile, con diverse caratteristiche unite da diversi rami quando sono pronti. Avrai comunque problemi a fonderti se il codice è troppo interdipendente, ma avrai un maggiore controllo.

Guardando questo da un'altra prospettiva, considera anche una maggiore comunicazione tra il tuo team. Eseguire riunioni standup regolari in stile agile. Considera dove siedono i membri del team e in che modo può essere d'aiuto. Se deve aver luogo una fusione complessa, potrebbe non essere una brutta cosa: utilizzare un approccio di programmazione in coppia che comprenda entrambe le parti.

Tendo a guardarlo da quasi il modo opposto:

• Il trunk deve essere sempre un codice pronto per la produzione (dopo la prima versione iniziale, ovvero).
• Dovrebbe esserci un ramo di tipo di sviluppo che corre parallelo al tronco, dove avviene lo sviluppo mensile. Ogni mese, quando arriva il momento del rilascio, questo viene unito nel trunk, testato e quindi rilasciato.
• Gli hotfix possono quindi essere facilmente eseguiti nel bagagliaio e registrati, e possono sempre essere distribuiti correttamente. Quindi crea una patch dall'aggiornamento rapido e applicala al tuo ramo di sviluppo.

Naturalmente, questo flusso di lavoro è molto più adatto a qualcosa che non è SVN, perché una buona ramificazione e fusione è qualcosa che è abbastanza doloroso in SVN, indipendentemente dal flusso di lavoro. Nella mia esperienza, la fusione in SVN dovrebbe quasi sempre essere eseguita manualmente, perché semplicemente non funziona e non c'è modo di aggirarla.

Ultimamente, come ultimo risultato, ho sostenuto una filosofia di "branch and merge". Penso che sia la sfortunata verità che gestire il codice si fonde dai rami non è un problema tecnico, ma è un compito che è cognitivo difficile: penso semplicemente che il cervello umano non tenga traccia di dettagli sufficienti per renderlo facile. Inoltre, devo ancora vedere che la ramificazione e la fusione funzionano davvero nella pratica. Una volta che il codice è ramificato, l'esperienza mi dice che non è altro che guai a fonderlo di nuovo.

Un approccio disciplinato release-on-main funziona bene.

La diramazione SVN non è progettata per essere flessibile. Vorrei suggerire che il tuo primo problema risiede in SVN; passare da quello aprirà nuove opzioni.