Aggiornare un progetto team in base a un modello di processo MSF v4.2.
Se è stato eseguito l'aggiornamento da Visual Studio Team System 2008 Team Foundation Server a Team Foundation Server 2013, è possibile aggiornare manualmente il progetto team. Se il progetto team è basato su un modello di processo della versione 4.2 di Microsoft Solutions Framework (MSF), seguire le procedure descritte in questo argomento. Dopo avere applicato gli aggiornamenti, sarà possibile accedere alle nuove funzionalità descritte in Aggiornare un progetto team aggiornato per accedere alle nuove funzionalità, nonché interfacciarsi con Microsoft Test Manager.
Importante
È necessario eseguire solo le procedure in questo argomento se si aggiorna un progetto team creato con un modello di processo fornito con Visual Studio Team System 2008 Team Foundation Server, o uno che non contiene test case e passi condivisi dei tipi di elemento di lavoro.
Queste procedure supportano solo l'accesso a nuove funzionalità disponibili con Team Foundation Server 2012.È necessario ulteriore lavoro per aggiungere nuove query o i rapporti più recenti, aggiornare i rapporti personalizzati oppure accedere ai dashboard.Per ulteriori informazioni, vedere Informazioni aggiuntive sulle modifiche apportate per l'aggiornamento di TFS.
Aggiornare le attività necessarie per accedere alle nuove funzionalità:
Rinominare i campi di sistema
(Solo Agile) Rinominare lo scenario in Storia utente
Scaricare la versione più recente del modello di processo MSF
Importare i tipi di collegamento
(Facoltativo) Applicare le personalizzazioni necessarie
Importare i tipi di elemento di lavoro
Importare il file della categoria
Importare i file di configurazione del processo
Verificare l'accesso alle nuove funzionalità
Attività aggiuntive necessarie per l'interfaccia con Microsoft Test Manager:
Specificare il tipo di bug da creare in Microsoft Test Manager
Concedere le autorizzazioni ai membri del team di testing
Avviare Microsoft Test Manager
Requisiti
Per scaricare un modello di processo, è necessario essere un membro del gruppo Project Collection Administrators. Se le autorizzazioni di sicurezza necessarie vengono impostate in modo esplicito, l'autorizzazione Gestisci modello di processo per la raccolta di progetti team deve essere impostata su Consenti.
Per eseguire gli strumenti witadmin e tcm da riga di comando, è necessario essere membro di uno dei seguenti gruppi: Team Foundation Administrators, Project Collection Administrators, o Project Administrators per il progetto team.
Per concedere autorizzazioni, è necessario essere membro del gruppo amministrativo a livello del gruppo che si desidera modificare. Ad esempio, se si desidera modificare le autorizzazioni per un gruppo o un utente a livello di raccolta di progetti team, è necessario essere un membro del gruppo Project Collection Administrators per tale raccolta oppure l'autorizzazione Modifica informazioni a livello di raccolta deve essere impostata su Consenti.
Per ulteriori informazioni, vedere Riferimento alle autorizzazioni per Team Foundation Server.
1.Rinominare i campi di sistema
Poiché i nomi descrittivi di diversi campi di sistema sono stati rinominati in Visual Studio Team Foundation Server 2010, è necessario rinominare questi campi nella raccolta di progetti team. Fra i campi di sistema rinominati sono inclusi System.AreaID, System.IterationID, System.HyperLinkCount, System.ExternalLinkCount e System.AttachedFileCount.
Eseguire questa attività per ogni raccolta di progetti team definita nell'istanza aggiornata di Team Foundation Server.
Aprire una finestra del prompt dei comandi in cui sono installati Visual Studio 2012 oppure Team Explorer 2012 e digitare:
cd %programfiles%\Microsoft Visual Studio 12.0\Common7\IDEIn una versione a 64 bit di Windows sostituire %programfiles% con %programfiles(x86)%.
Digitare tutti i comandi seguenti, sostituendo gli argomenti mostrati con i dati in uso, quindi scegliere il tasto INVIO
witadmin changefield /collection:CollectionURL /n:System.AreaId /name:"Area Id" witadmin changefield /collection:CollectionURL /n:System.AttachedFileCount /name:"Attached File Count" witadmin changefield /collection:CollectionURL /n:System.ExternalLinkCount /name:"External Link Count" witadmin changefield /collection:CollectionURL /n:System.HyperLinkCount /name:"Hyperlink Count" witadmin changefield /collection:CollectionURL /n:System.RelatedLinkCount /name:"Related Link Count"Utilizzare questo formato per CollectionURL: http://ServerName:Port/VirtualDirectoryName/CollectionName, ad esempio: http://srvalm:8080/tfs/DefaultCollection.
Torna all'inizio
2. (Solo Agile) Rinominare il tipo di elemento di lavoro dello scenario
Per ridurre la quantità di personalizzazioni necessarie da eseguire e conformarsi agli aggiornamenti futuri al modello di processo Agile, è consigliabile rinominare il tipo di elemento di lavoro scenario alla storia utente.
Nota
Naturalmente, per la ridenominazione del tipo di elemento di lavoro Scenario verrà richiesto di aggiornare i rapporti e le query esistenti che fanno riferimento al tipo di elemento di lavoro in questione.Tuttavia, a causa delle modifiche dello schema apportate al data warehouse con l'aggiornamento a Team Foundation Server 2010, i rapporti preesistenti o antecedenti all'aggiornamento devono essere riscritti per poter funzionare con il nuovo schema.Vedere la pagina relativa all'individuazione di rapporti dopo l'aggiornamento a Team Foundation Server 2010.
Eseguire questa attività per ogni progetto team che si desidera aggiornare.
Digitare il comando seguente, sostituendo gli argomenti mostrati con i dati in uso, quindi premere il tasto INVIO.
witadmin renamewitd /collection:CollectionURL /p:projectName /n:Scenario /new:"User Story"Suggerimento
Racchiudere un parametro tra virgolette quando contiene spazi.Ad esempio, specificare /p:"My Project X" quando nel nome del progetto sono contenuti spazi.
Torna all'inizio
3.Scaricare la versione più recente del modello di processo MSF
Vedere Scaricare la versione più recente dei modelli di processo.
Suggerimento
Per ottenere l'accesso alle versioni più recenti dei modelli di processo predefiniti, installare l'ultimo aggiornamento trimestrale per Team Foundation Server.Nell'ultimo aggiornamento trimestrale sono stati apportati aggiornamenti sostanziali al flusso di lavoro per diversi tipi di elementi di lavoro.Questi cambiamenti supportano le transizioni all'indietro, in modo che, quando inavvertitamente si trascina un elemento di lavoro nella bacheca Kanban o nell'area attività allo stato risolto o chiuso, è possibile trascinarlo su uno stato precedente del flusso di lavoro.
È possibile ottenere l'aggiornamento dal sito di download Microsoft: Visual Studio Team Foundation Server 2012 con Update 3.
Torna all'inizio
4.Importare i tipi di collegamento
Importare i tipi di collegamento, SharedSteps e TestedBy, disponibili nella cartella LinkTypes nel modello di processo scaricato nell'attività 3.
Eseguire questa attività per ogni raccolta di progetti team definita nell'istanza aggiornata di Team Foundation Server.
Digitare i seguenti due comandi, sostituendo gli argomenti mostrati con i dati in uso, quindi premere il tasto INVIO.
witadmin importlinktype /collection:CollectionURL /f:"DirectoryPath\TestedBy.xml" witadmin importlinktype /collection:CollectionURL /f:"DirectoryPath\SharedStep.xml"Per DirectoryPath, specificare il percorso della cartella LinkTypes per il modello di processo scaricato. Il percorso della directory dovrebbe seguire questa struttura: Drive:\MSFTemplateFolder\WorkItem Tracking\LinkTypes.
Torna all'inizio
5. (Facoltativo) Applicare le personalizzazioni alle versioni più recenti dei tipi di elemento di lavoro
Se è stato personalizzato uno qualsiasi dei seguenti tipi di elementi di lavoro, è necessario aggiornare la versione più recente di questi tipi con le personalizzazioni. Nella tabella seguente vengono riepilogati i campi aggiunti e rimossi nelle versioni più recenti di ogni modello di processo.
Tipi di elemento di lavoro Agile
Tipo di elemento di lavoro |
Campi rimossi |
Campi aggiunti. |
|---|---|---|
Bug |
|
|
Task |
|
|
Storia utente (in precedenza denominato scenario) |
|
Tipi di elemento di lavoro CMMI
Tipo di elemento di lavoro |
Campi rimossi |
Campi aggiunti. |
|---|---|---|
Bug |
|
|
Task |
|
|
Requisiti |
|
I tipi di personalizzazioni che è possibile applicare includono aggiunta di campi, aggiunte o modifiche agli elenchi di selezione o aggiunte ai motivi del flusso di lavoro. Non modificare gli stati del flusso di lavoro poiché questi vengono utilizzati nella configurazione del processo e negli strumenti di pianificazione Agile. Se è necessario modificare il flusso di lavoro, eseguire questa operazione dopo aver completato l'aggiornamento e attenersi alle linee guida sui mapping dei metastati forniti di seguito: Configurare e personalizzare gli strumenti di pianificazione Agile per il progetto team.
Se si utilizzano altri tipi di elementi di lavoro definiti nel modello di processo e si desidera aggiornarli alle versioni più recenti, applicare tutte le personalizzazioni apportate. Inoltre, se è stato definito un tipo di elemento di lavoro personalizzato utilizzato per tenere traccia dei test case, è necessario applicare le personalizzazioni di tale tipo al tipo di elemento di lavoro del test case fornito con l'ultimo modello di processo.
Per ulteriori informazioni sull'utilizzo di elementi che questi modelli di processo forniscono, vedere i seguenti argomenti:
MSF for Agile Software Development per Visual Studio ALM (v6.0)
MSF for CMMI Process Improvement per Visual Studio ALM (v6.0)
Torna all'inizio
6.Importare i tipi di elemento di lavoro
Importare i seguenti tipi di elemento di lavoro in base al modello di processo utilizzato.
Agile: Bug, Attività, Storia utente, Test Case, Passaggi condivisi, Richiesta di revisione codice, Risposta revisione del codice, Richiesta feedback, Risposta feedback
CMMI: Bug, Attività, Requisito, Test Case, Passaggi condivisi, Richiesta di revisione codice, Risposta revisione del codice, Richiesta feedback, Risposta feedback
Eseguire questa attività per ogni progetto team che si desidera aggiornare.
Digitare il comando seguente per ogni tipo di elemento di lavoro che si desidera importare, sostituendo gli argomenti mostrati con i dati in uso, quindi scegliere il tasto INVIO.
witadmin importwitd /collection:CollectionURL /p:projectName /f:"DirectoryPath\WITName"Suggerimento
Specificare il nome del file XML e non il nome descrittivo del tipo di elemento di lavoro.Ad esempio, specificare CodeReviewRequest.xml per il tipo di elemento di lavoro Richiesta di revisione del codice.
Per DirectoryPath, specificare la posizione della directory della cartella TypeDefinitions per il modello di processo scaricato. Il percorso della directory dovrebbe seguire questa struttura: Drive:\MSFTemplateFolder\ WorkItem Tracking\TypeDefinitions.
(Facoltativo) Verificare i tipi di elemento di lavoro accessibili aprendo Team Explorer o Team Web Access. Potrebbe essere necessario l'aggiornamento della cache per visualizzare le modifiche.
Torna all'inizio
7.Importare il file delle categorie
Importare il file di categorie posizionato nella cartella Gestione elementi di lavoro del modello di processo scaricato. Le categorie supportano il raggruppamento intelligente dei tipi di elementi di lavoro. Per ulteriori informazioni, vedere Utilizzare le categorie per raggruppare tipi di elementi di lavoro.
Nella finestra del prompt dei comandi, digitare il seguente comando, sostituendo gli argomenti mostrati con i dati in uso, quindi premere il tasto INVIO.
witadmin importcategories /collection:CollectionURL /p:projectName /f:"DirectoryPath\categories.xml"Per DirectoryPath, specificare il percorso della cartella WorkItem Tracking per il modello di processo scaricato. Il percorso della directory dovrebbe seguire questa struttura: Drive:\MSFTemplateFolder\WorkItem Tracking\TypeDefinitions.
Torna all'inizio
8.Importare il file di configurazione del processo
Il file di configurazione del processo determina il layout e le funzionalità disponibili tramite le pagine area e backlog del Team Web Access. Per utilizzare queste pagine, è necessario importare il file di configurazione del processo.
Importare il file di definizione della configurazione del processo.
witadmin importprocessconfig /collection:CollectionURL /p:" ProjectName" /f:"DirectoryPath\ProcessConfiguration.xml"Per DirectoryPath, specificare il percorso della cartella Process per il modello di processo scaricato. Il percorso della directory dovrebbe seguire questa struttura: Drive:\TemplateFolder\WorkItem Tracking\Process.
Torna all'inizio
9.Verificare l'accesso alle nuove funzionalità
Eseguire le attività riportate in Verificare la disponibilità di nuove funzionalità.
Nota
Non sarà necessario eseguire passaggi aggiuntivi per aggiornare il flusso di lavoro per i progetti team Agile come descritto di seguito: Aggiornare il flusso di lavoro per progetti team Agile.Attenendosi alle procedure illustrate in questo argomento, queste modifiche saranno già state applicate.
Torna all'inizio
Attività aggiuntive per l'interfaccia con Microsoft Test Manager
Eseguire le attività seguenti per completare gli aggiornamenti necessari per interfacciarsi con Test Manager.
1.Specificare il tipo di bug da creare in Microsoft Test Manager
Per supportare la creazione automatica di un elemento di lavoro per rilevare difetti del codice e bug individuati da un membro del team di test che utilizza Test Manager, è necessario specificare il tipo di bug da utilizzare per il progetto team esistente. Il comando tcm bugfieldmapping supporta l'importazione e l'esportazione di un file di mapping per il progetto team. Il file di mapping definisce il tipo di elemento di lavoro da creare e i tre campi dati che devono essere riempiti da Test Manager. I tre campi corrispondono a passi riproducibili, informazioni sul sistema e la build in cui è stato trovato il difetto. Quando un tester esegue un test e trova un difetto, può creare un bug nel quale i tre campi vengono riempiti automaticamente.
Aprire Blocco note o un editor di testo e copiare il codice seguente nel file:
<?xml version="1.0" encoding="utf-16"? <BugFilerMappings workitemtypetocreate="Bug"> <ReproSteps>Microsoft.VSTS.TCM.ReproSteps</ReproSteps> <SystemInformation>Microsoft.VSTS.TCM.SystemInfo</SystemInformation> <BuildFoundIn>Microsoft.VSTS.Build.FoundIn</BuildFoundIn> </BugFilerMappings>Nota
Se il tipo di elemento di lavoro che si utilizza per creare difetti del codice è contrassegnato da un'etichetta diversa da "Bug", sostituire "Bug" nell'esempio precedente con il nome di tale tipo di elemento di lavoro.
Salvare il file con l'etichetta bugfieldmappings.xml.
Nella finestra del prompt dei comandi, digitare il seguente comando, sostituendo gli argomenti mostrati con i dati in uso, quindi premere il tasto INVIO.
tcm bugfieldmapping /import /mappingfile:"DirectoryPath\bugfieldmappings.xml" /collection:CollectionURL /teamproject:projectNamePer DirectoryPath, specificare la cartella in cui è stato salvato il file bugfieldmappings.xml.
Per ulteriori informazioni, vedere Personalizzare e gestire l'esperienza di test [tcm e Microsoft Test Manager].
Torna all'inizio
2.Concedere le autorizzazioni ai membri del team di testing
È necessario concedere autorizzazioni a membri del team che gestiranno gli ambienti e le configurazioni di test, creeranno e visualizzeranno le esecuzioni dei test ed eseguiranno altre attività.
Nella tabella seguente vengono descritte le autorizzazioni che controllano l'accesso alle funzioni di test e il supporto per l'interfacciamento con il progetto team per l'esecuzione dei test. Nella tabella vengono inoltre indicate le assegnazioni predefinite impostate nella versione 5.0 dei modelli di processo MSF, oltre alle autorizzazioni consigliate da concedere ai tester manuali e ai coordinatori dei test.
Autorizzazione |
Descrizione |
Ambito |
Readers |
Contributors |
Builders |
Consigliata per i tester manuali |
Consigliata per i coordinatori dei test |
|---|---|---|---|---|---|---|---|
Visualizza informazioni a livello di progetto |
Consente di visualizzare l'appartenenza di gruppi a livello di progetto e le autorizzazioni di tali membri. |
Livello di progetto |
.png "segno di spunta"){kind=icon} |
|
|
|
|
Visualizza esecuzioni dei test |
Consente di visualizzare piani di test in questo nodo. |
Livello di progetto |
|
|
|
|
|
Crea esecuzioni dei test |
Consente di aggiungere e rimuovere risultati dei test e di aggiungere o modificare esecuzioni dei test per il progetto team. |
Livello di progetto |
|
|
|
|
|
Gestisci configurazioni di test |
Consente di creare ed eliminare configurazioni di test per il progetto team. |
Livello di progetto |
|
|
|
||
Gestisci ambienti test |
Consente di creare ed eliminare ambienti di test per il progetto team. |
Livello di progetto |
|
|
|
||
Elimina esecuzioni dei test |
Consente di eliminare un test pianificato per il progetto team. |
Livello di progetto |
|
|
|
||
Visualizza questo nodo |
Consente di visualizzare le impostazioni di sicurezza per un nodo dell'area. |
Nodo Area |
|
|
|
|
|
Gestisci piani di test |
Consente di creare e modificare piani di test assegnati a un nodo dell'area. Se i piani di test non sono stati eseguiti, possono anche essere eliminati. |
Nodo Area |
|
|
|
|
|
Gestisci controller test |
Consente di eseguire e annullare la registrazione dei controller di test per la raccolta di progetti team. |
Raccolta di progetti. |
|
È possibile concedere autorizzazioni attenendosi alle routine indicate per l'area di ambito specifica:
È possibile impostare autorizzazioni a livello di progetto o autorizzazioni del nodo di area dalla pagina amministrazione di Team Web Access. Vedere Gestione delle autorizzazioni e Aggiungere e modificare percorsi di area e di iterazione.
È possibile impostare le autorizzazioni per la raccolta di progetto da Team Explorer scegliendo Team, Impostazioni della raccolta del progetto team, Sicurezza, aprendo ed utilizzando la console di amministrazione per Team Foundation, o utilizzando gli strumenti da linea di comandoTFSSecurity e tf. Per ulteriori informazioni, vedere Collection-Level Groups.
Per ulteriori informazioni, vedere Modificare le autorizzazioni per un gruppo o un utente.
Torna all'inizio
3.Avviare Microsoft Test Manager
Dopo aver completato le attività di aggiornamento descritte precedentemente in questo argomento, è possibile avviare Microsoft Test Manager, connettersi al progetto e iniziare a pianificare le attività di test. Per ulteriori informazioni, vedere Test dell'applicazione.
Torna all'inizio
Informazioni aggiuntive sulle modifiche apportate per l'aggiornamento di TFS
Quando si esegue l'aggiornamento da Visual Studio Team System 2008 Team Foundation Server a TFS 2012, si ricevono aggiornamenti apportati a entrambi TFS 2010 e TFS 2012. Una serie di modifiche architetturali eseguite con la versione del TFS 2010. Per ulteriori informazioni sulle modifiche apportate effettuando l'aggiornamento alla versione più recente di TFS da Visual Studio Team System 2008 Team Foundation Server, vedere le risorse seguenti:
Concetti chiave di Team Foundation Server 2010 (post di blog)
Aggiornare un progetto team aggiornato per accedere alle nuove funzionalità (articolo VS ALM 2010)
Pagina relativa all'individuazione di rapporti dopo l'aggiornamento a Team Foundation Server 2010 (articolo VS ALM 2010)
Le modifiche e le aggiunte apportate allo schema per il cubo di Analysis Services (articolo VS ALM 2010)
Modifiche apportate ai progetti team e ai modelli di processo predefiniti durante l'aggiornamento di Team Foundation Server (articolo VS ALM 2012)
Vedere anche
Concetti
Aggiornare un progetto team aggiornato per accedere alle nuove funzionalità
Altre risorse
witAdmin: personalizzare e gestire oggetti per gestire il lavoro