L'introduzione di Team Foundation Server in una squadra basata FogBugz: Quali caratteristiche da usare?

Question

Attualmente lavoro in una società che utilizza FogBugz per il rilascio e bug tracking e SourceGear Vault per controllo del codice sorgente.

Ora stiamo introducendo Team Foundation Server. Chiaramente TFS sostituirà Vault per il controllo di origine. La mia domanda è, con i seguenti requisiti:

• Grande base esistente di casi Fogbugz (alcuni ovviamente aperto) che abbiamo bisogno di un supporto continuo
• esigenze desk di supporto siano in grado di bug Alza / chiamate di assistenza
• Vuoi modifiche al sorgente per essere collegati a un numero di pratica

... qual è il miglior diviso tra l'utilizzo di casi Fogbugz e TFS elementi di lavoro?

• E 'possibile migrare totalmente da FogBugz a TFS?
• Se non è possibile migrare da FogBugz a TFS allora qual è il modo migliore per utilizzare il caso FogBugz e TFS elementi di lavoro insieme?

Answer 1

Inizialmente direi bug e difetti rimangono in FogBugz, roba sul piano di progetto come elementi di lavoro. Si potrebbe ottenere manualmente gli sviluppatori per creare un elemento di lavoro per ogni caso in FogBugz e associare il codice con quella voce lavoro, ma posso sentire le urla di scherno già: -)

Si potrebbe voler dare un'occhiata al TFS integrazione della piattaforma . Non so se ci sono strumenti che si collegano direttamente a FogBugz ma questi strumenti sono altamente estensibile. Si potrebbe quindi decidere a uno tutto migrare a TFS o eseguire entrambi i sistemi e di sincronizzazione. In esecuzione entrambi è bello come ogni disciplina possibile utilizzare lo strumento sono più familiarità con, sviluppatori utilizzano TFS per tutto e il tester / supporto può continuare a utilizzare Fogbugz e il toolkit mantiene tutto al passo.