Migration VSTS vers TFS 2015

Récemment j’ai dû effectuer une migration d’un code source situé sur un VSTS vers le TFS 2015 On-Premise du client. C’est un scénario qui n’est pas officiellement supporté par l’outil TFS Integration Platform, mais je n’ai pas rencontré de soucis majeur (j’ai migré uniquement le code source et non les work items).

Pour rappel TFS Integration Platform est un outil développé par l’équipe ALM Rangers qui permet d’effectuer des migrations entre différentes versions de TFS. Les migrations peuvent être interrompues puis reprises. Cependant cet outil n’est plus mis à jour depuis 2012. A noter pour une migration dans le sens inverse, Microsoft a lancé un outil en preview : TFS Database Import Service for Visual Studio Team Services

Prérequis

  • un serveur SQL (SQL Express peut suffire) plus ancien que SQL Server 2014
  • le compte local qui fait tourner l’application doit pouvoir
    • Être administrateur du poste
    • Créer une base de donnée sur le serveur SQL
    • TFS Source : Être membre du groupe « Project Collection Proxy Service Accounts » et avoir des droits de lecture sur le projet
  • Disposer d’un compte pour le VSTS étant membre du groupe « Project Collection Proxy Service Accounts » et avoir des droits de lecture/écriture sur le projet (il peut être différent du compte local)
  • Visual Studio 2012 Pro ou supérieur (Team Explorer 2012 n’est plus disponible en standalone)

Installation

Après avoir double-cliqué sur le .msi, l’écran ci-dessous apparaît. Ici rien de particulier, installer juste le « TFS Integration Tools ».

Vous arrivez ensuite à cet écran où on vous demande la chaîne de connexion SQL, n’oubliez pas qu’à l’installation l’outil va créer une BDD, votre compte doit donc avoir les droits suffisants sur le serveur.

Bravo l’outil est maintenant installé, passons à la création de la migration !

Migration pas à pas

Voici l’écran d’accueil de l’application. La première chose à faire est de cliquer sur « Create New » (colonne de droite).

Avec l’explorateur Windows allez dans le dossier « Team Foundation Server » si ce n’est pas le cas et choisissez « VersionControl.xml ».

Il faut maintenant configurer la migration, veuillez cliquer sur « Configure » et choisir « VC11 Adapter » :

Sélectionner ensuite votre Team Project de source/cible :

Il ne reste plus qu’à lancer la migration et à résoudre les conflits s’il y en a. A noter que vous pouvez très bien mettre en pause la migration ou la finir une première fois, effectuer quelques commits sur la branche source et la relancer. Cela permet une interruption de service plus courte si une équipe est en train de travailler sur le projet durant la migration.

Une dernière petite astuce pour la route, je conseille de faire la migration sur une nouvelle VM que vous « jetterez » après la migration. Cela évite ainsi de polluer son poste de travail avec une vieille version de VS et de se prémunir d’un éventuel redémarrage de son poste de travail alors que la migration est en cours.

La migration est assez longue car vous aurez surement des conflits à résoudre donc je vous conseille de ne pas l’effectuer si vous avez une quantité importante de données.

 

Microsoft Test Manager : Tester un Build

Dans la 1ère partie nous avons vu comment configurer un environnement de test pour Microsoft Test Manager. Nous allons maintenant nous intéresser à comment tester un build sur un environnement configuré et comment faire en sorte que toutes les données qui nous intéresse soient bien collectés, en l’occurence, les données de « Test Impact Analysis« . Ces données permettent de détecter quels tests rejoués en fonction des changement apportés aux code source !

Marche à suivre

  1. Configurer Test Manager pour qu’il se lance toujours en mode administrateur (sinon il n’aura pas les droits pour observer les autres process)
  2. Paramétrer Test Manager (testeur) pour qu’il utilise la configuration créée précédemment en Test settings et la machine où va être déployé l’application comme environnement :
  3. Queue un  XAML build, attendre qu’il finisse. Le premier build va permettre de constituer une base sur laquelle le moteur pourra analyser les différences avec les prochains builds. 
  4. Effectuer le déploiement
  5. Assigner le build au test, une pop-up vous proposant de voir les tests recommandés s’affichera. Assigner un build aux tests permet d’attacher les données de tests à ce build.
  6. Run le Test Plan
  7. Après avoir cliqué sur « Start Test » (pas besoin de coché « Create action recording »), lancer l’application en mode Administrateur afin que le processus tourne avec le même compte utilisateur.
    4
  8. Vérifier à la fin du 1er cas de test que les fichiers « testImpact.xml » et [webServer].testImpactXml sont bien mis en pièce jointe. S’ils ne sont pas présent regarder si vous n’avez pas des fichiers warning afin de déceler des erreurs. 

A Savoir

  • Aucune notification n’apparait si un problème a empêché la collecte d’informations nécessaire à l’analyse
  • Il ne supporte pas bien les multithread/méthodes asynchrone
  • Il détecte correctement le changement de code dans le XAML
  • Test Impact Analysis n’existe pas encore avec le nouveau système de build vNext.
  • Il est préférable qu’un seul application pool utilisant le compte de service tfs et que celui-ci n’ai qu’un seul site web.
  • Le démarrage d’une suite de tests redémarre le serveur IIS

 

