2. on récupère la liste des folders (branche) ;

[code language= »csharp » light= »true »]
var items = vcs.GetItems(sourceCodeArea, VersionSpec.Latest, RecursionType.OneLevel, DeletedState.NonDeleted, ItemType.Folder).Items;
[/code]

3. pour chacun de ses folders, on vérifie la cohérence du nom par rapport au filtre précisé :

[code language= »csharp » light= »true »]
if (item.ServerItem.ToLower().Contains(filter.ToLower()))
[/code]

4. une fois récupérées, les branches seront ajoutées dans une liste d’objets maisons pour être gérées plus tard.

 

2ième étape:  récupérer les définitions de build existantes:

[code language= »csharp »]
var tfs = new TfsTeamProjectCollection(_TFSserver);
tfs.Authenticate();
var buildServer = (IBuildServer)tfs.GetService(typeof(IBuildServer));
var buildDefinitionList = new List<IBuildDefinition>(buildServer.QueryBuildDefinitions(TEAM_PROJECT));
[/code]

Afin de déterminer si les builds n’existent pas déjà, il faut en premier lieu récupérer la liste des builds existantes.

Les instructions ci-dessus permettent d’interroger le serveur TFS pour cela.

Ici, le TEAM_PROJECT  est simplement une constante représentant le nom du projet d’équipe.

L’appel à  buildServer.QueryBuildDefinitions va fournir l’ensemble des builds existantes pour le projet.

 

3ème étape:  parcourir la liste des branches et créer les builds inexistantes:

[code language= »csharp »]
if (!buildDefinitionList.Exists(x => x.Name == TfsBuildServices.BuildName(projectName, branch)))
                {
                    IBuildDefinition CIBuild = buildDefinitionList.Where(x => x.Name == projectName + "_CI").First();
                    if (CIBuild != null)
                    {
                        var newbuild = buildServer.CreateBuildDefinition(TEAM_PROJECT);
                        newbuild.CopyFrom(CIBuild);
                        newbuild.Name = TfsBuildServices.BuildName(projectName, branch);
                        BuildSettings settings = new BuildSettings();
                        var process = WorkflowHelpers.DeserializeProcessParameters(newbuild.ProcessParameters);
                        settings.ProjectsToBuild = new StringList(((BuildSettings)process["BuildSettings"]).ProjectsToBuild.ToString().Replace("DEV",branch));
                        process.Remove("BuildSettings");
                        process.Remove("ProjectsToBuild");
                        process.Add("BuildSettings", settings);
                        process.Add("ProjectsToBuild", new string[] { settings.ProjectsToBuild.ToString() });
                        newbuild.ProcessParameters = WorkflowHelpers.SerializeProcessParameters(process);
                        newbuild.DefaultDropLocation += @"" + projectName;
                        newbuild.Workspace.Mappings[0].ServerItem = newbuild.Workspace.Mappings[0].ServerItem.Replace("DEV", branch);
                        newbuild.Save();
                    }
                }
[/code]

1. une simple requête linq sur le nom de la build permet de passer la création si la build existe déjà

[code language= »csharp » light= »true »]
if (!buildDefinitionList.Exists(x => x.Name == TfsBuildServices.BuildName(projectName, branch)))
[/code]

L’appel  à TfsBuildServices.BuildName  permet de centraliser et de formaliser  la création du nom de la build 

2. on récupère la build d’intégration continue qui va nous servir de modèle pour la nouvelle définition 

[code language= »csharp » light= »true »]
IBuildDefinition CIBuild = buildDefinitionList.Where(x => x.Name == projectName + "_CI").First();
[/code]

3. on initialise la nouvelle build avec le modèle

[code language= »csharp » light= »true »]
var newbuild = buildServer.CreateBuildDefinition(TEAM_PROJECT);
  newbuild.CopyFrom(CIBuild);
[/code]

4. la modification des paramètres

