Tricks : Gérer son numéro de version au niveau de la solution

Si comme moi, vous avez toujours rêvé de pouvoir gérer son numéro de version au niveau de solution et non au niveau de chaque projet cet article est fait pour vous !

Marche à suivre

  1. Click droit sur la solution -> Ajouter un nouvel item -> Classe Visual C#
  2. Nommez le fichier « SharedAssembyInfo.cs »
  3. Reprenez toutes les infos d’un « AssemblyInfo.cs » d’un projet existant et copier-coller le contenu dans « SharedAssembyInfo.cs ». Les fichiers « AssemblyInfos.cs » se trouvent dans la rubrique « Properties » située juste au-dessus de « Références ».
  4. Mettez en commentaire tout le contenu des différents « AssemblyInfo.cs »
  5. Sur chaque projet :
    1. Click droit -> Ajouter élément existant
    2. Sélectionner le « SharedAssembyInfo.cs »
    3. Choisir d’ajouter en tant que lien
    4. Faites glisser le fichier ajouté au projet dans le dossier « Properties »

A savoir

Vous n’êtes pas obligé de partager toutes les informations dans le « SharedAssembyInfo.cs », tout ce qui est spécifique à chaque projet vous pouvez le laisser dans le « AssemblyInfos.cs » du projet.

Pour allez plus loin

Savez-vous que vous pouvez générer un numéro de build sans usine de build depuis Visual Studio? Pour cela il suffit de :

  1. Mettre en commentaire l’attribut « [assembly: AssemblyFileVersion(« 1.0.0.0 »)]» que l’on trouve dans « SharedAssembyInfo.cs » ou « AssemblyInfos.cs ». Seul l’attribut « AssemblyVersion » doit être spécifié.
  2. Mettre l’attribut « AssemblyVersion » sous la forme : « [assembly: AssemblyVersion(« Majeur.Mineur.* »)] »

Après ça, à chaque build, Visual Studio va remplacer l’étoile par un « numéro de build » et un « numéro de révision » :

  • Numéro de build : Le nombre de jour depuis le 1er Janvier 2000.
  • Numéro de révision : Le nombre de secondes depuis minuit divisé par 2.

 

J’espère que cet article vous aura été utile 😉

 

Sources

http://weblogs.asp.net/ashishnjain/sharing-assembly-version-across-projects-in-a-solution

http://www.csharpcity.com/2012/visual-studio-automatic-version-numbering/

https://msdn.microsoft.com/en-us/library/k49w9389(v=vs.110).aspx

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 !).

[NCrafts] Continuous delivery, the missing parts

Paul Stack commence cette présentation avec une définition du Continuous Delivery (déploiement continue), qui est composé de principes et de pratiques pour construire, tester , deployer plus rapidement et plus fréquemment.

Les principes:

  1. Le processus doit être répétable et fiable
  2. Tout tâche soit être automatisée
  3. Si quelque chose est difficile, le faire plus souvent
  4. Tout mettre dans un contrôleur de source
  5. Le done (terminé) s’applique à une fonctionnalité livrée
  6. La qualité doit aussi être présente dans le code
  7. Tout le monde est responsable du processus de déploiement
  8. Le processus doit être constamment éprouvé

Lire la suite

[TechDays 2015] Introduction à DevOps

Aujourd’hui les systèmes d’information sont constitués de plusieurs protagonistes : les développeurs, les administrateurs, les manageurs, les testeurs et intégrateurs, et les administrateurs de bases de données.

La problématique que nous rencontrons c’est un mauvais échange ou bien même parfois aucun entre les développeurs (dev) et l’équipe infrastructure (ops) qui est du à un vocabulaires et couches métiers différentes, ce qui conduit à une mauvaise qualités de projets en production ou de livraison.

Qu’est ce que le DevOps

Inventé en 2009 DevOps qui est la concaténation de dev(developpeurs) et ops (opérations =  exploitation) est une philosophie organisationnelle visant à réduire les frictions entre les dev et l’IT (ops) et ayant pour but de faire un projet ensemble.

A qui s’applique t-il

Il peut s’appliquer :

A de multiple type de secteur: web / mobilité, industrie, éditeur de logiciel, founisseurs de services cloud, jeux.

A toute organisation : petite structure (communication plus facile) mais aussi dans les grandes structures (comme Facebook, Linkin, Microsoft, Amazon).

Et pour tout type d’applications : web , mobile, jeux.

Par contre DevOps est moins adapté aux applications de type Client/Serveur (du au déploiement qui se font moins en continue). Lire la suite

[TFS] Configuration avancée de TFS Proxy

Dans mon précédent post j’explique comment installer et configurer un serveur TFS proxy.

Pour rappel un serveur TFS proxy est utile pour des raisons de performances dans le cas d’une équipe de développeurs travaillant sur un site distant.

Après avoir installé et configuré le serveur TFS proxy on peut le configurer plus finement en modifiant le fichier proxy.config

Le fichier proxy.config

Ce fichier qui est au format XML se trouve sur le serveur TFS proxy dans le répertoire :

Program Files /Microsoft Team Foundation Server 12.0/Version Control Proxy/Web Services/VersionControlProxy/

proxy1

Une fois ouvert voici son contenu

proxy2 Lire la suite

[TFS] Configuration de Team Foundation Serveur Proxy

Lorsqu’une équipe de développeurs travaille sur un site distant, l’utilisation du contrôleur de source de TFS peut requérir de la bande passante. Pour pallier à ce problème, on peut utiliser un TFS proxy.

Celui-ci va garder en cache les fichiers et les pièces jointes de test, afin de pouvoir les servir plus rapidement et libérer de la bande passante.

Cependant la configuration matérielle pour ce serveur TFS proxy est plus élevée que celle du serveur TFS.

Configuration Matérielle

Le TFS proxy est donc installé sur un serveur qui se trouve sur le même emplacement que l’équipe distante. Il n’est pas conseillé de l’installer sur me même serveur que le serveur TFS Applicatif.

Voici la configuration matérielle préconisée par Microsoft pour le serveur TFS proxy, en fonction de la taille de l’équipe

Installation et Configuration de Team Foundation Serveur Proxy

Pour installer le TFS proxy, il faut d’abord installer TFS , il s’agit de la même procédure d’installation que TFS

Pour le configurer :

Dans la console d’administration de TFS, cliquez sur Serveur Proxy, puis sur Configurer les fonctionnalités

 

Lire la suite