Best practice per il controllo del codice sorgente e correzioni di bug

Question

Se è necessario emettere una patch bug che non include lo sviluppo corrente che è stato eseguito il commit o eventuali modifiche rispetto alla versione corrente, cosa si dovrebbe fare per rendere il processo più sicuro e con costi generali inferiori?

Attualmente stiamo usando Subversion per il nostro controllo del codice sorgente in un piccolo team (3 sviluppatori) che si sviluppa principalmente in Visual Studio 2008. Prevediamo che il team potrebbe raggruppare 8 sviluppatori nel corso del prossimo anno e che qualsiasi supporto di rilascio precedente diventi più complicato. Mentre la maggior parte dei clienti è nella versione corrente, alcuni sono più indietro.

Answer 1

Il controllo del codice sorgente può gestirlo abbastanza facilmente ed è stato progettato per questo.

Quando raggiungi il periodo di stabilizzazione del tuo rilascio, dovrebbe essere fatto un ramo. È importante non avviare alcun lavoro sulla versione successiva prima che ciò avvenga.

Qualsiasi correzione di bug per quella versione dovrebbe essere fatta in quel ramo. Ciò impedisce al nuovo codice di una prossima versione di inquinare la correzione dei bug. Una volta completata la correzione dei bug, puoi unire le modifiche al trunk e tutte le altre versioni necessarie.

Non dimenticare di inserire il numero del bug nel commento, in quanto ciò renderà più facile tenere traccia dei commit.

Answer 2

Che ne dici di: un ramo per versione principale, con correzioni di bug applicate ai rami secondo necessità, e anche applicate (o unite) al tronco.

Answer 3

Dove lavoro, abbiamo diversi progetti che lavorano contemporaneamente. Per evitare questo problema, abbiamo diverse varianti del codice sorgente. Ad esempio, la prima versione è Variant 1.0. Creiamo un ramo di questa versione, diciamo, Variant 2.0, per tutti gli sviluppi futuri. Se dobbiamo correggere un bug, lo facciamo sulla variante principale, che attualmente è 1.0 e può rilasciarla. Quando Variant 2.0 è pronto per la produzione, lo uniamo con tutto ciò che si trova sul ramo principale (in questo caso, 1.1) e questo diventa il nuovo tronco principale. A un certo punto, avevamo 4 filiali in esecuzione contemporaneamente.

La fusione del codice può richiedere molto tempo e devi stare attento a non introdurre nuovi bug durante l'unione, ma se hai a disposizione uno strumento di confronto del codice decente, non dovrebbe essere poi così male. Abbiamo fatto un po 'di tempo indietro utilizzando Beyond Compare su una directory di origine di 10.000 file e ci è voluta una sola mattina.