2010-01-14 9 views
12

Ho bisogno di un elenco di changeset (o elementi di lavoro) che sono stati creati tra build (posso etichettare build se necessario). Ho bisogno che la lista per il nostro test team (e di pubblicare 'elenco modifiche')Come recuperare un elenco di changeset (o elementi di lavoro) che sono stati archiviati tra le build?

È compito MSBuild in grado di recuperare quella lista e salvare come file di (allora posso elaborare ulteriormente tale elenco.
O forse mi serve per collegare a TFS dal codice C# e recuperare tale elenco (ho familiarità con il recupero di WorkItem in C#)

+0

qualsiasi soluzione finale con il campione completo di codice sorgente a lavorare su di esso? – Kiquenet

risposta

0

Facciamo qualcosa di simile nel nostro processo di creazione TFS. Per fare ciò abbiamo creato un'attività personalizzata MSBuild in C# che effettua la chiamata a TFS per gli articoli È abbastanza semplice creare le attività personalizzate

Ecco un articolo per iniziare a scrivere MSBuild t chiede. http://msdn.microsoft.com/en-us/library/t9883dzc.aspx

Presumo che tu sappia già come eseguire le chiamate a TFS in base alla tua domanda.

2

TFS produrrà automaticamente un elenco di tutti i set di modifiche e gli elementi di lavoro associati archiviati tra due build di successo. Troverete gli elenchi alla fine del rapporto di costruzione.

È possibile impostare una build utilizzata per comunicare con i tester. Quando questa build viene costruita con successo, i tester possono semplicemente esaminare il report di build per vedere quali elementi di lavoro e set di modifiche sono stati impegnati dall'ultima build.

Se si imposta un listener di eventi per la proprietà di qualità build di una build, è possibile inviare un avviso di posta elettronica ai tester quando la qualità archivia modifiche apportate a una versione specifica.

+1

Che ne dici di due build non successivi (ma correlati)? Ad esempio, ho implementato Build 123 quattro giorni fa. Da allora, ci sono state diverse build. Ma ora sono pronto per essere distribuito nuovamente nel mio ambiente di test, questa volta Build 129. C'è un modo per ottenere tutti i changeset e workitems tra Build 123 e 129? – fourpastmidnight

1

Questo post può essere quello che stai cercando. In pratica passi attraverso tutti i link trovando quelli con un Uri che contiene 'changeset'. Non sembra essere una proprietà specifica per questo.

http://blogs.msdn.com/b/buckh/archive/2006/08/12/artifact-uri-to-changeset.aspx

(copiato dal blog in caso di rot)

using System; 
using System.Collections.Generic; 

using Microsoft.TeamFoundation.Client; 
using Microsoft.TeamFoundation.WorkItemTracking.Client; 
using Microsoft.TeamFoundation; 
using Microsoft.TeamFoundation.VersionControl.Client; 

class ChangesetsFromWorkItems 
{ 
    static void Main(string[] args) 
    { 
     if (args.Length < 2) 
     { 
      Console.Error.Write("Usage: ChangesetsFromWorkItems <server> <workitemid> [workitemid...]"); 
      Environment.Exit(1); 
     } 

     TeamFoundationServer server = TeamFoundationServerFactory.GetServer(args[0]); 
     WorkItemStore wiStore = (WorkItemStore)server.GetService(typeof(WorkItemStore)); 
     VersionControlServer vcs = (VersionControlServer) server.GetService(typeof(VersionControlServer)); 

     int workItemId; 
     for (int i = 1; i < args.Length; i++) 
     { 
      if (!int.TryParse(args[i], out workItemId)) 
      { 
       Console.Error.WriteLine("ignoring unparseable argument {0}", args[i]); 
       continue; 
      } 

      WorkItem workItem = wiStore.GetWorkItem(workItemId); 
      List<Changeset> associatedChangesets = new List<Changeset>(); 
      foreach (Link link in workItem.Links) 
      { 
       ExternalLink extLink = link as ExternalLink; 
       if (extLink != null) 
       { 
        ArtifactId artifact = LinkingUtilities.DecodeUri(extLink.LinkedArtifactUri); 
        if (String.Equals(artifact.ArtifactType, "Changeset", StringComparison.Ordinal)) 
        { 
         // Convert the artifact URI to Changeset object. 
         associatedChangesets.Add(vcs.ArtifactProvider.GetChangeset(new Uri(extLink.LinkedArtifactUri); 
        } 
       } 
      } 

      // Do something with the changesets. Changes property is an array, each Change 
      // has an Item object, each Item object has a path, download method, etc. 
     } 
    } 
} 
11

So che questa discussione è un paio di anni, ma ho trovato quando si cerca di ottenere la stessa cosa. Ci sto lavorando da un paio di giorni e ho trovato una soluzione che assolve questo compito specifico. (TFS 2010)

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using Microsoft.TeamFoundation.Client; 
using Microsoft.TeamFoundation.VersionControl.Client; 
using Microsoft.TeamFoundation.Build.Client; 


namespace BranchMergeHistoryTest 
{ 
    class Program 
    { 
    private static Uri tfsUri = new Uri("http://sctf:8080/tfs"); 
    private static TfsTeamProjectCollection tfs = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(tfsUri); 

    static void Main(string[] args) 
    { 

     IBuildServer buildServer = tfs.GetService<IBuildServer>(); 
     IBuildDefinition buildDef = buildServer.GetBuildDefinition("Project", "Specific Build"); 
     IOrderedEnumerable<IBuildDetail> builds = buildServer.QueryBuilds(buildDef).OrderByDescending(build => build.LastChangedOn); 
     /* I had to use some logic to find the last two builds that had actual changesets attached - we have some builds that don't have attached changesets. You may want to do the same. */ 
     IBuildDetail newestBuild = builds.ElementAt(0); 
     IBuildDetail priorBuild = builds.ElementAt(1); 

     string newestBuildChangesetId = newestBuild.Information.GetNodesByType("AssociatedChangeset")[0].Fields["ChangesetId"]; 
     string priorBuildChangesetId = priorBuild.Information.GetNodesByType("AssociatedChangeset")[0].Fields["ChangesetId"]; 

     VersionControlServer vcs = tfs.GetService<VersionControlServer>(); 
     const string sourceBranch = @"$SourceBranch-ProbablyHEAD"; 
     const string targetBranch = @"$TargetBranch-ProbablyRelease"; 
     VersionSpec versionFrom = VersionSpec.ParseSingleSpec(newestBuildChangesetId, null); 
     VersionSpec versionTo = VersionSpec.ParseSingleSpec(priorBuildChangesetId, null); 
     ChangesetMergeDetails results = vcs.QueryMergesWithDetails(sourceBranch, VersionSpec.Latest, 0, targetBranch,VersionSpec.Latest, 0, versionFrom, versionTo, RecursionType.Full); 
     foreach(Changeset change in results.Changesets) 
     { 
     Changeset details = vcs.GetChangeset(change.ChangesetId); 
     // extract info about the changeset 
     } 
    } 
    } 
} 

Spero che questo aiuti la persona successiva a provare a svolgere il compito!

+0

qualsiasi soluzione finale con esempio di codice sorgente completo a lavorare su di esso? – Kiquenet

+0

Ho avuto un paio di problemi con questo codice. Il nodo AssociatedChangeset non esisteva. Hai la versione di Build.SourceGetVersion. Anche versionFrom e versionTo sono trasposti. –

3

So che questo è un vecchio post, ma ho cercato di capire come ottenerlo per molte ore e ho pensato che qualcun altro potesse beneficiare di ciò che ho messo insieme. Sto lavorando con TFS 2013 e questo è stato compilato insieme da diverse fonti. So che non tutti mi ricordo a questo punto, ma i principali dove:

Get Associated Changesets from Build

Queue a Team Build from another and pass parameters

quello che mi mancava da maggior parte degli articoli che ho trovato su questo argomento è stato come prendere la build dettagli e carica i changeset o gli elementi di lavoro associati. La classe InformationNodeConverters era la chiave mancante per questo e ti permette di ottenere anche altri elementi.Una volta ottenuto ciò, sono riuscito a trovare il seguente codice che è piuttosto semplice.

Si noti che se si esegue questo da uno script PowerShell di generazione post è possibile utilizzare la variabile TF_BUILD_BUILDURI. Ho anche incluso il codice che ho trovato per prendere i dati di riepilogo recuperati e caricare l'articolo effettivo.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using Microsoft.TeamFoundation.Build.Client; 
using Microsoft.TeamFoundation.Client; 
using Microsoft.TeamFoundation.VersionControl.Client; 
using Microsoft.TeamFoundation.WorkItemTracking.Client; 

namespace Sample 
{ 
    class BuildSample 
    { 
     public void LoadBuildAssociatedDetails(Uri tpcUri, Uri buildUri) 
     { 
      TfsTeamProjectCollection collection = new TfsTeamProjectCollection(tpcUri); 
      IBuildServer buildServer = collection.GetService<IBuildServer>(); 
      IBuildDetail buildDetail = buildServer.GetAllBuildDetails(buildUri); 

      List<IChangesetSummary> changeSets = InformationNodeConverters.GetAssociatedChangesets(buildDetail); 
      VersionControlServer vcs = collection.GetService<VersionControlServer>(); 
      IEnumerable<Changeset> actualChangeSets = changeSets.Select(x => vcs.GetChangeset(x.ChangesetId)); 

      List<IWorkItemSummary> workItems = InformationNodeConverters.GetAssociatedWorkItems(buildDetail); 
      WorkItemStore wis = collection.GetService<WorkItemStore>(); 
      IEnumerable<WorkItem> actualWorkItems = workItems.Select(x => wis.GetWorkItem(x.WorkItemId)); 
     } 
    } 
} 
+1

Credo che questo sia il più corretto. Ottenere la cronologia di un determinato percorso tra due changeset di build sembra soggetto a errori. –

1

Abbiamo creato etichette per ogni build, sono le stesse del numero di build, che è lo stesso del numero di versione del prodotto su cui operano il nostro QA e supporto.

Quindi, questo funziona per noi:

tf.exe history <BRANCH> /version:L<BUILD_NUMBER_FROM>~L<BUILD_NUMBER_TO> /recursive /collection:http://<our TFS server> 

risultati simile a questa:

Changeset User    Date  Comment 
--------- ----------------- ---------- ------------------------------------- ---------------- 
3722  Sergei Vorobiev 2013-11-16 Merge changeset 3721 from Main 
3720  <redacted> 
3719  <redacted> 
Problemi correlati