Cette procédure fonctionne aussi pour les autres données de tests que l’on peut collecter et rattacher à un build. A ce propos, il faut savoir que pour les données de couverture de code nécessite de labelliser les sources lors du build.  Les données de tests récoltés sont consultables sur le résumé du build dans le portail web tfs (et l’interface est plutôt bien fait !)

J’espère que cette série vous en a appris plus sur les fonctionnalités de Microsoft Test Manager 🙂

Microsoft Test Manager : Créer et utiliser un environnement de Test

Vous connaissez peut-être Microsoft Test Manager, l’outil de Microsoft dédié aux testeurs. Sachez qu’en plus de l’organisation de cas de tests, cet outil permet aussi de collecter des données durant les tests notamment :

  • Les informations système (OS, Naviguateur)
  • Les évènements systèmes
  • Les events Intellitrace
  • La couverture de code du test
  • Les actions utilisateurs (bouton cliqué, texte saisie, etc)

Ces données peuvent tout aussi bien être collectés côté client que côté serveur ! Et quand je dis côté serveur c’est que l’applicatif arrive à tracer les requêtes effectuées au site web IIS faisant tourner vôtre API !

Pour collecter côté client, rien de plus simple le Test Runner intégré à Microsoft Test Manager se charge de tout, mais pour collecter côté serveur, cela nécessite une bonne dose de configuration que nous allons voir ensemble. Dans ce tutoriel nous allons créer un environnement de test pour une application composée d’un client WPF communiquant avec une WebApi.

Cette série de posts sur « Microsoft Test Manager : Créer et utiliser un environnement de Test » sera composée en 2 partie :

  1. Créer un environnement de Test
  2. Tester un build dans un environnement de test

Prérequis :

  • TFS XAML Build
  • License Visual Studio Enterprise ou Test Professionnal
  • 1 application avec du code managé pouvant être traduit en Common Intermediate Language
  • Un compte de domaine TFSTEST
  • Un serveur où seront déployées les applications à tester : TFSTESTSERVEUR
  • Télécharger l’ISO des derniers agents pour Visual Studio 2013 (en effet les agents 2015 ne sont pas compatibles avec Lab Center / Test Manager)
  • Microsoft Test Manager installé sur le poste du testeur
  • Des campagnes de tests dans Microsoft Test Manager

Pour installer le contrôleur et les agents vous pouvez choisir :

  • D’installer le contrôleur sur votre machine de build et les agents sur TFSTESTSERVEUR
  • D’installer le contrôleur sur la machine faisant tourner TFS Web App et les agents sur TFSTESTSERVEUR
  • D’installer le contrôleur et les agents sur TFSTESTSERVEUR

 

Le compte TFSTEST doit être ajouté au groupe administrateur des serveurs où sont installés le contrôleur et/ou les agents (notamment TFSTESTSERVEUR)

L’environnement de test sera ici un « environnement standard » et non un « environnement virtuel »

 

Installer et configurer le Test Contrôleur

  1. Monter l’ISO et à partir du dossier TestController et installer le contrôleur sur TFSTESTSERVEUR.
  2. Le configurer pour qu’il tourne avec le compte TFSTEST et le connecter à la bonne « Collection de projets d’équipe »

image001

  1. Cliquer sur « Appliquer»

 

Installer les agents sur TFSTESTSERVEUR

  1. Monter l’ISO et à partir du dossier TestAgent installer l’agent de test
  2. Configurer l’agent de test pour qu’il tourne avec le compte TFSTEST et l’enregistrer auprès du contrôleur précédemment installé.
  3. TODO Screenshot
  4. Cliquer sur Appliquer

Pour plus d’infos n’hésitez pas à consulter : https://msdn.microsoft.com/en-us/library/hh546460.aspx

 

Créer l’environnement avec Microsoft Test Manager

  1. Allez dans Lab Center puis choisissez l’onglet Contrôleur, vérifiez que votre contrôleur est en ligne.image003
  2. Allez dans l’onglet « Lab », cliquer sur « Nouveau »image005
  3. Etape « Type et nom » : Choisir « Environnement standard » et attribuer un nom
  4. Etape « Ordinateurs » :
    1. Ajouter TFSTESTSERVEUR
    2. Saisir les identifiants du compte TFSTEST
    3. Choisir le type Web Server
  5. Etape « Propriétés de l’ordinateur» : ras
  6. Etape « Avancée » : ras
  7. Etape « Vérification » : Cliquer sur « Vérifier », si tout se passe bien l’environnement devrait être créé.
  8. Cliquez sur « Terminer», l’outil va installer les agents et les configurer sur TFSTESTSERVEUR

Pour plus d’infos n’hésitez pas à consulter :  https://msdn.microsoft.com/en-us/library/ee390842.aspx

 

Créer la configuration de Test avec Microsoft Test Manager

  1. Dans «Lab Center», aller dans « Paramètres de tests » et cliquer sur nouveau
    1. Etape « Général» : Saisir un nom, une description et choisir le type « Manuel »
    2. Etape « Rôles » : Choisir Serveur Web
    3. Etape « Données et Diagnostics » : image008
    4. Etape « Résumé » : Cliquer sur Terminer

 

