Gestione del codice 'done' ma non rilasciabile in TFS

Naviga le tue risposte
6

Lavoro in un'organizzazione con 11 team di scrum che sviluppano sullo stesso codice base. Attualmente, tutto lo sviluppo è fatto nel bagagliaio, e alla fine di uno sprint tutto DEVE essere rilasciabile, o deve essere fatto retrocedere (un processo arduo) quando viene rilasciata una versione.

La mia opinione è che mentre il lavoro in uno sprint è (idealmente) "fatto" alla fine dello sprint, questo non significa necessariamente pronto per il rilascio. Potresti trovarti in un punto in cui non hai un prodotto minimo vitale da rilasciare, ma avere alcune storie complete. Se una storia non viene eseguita, o la trama è solo una parte di una funzionalità più ampia, dovrebbe essere facile tenerla separata dal codice di rilascio. Al momento è tutto arretrato, viene eseguito il taglio di rilascio, quindi viene ricontrollato. Un'enorme perdita di tempo!

Utilizziamo l'integrazione continua, che è l'argomento principale per tutti quelli che si sviluppano sul trunk. Occasionalmente i team usano un ramo di squadra, ma questo è correntemente disapprovato.

Ho considerato semplicemente di avere un ramo "dev" e "release", e di spingere le funzionalità a rilasciare quando sono un MVP, o di avere un ramo per ogni storia o funzione, ma questo è molto pesante per TFS. Altre persone hanno avuto a che fare con problemi simili in passato e quali sono i tuoi pensieri sulla migliore strada da percorrere? Sfortunatamente, siamo legati a TFS a breve termine.

    
posta SpoonerNZ 07.08.2014 - 14:40
fonte

3 risposte

6

Sembra che tu sia completamente bloccato da quella mancanza di ramificazione. Per lo meno dovresti sviluppare un ramo Dev e unire il codice completato su Main quando il tuo codice funziona e 'rilasciabile'. Ciò fermerebbe la stupidità di ripristinare il lavoro impegnato se non si riuscisse a rispettare la scadenza e a reimpegnarla in seguito. I giorni dell'utilizzo di VSS sono ormai lontani !!

Ogni team dovrebbe avere il proprio ramo dev, ma posso capire se tutti voi volete lavorare su un singolo ramo Dev.

CI dovrebbe essere applicato sia alle direttrici Dev e Main, sia all'analisi extra su Main - abbiamo usato alcune analisi statiche, test e generazione di documenti molto lunghi su Main che avrebbero rallentato il Dev down troppo.

Microsoft consiglia di utilizzare un ramo principale (o tronco) con rami Dev e rami di rilascio in il loro modello TFS. (i vecchi documenti sono qui , anche se dicono che sono obsoleti ... ma trascurano di collegarsi a le loro viste attuali)

    
risposta data 08.08.2014 - 12:12
fonte
2

La guida alla Scrum è molto chiara: il lavoro di uno sprint consiste nel fornire un incremento potenzialmente rilasciabile del prodotto "finito" alla fine di ogni sprint.

Ci sono una serie di ragioni per questo, ma il principale è evitare di incorrere in inutili debiti tecnici. Finché non hai reso il tuo prodotto potenzialmente rilasciabile, non sai quanto tempo resta da fare, o quanto tempo ci vorrà per rilasciare.

Sembra che tu abbia una politica di ramificazione eccellente ed è bello vedere che stai facendo un'integrazione continua. Non cambierei nulla.

Un problema che vedo però è dove descrivi una storia come parte di una funzionalità più ampia. Posso capire perché questo potrebbe causare problemi con la tua politica di ramificazione. Ma penso che il problema sia con il tuo pbi. Un buon articolo del backlog di prodotto dovrebbe essere indipendente e sarei più propenso a migliorarlo per risolvere il problema, piuttosto che a compromettere la ramificazione.

    
risposta data 07.08.2014 - 15:58
fonte
1

Quello che potresti fare è definire storie epiche con sottostorie.
Crea un ramo per quella storia epica e poi ramificane quella per ogni sottotoria. Quando ogni sottotitolo è fatto, unisci il ramo al ramo della storia epica. Quando l'epop è completamente finito, puoi unire nuovamente quel ramo per dominarlo e rilasciare tutto.

Devo dire che sono d'accordo con Derek Davidson; sembra che tu stia costruendo le tue funzionalità una parte alla volta, invece che in modo incrementale (che suona come la stessa cosa, lo so).
Mi ricorda una foto che ho visto su Twitter su come Spotify fa le cose. Invece di costruire immediatamente una macchina una ruota alla volta, sono passati dalla costruzione di uno skateboard, a uno scooter, a un motorino, ...
Sono consapevole che è più facile a dirsi che a farsi, ma tieni presente che c'è sempre un modo, anche se non puoi vederlo adesso. Potresti iniziare chiedendo a cosa serve il rapporto e cercando di ragionare quale sarebbe in assoluto il modo più semplice e semplice per raggiungere questo obiettivo.
Potrebbe essere qualcosa di completamente diverso da un rapporto.

    
risposta data 08.08.2014 - 11:47
fonte

Leggi altre domande sui tag

Strategia per utilizzare due diversi sistemi di misurazione nel software API REST vs direttamente chiamate DB nell'applicazione desktop