Come posso ramificare il mio codice in un modo che rende possibile i test senza contaminare la linea di base?

Question

Usando TFS, abbiamo quanto segue:

• Una linea di base principale
• Un ramo di sviluppo per ogni sforzo di sviluppo. Questi si uniscono alla linea di base.
• Un ramo di rilascio che viene creato con ogni versione. Le correzioni di bug vengono fatte qui, rilasciate e si uniscono alla linea di base.
• Usando gli scaffali, possiamo condividere il codice tra le filiali di sviluppo, se necessario senza contaminare la linea di base. Utile per le revisioni del codice.
• Quando forniamo le nostre modifiche di sviluppo al basale, abbiamo una build automatizzata che inizia e pone automaticamente le nostre modifiche sul server di test.

Il problema è che gli analisti aziendali non possono vedere le nostre modifiche fino a quando non sono sul server di test e attualmente l'unico modo per ottenere le nostre modifiche sul server di test è controllarle al basale. Quindi, se il BA trova qualcosa di sbagliato, il codice è, sfortunatamente, già al basale e dovremmo affrontare il problema di riprenderlo.

Esiste un modo in cui possiamo cambiare la nostra strategia o processo di ramificazione per ottenere il BA ciò che vogliono vedere senza contaminare la nostra linea di base?

Answer 1

La tua strategia di ramificazione suona esattamente ciò che abbiamo deciso nella mia azienda. Non credo che il problema sia con la tua strategia di ramificazione, penso che il problema sia che devi controllare le modifiche nella base per applicarle al server di test.

Nella mia azienda, le modifiche non vengono controllate nella linea di base fino a quando non vengono promosse e funzionanti in produzione. I rami di rilascio sono ciò che vengono distribuiti sui server di prova ... se vengono trovati bug o BAS vogliono cambiare qualcosa, non dobbiamo passare attraverso il dolore di rimuovere i cambiamenti dalla linea di base.

Tuttavia, se hai molte versioni simultanee, questo può diventare un dolore per unire tutte le versioni prima di spostarle in produzione, poiché non si sta fondendo nella linea di base fino a dopo il processo. Nella mia azienda, abbiamo un programma di rilascio molto rigoroso e proviamo a fare una sola versione che si fa strada alla produzione alla volta. Per questo motivo, aspettare di unire il rilascio fino alla base fino a quando il rilascio non è stato promosso in produzione non ha creato alcun problema per noi, o finora lavoro extra ...

Quante volte fai uscite? Saresti in grado di distribuire filiali di rilascio sui server di test e far rappresentare la linea di base ciò che è attualmente distribuito in produzione?

(Farei un commento, ma sto ancora lavorando per guadagnare quel privilegio ...)

Answer 2

Non preferirei questo approccio, suggerirei:

Una linea di base principale che contiene codice stabilizzato. Il codice verrà fuso in questo ramo dalla rispettiva ramo di rilascio solo dopo la versione riuscita.

Un ramo di rilascio che viene creato da Main per ogni versione. Questo ramo verrà utilizzato per generare build di rilascio e verrà distribuito per testare l'ambiente.

Un ramo di sviluppo creato dalla filiale di rilascio, verrà utilizzato per gli sforzi di sviluppo e verrà unita a rilasciare quando sarò pronto a dare la mia build per testare.