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

Penso che il tuo approccio alla ramificazione e alla fusione sia OK, ma se il problema principale è che la base di codice è abbastanza instabile, è quello su cui devi concentrarti e ridurla al minimo.

La cosa principale da accertarsi è 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. Anche seguire le pratiche come il principio della singola responsabilità ti aiuterà.

Se un cambiamento architettonico importante deve verificarsi, dovrebbe avvenire nel suo stesso ramo, e poi essere ricondotto nel main una volta completamente testato e 'stabile' (entro limiti ragionevoli). Questo può essere doloroso e impegnativo, ma dovrebbe anche essere raro. Se hai buone pratiche di test in atto, il rischio è ridotto al minimo.

Potrebbe anche essere utile passare a un sistema di controllo della versione distribuito. Questo dovrebbe darti un tronco stabile, con caratteristiche diverse unite da diversi rami quando sono pronti. Continuerai a mescolare il dolore se il codice è troppo interdipendente, ma avrai un maggiore controllo.

Considerando questo da un'altra prospettiva, considera anche una maggiore comunicazione tra la tua squadra. Esegui regolari incontri stand up in stile agile. Considera dove siedono i membri del team e come può aiutarti. Se una fusione complessa deve aver luogo, potrebbe non essere una cosa così brutta: utilizzare un approccio di programmazione a coppia che dia comprensione a entrambe le parti.

Tendo a guardarlo da praticamente il contrario:

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

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

Ultimamente, ho sostenuto una filosofia di "branch and merge" come ultimo risultato. Penso che sia la sfortunata verità che trattare con i codici non sia un problema tecnico, ma è un compito che è cognitivamente difficile: penso sia semplicemente che il cervello umano non tiene traccia di dettagli sufficienti a renderlo facile. Inoltre, devo ancora vedere che la ramificazione e la fusione funzionano effettivamente nella pratica. Una volta che il codice è ramificato, l'esperienza mi dice che non è altro che un problema per unirlo di nuovo.

Un approccio basato sul rilascio disciplinato funziona bene.

La ramificazione SVN non è progettata per essere flessibile. Vorrei suggerire che il tuo primo problema si trova in SVN; il passaggio da questo aprirà nuove opzioni.