Unione di progetti di team

Question

Nel nostro progetto attuale abbiamo quattro diversi progetti di team TFS2010 nella stessa raccolta di progetti di team. La ragione di ciò è che diverse parti del progetto volevano utilizzare diversi modelli di progetto di squadra (CMMI vs Agile).

Tutti i progetti ora utilizzano lo stesso modello. Pertanto siamo ora giunti alla conclusione che sarebbe meglio unire i progetti in un progetto a squadra singola. Ciò solleva diverse domande:

1. È possibile/possibile utilizzare uno dei progetti esistenti come progetto di destinazione per gli altri tre?
2. Come spostiamo i nostri articoli di lavoro esistenti nel nuovo progetto mantenendo il nostro albero delle aree? Speriamo di creare un'area radice per ciascuno dei nostri progetti di team esistenti e spostare tutti gli elementi/aree di lavoro sotto questo nodo radice.
3. Oggi abbiamo collegamenti di elementi di lavoro da un progetto di team a un altro - come manteniamo questi collegamenti durante la fusione?
4. Qual è la migliore pratica quando si sposta il codice sorgente? Un approccio chiaro è semplicemente copiarlo nella nuova posizione e bloccare e conservare i vecchi progetti del team nel caso in cui sia necessario accedere a versioni precedenti del codice. Ma è possibile utilizzare la ramificazione per questo, ad es. ramificando tutto il codice esistente nel nuovo progetto del team? Che tipo di problemi potrebbe causare questo approccio?

Grazie per il vostro aiuto!

Answer 1

Sfortunatamente, TFS 2010 non consente di unire progetti di team.

I progetti di team di sviluppo e le raccolte di progetti di team sono una delle decisioni strategiche più importanti da prendere prima di iniziare a utilizzare TFS. Sfortunatamente, molti dei nostri clienti ci aiutano a non rendere necessaria la pianificazione anticipata e non capisco alcune delle limitazioni in TFS in merito alla fusione, spostamento, divisione, ecc. Dei progetti di team prima che inizino a utilizzare TFS: (

Quando abbiamo consultazioni in cui i clienti desiderano consolidare i propri progetti di team, si finisce per fare un sacco di lavoro manuale per migrare i manufatti. Abbiamo creato alcuni strumenti per aiutarci con questo processo per gli oggetti di lavoro ma per la maggior parte è un sacco di noioso lavoro di consulenza. Le utility di migrazione finiscono sempre per essere personalizzate per ogni cliente, dato che di solito hanno regole di business diverse per come vogliono migrare.

In definitiva, una "migrazione" "non finisce con l'introdurre a Tutte le informazioni e si finisce con altri problemi come data/ora che differiscono da ciò che erano originariamente. (Ho sentito indicato come un problema di compressione del tempo con le migrazioni.)

Alcune riflessioni aggiuntive per ciascuna delle vostre domande originali:

1. Certo, si potrebbe teoricamente utilizzare uno dei progetti del team esistenti come obiettivo per la migrazione degli altri tre. Finché ti piace il nome del progetto del team e non vuoi rename the team project. :)
2. Qui è dove abbiamo creato utilità di migrazione degli elementi di lavoro personalizzati per assistere i nostri clienti di consulenza. Probabilmente dovresti fare lo stesso.
3. Ciò è possibile anche con un'utilità di migrazione dell'elemento di lavoro personalizzata. È sufficiente tenere traccia dei mapping tra gli ID degli elementi di lavoro precedenti e i nuovi ID degli elementi di lavoro, quindi aggiungere i collegamenti in un secondo momento una volta che tutti i nuovi elementi di lavoro sono stati creati nel progetto del gruppo di destinazione.
4. Questo dipende in ultima analisi. Vorrei fare un "move" version control operation sul codice sorgente dal vecchio progetto del team al nuovo progetto del team. Questo mantiene tutto. Tuttavia, non eliminerei nessuno dei vecchi progetti del team perché ciò causerebbe la distruzione della cronologia del controllo della versione.

Non è la migliore storia per te, ma spero che possa aiutarti a pianificare un po '!