Aggiornare un progetto team basato su un modello di processo MSF v4.2
Se si aggiorna da Visual Studio Team System 2008 Team Foundation Server a Team Foundation Server 2012, è possibile aggiornare il progetto team manualmente.Se il progetto team è basato su un modello di processo 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.
.gif "Nota importante") Importante |
|---|
È necessario eseguire solo le procedure descritte in questo argomento se si aggiorna un progetto team creato con un modello di processo specifico di 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.Il lavoro aggiuntivo è obbligatorio per aggiungere nuove query o gli ultimi rapporti, aggiornare i rapporti personalizzati, o i dashboard di accesso.Per ulteriori informazioni, vedere Informazioni aggiuntive sulle modifiche apportate quando migliorano TFS. |
Aggiornare le attività richieste per accedere alle nuove funzionalità:
Rinominare i campi di sistema
(Solo) Agile rinominare lo scenario alla storia utente
Scaricare la versione più recente del modello di processo MSF
I tipi di collegamento
(Facoltativo) applicare in base alle necessità le personalizzazioni
I tipi di elemento di lavoro
Importare il file di categorie
Importare i file di configurazione considerati
Verificare l'accesso a nuove funzionalità
Attività aggiuntive necessarie per interagire con Microsoft Test Manager:
Specificare il tipo di bug da creare in Microsoft Test Manager
Concedere le autorizzazioni ai membri del team di test
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 da riga di comando tcm e di witadmin, è necessario essere membro di uno dei seguenti gruppi: Team Foundation Administrators, Amministratori raccolta progetti, 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 la classe 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 nel Team Foundation Serveraggiornato.
Aprire una finestra del prompt dei comandi in cui Visual Studio 2012 o Team Explorer 2012 sia installato e digitare:
cd %programfiles%\Microsoft Visual Studio 11.0\Common7\IDEIn una versione a 64 bit di Windows sostituire %programfiles% con %programfiles(x86)%.
Digitare ognuno dei comandi seguenti, sostituendo i dati per gli argomenti mostrati quindi scegliere la chiave 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 scenario
Per ridurre la quantità di personalizzazioni necessarie e renderli compatibili con gli aggiornamenti futuri al modello di processo Agile, è consigliabile rinominare il tipo di elemento di lavoro scenario alla storia utente.
[!NOTA]
Naturalmente, rinominare il tipo di elemento di lavoro scenario gli richiede di aggiornare i rapporti esistenti e query che fanno riferimento al tipo di elemento di lavoro scenario.Tuttavia, a causa di modifiche dello schema apportate al data warehouse con l'aggiornamento a Team Foundation Server 2010, il esistente o i rapporti pre-aggiornamento deve essere riscritto per utilizzare il nuovo schema.Vedere Individuazione dei 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 i dati per gli argomenti mostrati quindi scegliere la chiave INVIO.
witadmin renamewitd /collection:CollectionURL /p:projectName /n:Scenario /new:"User Story".gif "Suggerimento")
SuggerimentoRacchiudere un parametro virgolette quando contiene spazi.Ad esempio, specificare /p:"My Project X" quando il nome del progetto contiene 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.Gli aggiornamenti significativi sono stati apportati al flusso di lavoro per diversi tipi di elemento di lavoro nell'ultimo aggiornamento trimestrale.Queste modifiche supportano delle transizioni in modo che inavvertitamente quando si trascina un elemento di lavoro nella scheda di Kanban o nella scheda di 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: Aggiornamento trimestrale per Microsoft Visual Studio 2012 Team Foundation Server. |
Torna all'inizio
4.I tipi di collegamento
I tipi di collegamento, SharedSteps e TestedBy, situato nella cartella LinkTypes nel modello di processo scaricato nell'attività 3.
Eseguire questa attività per ogni raccolta di progetti team definita nel Team Foundation Serveraggiornato.
Digitare i due comandi seguenti, sostituendo i dati per gli argomenti mostrati quindi scegliere la chiave 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 deve rispettare questa struttura: Unità:\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 dei seguenti tipi di elemento di lavoro, è necessario aggiornare la versione più recente di questi tipi con le personalizzazioni.Nella tabella seguente vengono riepilogati i campi rimossi e aggiunti 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 (Scenario in precedenza denominato) |
|
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 le aggiunte di campo, le aggiunte o modifiche agli elenchi di selezione, o le aggiunte ai motivi del flusso di lavoro.Non modificare gli stati del flusso di lavoro come questi vengono utilizzati nella configurazione del processo e in Agile che pianifica gli strumenti.Se è necessario modificare il flusso di lavoro, modificarli dopo avere completato l'aggiornamento e seguire le istruzioni sui mapping di metastate forniti di seguito: Personalizzare le pagine di backlog e dell'area attività mediante la configurazione del processo.
Se si utilizzano altri tipi di elementi di lavoro definiti nel modello di processo e si desidera aggiornarli alle versioni più recenti, quindi applicare tutte le personalizzazioni apportate anche per tali elementi.Inoltre, se è stato definito un tipo di elemento di lavoro personalizzato utilizzato per tenere traccia dei test case, è necessario applicare le personalizzazioni del tipo al tipo di elemento di lavoro test case fornito dell'ultimo modello di processo.
Per ulteriori informazioni sull'utilizzo di elementi che questi modelli di processo forniscono, vedere i seguenti argomenti:
Torna all'inizio
6.I tipi di elemento di lavoro
I seguenti tipi di elemento di lavoro in base al modello di processo utilizzato.
Agile: Bug, attività, storia utente, test case, passi condivisi, richiesta di revisione del codice, risposta alla revisione del codice, richiesta di feedback, risposta di feedback
CMMI: Bug, attività, requisito, test case, passi condivisi, richiesta di revisione del codice, risposta alla revisione del codice, richiesta di feedback, risposta di feedback
Eseguire questa attività per ogni progetto team che si desidera aggiornare.
Digitare il comando seguente per ogni tipo di elemento di lavoro che è necessario importare, sostituendo i dati per gli argomenti mostrati quindi scegliere la chiave INVIO.
witadmin importwitd /collection:CollectionURL /p:projectName /f:"DirectoryPath\WITName"SuggerimentoSpecificare 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 revisione del codice.
Per DirectoryPath, specificare il percorso della cartella TypeDefinitions per il modello di processo scaricato.Il percorso della directory deve rispettare questa struttura: Unità:\MSFTemplateFolder\ WorkItem Tracking\TypeDefinitions.
(Facoltativo) verificare i tipi di elemento di lavoro è disponibile aprendo il Team Explorer o il team Web Access.Potrebbe essere necessario aggiornamento della cache per visualizzare le modifiche.
Torna all'inizio
7.Importare il file di categorie
Importare il file di categorie trova nell'elemento di lavoro che la cartella di rilevamento del modello di processo scaricato.Le categorie supportano il raggruppamento intelligente dei tipi di elemento di lavoro.Per ulteriori informazioni, vedere Definire categorie per raggruppare tipi di elementi di lavoro.
Nella finestra del prompt dei comandi, digitare il comando seguente, sostituendo i dati per gli argomenti mostrati quindi scegliere la chiave INVIO.
witadmin importcategories /collection:CollectionURL /p:projectName /f:"DirectoryPath\categories.xml"Per DirectoryPath, specificare il percorso dell'elemento di lavoro della cartella workitem tracking per il modello di processo scaricato.Il percorso della directory deve rispettare questa struttura: Unità:\MSFTemplateFolder\WorkItem Tracking.
Torna all'inizio
8.Importare i file di configurazione considerati
I file di configurazione considerati determinano il layout e le funzionalità disponibili tramite le pagine scheda e backlog di Team Web Access.Per utilizzare queste pagine, è necessario importare i file di configurazione elaborati nella sequenza indicata
Per importare i file di definizione per la configurazione del processo, digitare i due controlli, uno alla volta, sostituendo i dati per gli argomenti mostrati quindi scegliere la chiave INVIO.
witadmin importcommonprocessconfig /collection:CollectionURL /p:" ProjectName" /f:"DirectoryPath\CommonConfiguration.xml" witadmin importagileprocessconfig /collection:CollectionURL /p:" projectName" /f:"DirectoryPath\AgileConfiguration.xml"Per DirectoryPath, specificare il percorso della cartella Process per il modello di processo scaricato.Il percorso della directory deve rispettare questa struttura: Unità:\MSFTemplateFolder\WorkItem Tracking\Process.
Torna all'inizio
9.Verificare l'accesso a nuove funzionalità
Eseguire le attività fornite 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.Seguendo le procedure di questo argomento, è stato applicato già tali modifiche.
Torna all'inizio
Attività aggiuntive un'interfaccia con Microsoft Test Manager
Eseguire le attività seguenti per completare gli aggiornamenti necessari per l'interfacciamento con la gestione di test.
.gif "Ff452591.collapse_all(it-it,VS.110).gif")
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 comando seguente, sostituendo i dati per gli argomenti mostrati quindi scegliere la chiave 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 Specificare il tipo di bug da registrare mediante Microsoft Test Manager.
Torna all'inizio
2.Concedere le autorizzazioni ai membri del team di test
È 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 le autorizzazioni del nodo area dalla pagina di amministrazione di Team Web Access.Vedere Gestione delle autorizzazioni e Creare e modificare aree e iterazioni.
È possibile impostare autorizzazioni della raccolta di progetti da Team Explorer scegliendo Team, Impostazioni insieme di progetti team, Sicurezza, aprire e utilizzare la console di amministrazione per Team Foundation, o tramite gli strumenti da riga di comando di tf e di TFSSecurity.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 quando migliorano TFS
Quando si esegue l'aggiornamento da Visual Studio Team System 2008 Team Foundation Server al 2012, si riceve gli aggiornamenti apportati al 2010 al 2012.È una serie di modifiche architetturali eseguite con la versione del 2010.Per ulteriori informazioni sulle modifiche apportate l'aggiornamento alla versione più recente di TFS da Visual Studio Team System 2008 Team Foundation Server, vedere le risorse seguenti:
Team Foundation Server 2010 concetti chiave post di blog)
Aggiornare un progetto team aggiornato accedere alle nuove funzionalità (VS l'articolo 2010 ALM)
Individuazione dei rapporti dopo l'aggiornamento a Team Foundation Server 2010 (VS l'articolo 2010 ALM)
Modifiche e aggiunte allo schema del cubo di Analysis Services (VS l'articolo 2010 ALM)
Modifiche apportate ai progetti team e ai modelli di processo predefiniti durante l'aggiornamento di Team Foundation Server (VS l'articolo 2012 ALM)
Vedere anche
Concetti
Aggiornare un progetto team aggiornato per accedere alle nuove funzionalità
Altre risorse
witAdmin: personalizzare e gestire oggetti per il rilevamento degli elementi di lavoro