La build definition utilise des BuildSettings pour enregistrer ses paramètres :

[code language= »csharp »]
BuildSettings settings = new BuildSettings();
                        var process = WorkflowHelpers.DeserializeProcessParameters(newbuild.ProcessParameters);
                        settings.ProjectsToBuild = new StringList(((BuildSettings)process["BuildSettings"]).ProjectsToBuild.ToString().Replace("DEV",branch));
                        process.Remove("BuildSettings");
                        process.Remove("ProjectsToBuild");
                        process.Add("BuildSettings", settings);
                        process.Add("ProjectsToBuild", new string[] { settings.ProjectsToBuild.ToString() });
                        newbuild.ProcessParameters = WorkflowHelpers.SerializeProcessParameters(process);
                        newbuild.DefaultDropLocation += @"" + projectName;
                        newbuild.Workspace.Mappings[0].ServerItem = newbuild.Workspace.Mappings[0].ServerItem.Replace("DEV", branch);
[/code]

Ces settings sont sérialisés sous forme de dictionnaires et doivent donc être réédités pour cadrer avec le besoin spécifique UAT:

• la copie de la build CI pointe par exemple vers la solution à compiler $/Project/dev/Appli1/Appli1.sln . il faut donc modifier ce répertoire pour celui UAT : 

[code language= »csharp » light= »true »]
settings.ProjectsToBuild = new StringList(((BuildSettings)process["BuildSettings"]).ProjectsToBuild.ToString().Replace("DEV",branch));
[/code]

• de la même manière le default drop location contient celle de la build CI et doit être modifié : 

[code language= »csharp » light= »true »]
newbuild.DefaultDropLocation += @"" + projectName;
[/code]

• et enfin le modèle objet de la définition de build contient aussi le mapping vers le répertoire source controle mappé qui doit lui aussi être remplacé : 

[code language= »csharp » light= »true »]
newbuild.Workspace.Mappings[0].ServerItem = newbuild.Workspace.Mappings[0].ServerItem.Replace("DEV", branch);
[/code]

5. on sauvegarde, laisse 15 min au four : et hop. la build est créée !

[code language= »csharp » light= »true »]
newbuild.Save();
[/code]

 

4ième étape:  supprimer les builds des anciennes branches :

Récupération de la liste des branches supprimées :

[code language= »csharp » highlight= »2″]
var items = vcs.GetItems(area, VersionSpec.Latest, RecursionType.OneLevel,
DeletedState.Deleted,
ItemType.Folder).Items;
[/code]

Pour chacune des anciennes branches on récupère la définition de la build associée (si elle existe)

[code language= »csharp » highlight= »4″]
IBuildDefinition UAT_CIBuild = buildDefinitionList.Where(x => x.Name == TfsBuildServices.BuildName(projectName, branch)).FirstOrDefault();
if (UAT_CIBuild != null)
{
buildServer.DeleteBuilds(UAT_CIBuild.QueryBuilds());
}
[/code]

A noter: pour pouvoir supprimer une définition de builds il faut que les historiques de run soient eux-aussi supprimés, c’est pourquoi l’appel buildServer.DeleteBuilds(UAT_CIBuild.QueryBuilds());  est fait ainsi  : cela supprime l’ensemble.

 

5ième étape:  emballer dans une petite application :

Je ne rentrerai pas dans les détails sur ce point, mais avec les éléments fournis rien de plus simple que de réunir tout cela dans une application qui tourne à intervalle régulier et exécute ces appels afin de synchroniser les définitions de builds et les branches.

 

Pour aller plus loin 

http://nakedalm.com/

https://msdn.microsoft.com/fr-fr/vstudio/ff637362.aspx

ALM ranger’s site

Prochaine étape 

Dans le prochain billet j’expliquerai comment se passer de l’application console en intégrant ce code au sein d’activités de build maisons et comment créer notre propre template de build avec tout ceci.

 

Laurent.