Et voilà, la configuration de l’environnement est enfin terminée ! A présent vous allez pouvoir collecter les données dont vous avez besoin aussi bien côté client que côté serveur ! Dans le prochain post nous verrons comment rattacher ces données de tests à un build, ce qui va notamment permettre d’utiliser une fonctionnalité unique de TFS, Test Impact Analysis (un algorithme permettant de calculer les tests à rejoués entre 2 builds !).

Microsoft Ignite 2015 – Du lundi 4 mai au Mercredi 6 mai par Stéphane

Par Stéphane,
Pôle SharePoint MCNEXT

LUNDI 4 MAI 2015
1 – DevOps as a strategy for business agility
2 – Deep Div into Safe Sharepoint Branding in Office 365 Using Repeatable Patterns and Practices
3 – Building solutions with Office 365

MARDI 5 MAI 2015
4 – Get Your Hands Dirty with the Office 365 APIs, Authentication, and SDKs
5 – Designing and Applying Information Architecture for Microsoft SharePoint and Office 365
6 – Building business apps like they do in the valley with Angular, Node.js, and more..

MERCREDI 6 MAI 2015
7 – Understanding the IT Pro’s dynamic operations role within DevOps
8 – What’s new for build automation in Team Foundation Server and Visual Studio Online
9 – Bose Turns Up the Volume with Microsoft Office 365
10 – Visual Studio 2015 for Web Developers
11 – Implementing Next Generation SharePoint Hybrid Search with the Cloud Search Service Application

Lire la suite

[JSS 2014] Session : BI et déploiement automatique avec TFS

Speaker : Romuald COUTAUD & Khirdine HADDAR
Level : 200

Objectif : Déploiement des solutions BI (SQL, SSIS, SSAS, SSRS) automatiquement avec TFS

Introduction :
Dans tous les projets BI, il y a différentes façons de gérer l’industrialisation de nos projets (SQL, SSIS, SSAS, SSRS). Cette session va permettre d’illustrer TFS (Team Foundation Server), l’un des moyens d’industrialisation de ces projets en automatisant la génération et le déploiement des livrables dans les différents environnements (Dev, Intégration, Prod).
Ce qui va être présenté ici, ce sont juste le versioning des solutions ainsi que la génération et le déploiement automatique des différents projets (TFS Build).

TFS :

  • Gestion des versions des projets
  • Packager les livrables
  • Build TFS
    • Extraction et copie automatique sur le serveur
    • Génération des projets (se fait à l’aide de MSBuild, un framework dotNet)
    • Déploiement

Le déploiement se fait à l’aide de WWF (Windows Workflow Foundation). Il est possible d’utiliser des scripts PowerShell pour compléter ces tâches.
Beaucoup de DLL (codeplex) ont été développées par la communauté et seront utilisées.

Outils :
SSIS : MSBuildSSIS2012 (génération & déploiement)
SSAS : SSASHelper (génération)
SSRS : SSRSMSBuildTasks

Démo : Déploiement SQL Server

  • définition du Build avec les différents arguments (deploy, environment, …)
    • fait appel à TFSBuild.exe

>> Toute la base a été déployée sur l’instance DB indiquée, avec les schémas associés.

Démo : Déploiement SSIS

  • le fichier .proj a été modifié pour prendre en compte des options non natifs
  • possibilité d’ajouter un fichier .xaml (WWF) pour avoir des options en plus aussi (BuildSSIS, …)
  • lancement du Build
    • compilation du projet SSIS + déploiement
    • le build peut se lancer aussi en ligne de commande. En changeant les paramètres, on peut facilement déployer les mêmes sources mais sur des instances différentes

Démo : Déploiement SSAS

  • mêmes procédés que précédemment à l’exception qu’un fichier de config.xml peut permettre de customiser ses différentes sources
  • comme indiqué dans la partie Outils, le codeplex pour SSAS ne permet pas de déployer les solutions SSAS. Pour la démo, un script PowerShell a été développé, permettant les déploiements

Démo : Déploiement SSRS

  • pas de surprise par rapport aux précédentes démos. La DLL, récupérée sur codeplex, met à disposition plusieurs méthodes permettant de checker l’existance d’un rapport, l’ajout/suppression d’un rapport, la modification de la source, etc.
  • les étapes de génération et déploiement restent les mêmes que précédemment

Pré-requis :

  • avoir un server TFS configuré
  • adapter tous les codeplex récupérés

Conclusion :
On entend beaucoup parler de TFS (surtout chez les dotNetiens) mais durant mes différentes missions, je n’ai pas eu l’occasion de voir cette méthode mise en place.
Très bonne session, on a pu voir qu’une fois que toutes les configurations, pour chaque type de solution, ont été mises en place, on peut facilement déployer nos solutions sur chacun de nos environnements et du coup, faciliter la tâche à nos chers collègues du support (et nous même).
Reste à voir ce que TFS peut donner avec les tests unitaires par exemple…