Archives par étiquette : TFS2012

image

Comment fonctionne le versionning de base de données ?

J’ai récemment décrit comment mettre en place de l’intégration continue afin d’intégrer automatiquement les modifications de schéma de bases de données sur des bases de données de test par exemple.

On m’a à cette occasion très justement indiqué que j’aurais pu décrire comment fonctionne le versionning de base de données.

Je vais donc décrire via ce post comment gérer dans un SCM une base de données, et je vais l’illustrer via l’utilisation de RedGate SQL Source Control. Les principes fondamentaux restent identiques pour les autres outils de la catégorie.

Cet outil peut être utilisé avec différents SCM : SVN, Git, Mercurial et bien évidemment avec TFS.

Une fois installé, vous disposez d’un nouvel onglet dans SQL Server Management Studio, celui-ci vous permet d’effectuer les principales tâches de gestion de version d’une base de données :

  • Définition du lien avec le SCM de votre choix
  • Opérations Get Latest et Commit

Première étape à réaliser donc, établir le lien entre une base de données et votre SCM :

image

A noter que ce lien étant stocké sur la machine où il est réalisé, il doit être réalisé sur chaque poste de développement.

Une fois le lien effectué, RedGate SQL Source Control va scruter en continu les modifications effectuées sur votre base de données. Il sera ainsi capable de vous indiquer les modifications effectuées lorsque vous souhaiterez faire un commit.

Le développeur peut donc effectuer les modifications qu’il souhaite sur sa base et va ensuite être capable de faire un commit dans le source control de ses modifications.

A noter qu’afin d’être capable de stocker les informations de schémas d’une base de données dans n’importe quel SCM il faut être capable de créer un ou plusieurs fichiers représentant ce schéma.

La plupart des outils de versionning de bases de données fonctionne de la même manière.

Un des objectifs de la mise en place de versionning étant la capacité de recréer from scratch une BDD propre, les outils crééent un script de création de chaque “objet” (Table, Vue, Procédure stockée, Trigger, etc.) et stockent ces fichiers dans le repository.

Ainsi le premier commit effectué depuis RedGate génère la structure suivante dans le source control :

image

Un petit tour dans le dossier de définition des tables et nous retrouvons notre table de test stockée sous forme de fichier .sql :

image

Ce fichier SQL contenant le script de création de la table avec l’ajout du champ et de la clé primaire :

image

A chaque modification de schéma, l’outil de versionning de BDD va ainsi générer le même script de création mis à jour en fonction des modifications de schéma effectuées. Ainsi un ajout de champ “nom_test” génère une nouvelle version du fichier Test.sql :

image

 

Vous retrouverez également ces scripts directement dans SQL Source Control lorsque vous effectuerez un GetLatest :

image

Bien évidemment, lorsque l’on effectue ce GetLatest, RedGate SQL Source Control ne vas pas bêtement remplacer la table en exécutant directement le script de création présent dans le source control mais il va générer un script de modification adéquat  afin de préserver les données présentes :

image

Cette génération de requête à partir du diff de deux requêtes de création est d’ailleurs la seule partie complexe de ce type de logiciels.

image

Créer un nouveau type de WorkItem dans TFS 2012

Je l’indiquais récemment il est parfois très utile de créer un nouveau type de work item dans TFS afin de gérer de nouveaux types d’informations non gérés par défaut par le process template que vous avez choisi lors de la création de votre Team Project.

Par exemple avec le modèle SCRUM vous disposez des types de work item suivants :

  • Product Backlog Item
  • Bug
  • Task
  • Impediment
  • Test Case

Comme vous avez pu l’apercevoir dans un précédent post, nous avons créé un type de Work Item spécifique pour gérer les migrations de données entre nos différents produits et des produits concurrents.

Je vais donc illustrer la création d’un nouveau type de work item en prenant cet exemple concret.

La plupart des éditeurs de logiciels connaissent très bien la problématique des migrations.

Que cela soit entre les différentes gammes de produits que peut proposer un éditeur ou même depuis des produits concurrents, les migrations de données peuvent être complexes et source récurrente de problèmes.

Afin d’être capable de mesurer l’activité suscitée par ces migrations, j’ai décidé de créer un nouveau type de work item qui nous permet d’avoir une bonne visibilité de l’impact de ces migrations sur l’activité du service développement.

Je trouve en effet très important d’arriver à avoir des indicateurs pertinents qui permettent d’avoir une vision précise de l’activité afin de pouvoir prendre des décisions avisées rapidement.

Dans le principe “Build-Mesure-Learn” mis en avant par les méthodes agiles, on a plutôt tendance à se focaliser sur le Build et non sur les deux étapes suivantes qui font pourtant du cycle vertueux permettant d’améliorer les choses en continu.

L’objectif étant de mieux travailler et non pas de travailler plus dur, plus vous arriverez à mesurer finement votre activité plus vous serez susceptibles de parvenir à améliorer les choses.

Les objectifs de ce type de work item Migration sont (entre autres) les suivants :

  • Mesurer le nombre de sollicitations (=interruptions) du service dév. pour chaque migration
  • Mesurer le temps passé sur ces sollicitations
  • Connaitre le nombre de corrections réalisées par migration

Ce qui nous permet sur une période donnée :

  • d’avoir le total de temps passé en assistance sur les migrations
  • de mesurer le nombre d’interruptions (et donc de perte de productivité) lié à cette activité
  • et de voir l’évolution du nombre de corrections effectuées afin d’apprécier la courbe de diminution de celles-ci

La création d’un nouveau type de Work Item correspond tout à fait à ce besoin puisqu’elle nous permet :

  • de stocker les informations souhaitées (nombres d’interruptions, etc.) très simplement
  • de faire des liens avec les work items liés (ex: les bugs)
  • d’utiliser les fonctionnalités de reporting, et d’export des WI vers Excel afin de pouvoir exploiter ces informations simplement

Je ne vais pas détailler la création d’un type de work item car la procédure est décrite dans la documentation :

Je vais plutôt vous montrer le résultat final :

Stockage des différentes informations souhaitées, et affichage des liens avec les autres Work Items :

image

 

Utilisation du champ History pour tracer tous les évènements lié à une migration :

    image

Il ne reste plus qu’à faire des belles statistiques à partir de cela afin d’avoir une vision précise de notre activité liée aux migrations !

image.png

Afficher un nouveau type de Work Item dans le Task Board de TFS 2012

Il peut être utile de créer ses propres types de Work Item pour gérer des informations complémentaires aux Work Item créés par défaut par le process template que vous avez choisi lors de la création de votre Team Project.

Je reviendrais d’ailleurs prochainement sur ce sujet avec un exemple de type WI que nous avons créé récemment afin de gérer une activité spécifique de notre service développement.

L’affichage d’un nouveau type de work item dans la task board semble à priori assez simple.

Dans mon cas, je souhaite afficher mon type de WI avec la même présentation que pour les PBI et les Bugs c’est à dire sous forme de ligne.

Pour cela la documentation indique :

“Backlog items correspond to those types of work items assigned to the Requirements Category. Only backlog items that have been assigned to the current iteration or that have tasks that have been assigned to the current iteration appear on the task board. They can be in any workflow state.”

Aucun problème, direction donc la gestion des catégories pour ajouter mon type de Work Item à la bonne catégorie :

image

image

image

L’import du fichier se fait avec succès et pourtant c’est le drame, un petit tour sur le board pour voir le résultat et on se retrouve avec un message amical :

The current configuration is not valid for this feature. This feature cannot be used until you correct the configuration.

Au lieu d’afficher le board, on se retrouve donc avec ce message qui laisserait penser que les features agile du portail web ont été désactivées.

Point d’autre information, débrouille toi tout seul pour corriger le problème.

La solution pour avancer et trouver la source du problème est de réimporter le fichier de configuration du taskboard : CommonConfiguration.xml (que nous avions déjà vu dans un autre post) :

image

Celui-ci effectue visiblement plus de tests de vérification qu’un simple import de catégories et nous donne de précieuses informations.

Dans mon cas, le problème vient du fait que j’avais implémenté une gestion d’état particulière, où mes WI de type Migration sont à l’état initial “Active” et non pas “New” comme c’est le cas pour les bugs et les PBI.

Une modification de mon type de WI plus tard afin de corriger l’état initial plus tard, le board s’est remis à fonctionner correctement mais mon état “Active” n’était pas pris en compte et les work items étaient donc masquées de mon taskboard pour les voir apparaitre, il faut donc modifier la définition du taskboard via le fichier CommonConfiguration.xml de cette manière :

image

Et bingo, mon nouveau type de work item est à présent affiché :

image

Oubliez DropBox, de vrais outils gratuits de gestion de sources existent !

C’est avec une grande surprise que j’ai découvert il y a quelques jours l’annonce du support de DropBox pour les déploiements dans Windows Azure.

Proposer le support de TFS, de git ou de mercurial d’accord, mais DropBox ?!?

Dropbox : sauvegardez, synchronisez et partagez facilement, en toute sécurité.

DropBox étant un “simple” espace de stockage sur le cloud, j’avais du mal à croire que certains développeurs l’utilisent en tant que repository de source, et pourtant cela semble bien être le cas.

DropBox propose en effet un outil de synchro qui permet de directement mapper un dossier local vers l’espace de stockage DropBox.

Certains développeurs l’utilisent donc comme certains pouvaient utiliser un dossier partagé pour gérer leurs sources.

J’avoue être complètement surpris que l’on puisse encore utiliser ce type de système même pour des tout petits développements.

La plupart des outils de gestion de sources sont gratuits, nécessitent peu d’apprentissage, et ont un coût d’utilisation (=surcharge de travail) très très très faible.

Même Microsoft fournit ce type d’outil gratuitement :

Vous pouvez en effet côté serveur mettre en place un TFS Express pour des équipes de 5 personnes max, ou encore sans aucune installation utiliser TFS Service.

Côté client, Team Explorer 2012 et un coup de PowerTools (bon ok sur ce coup là l’install est pas vraiment très légère…) permet de gérer n’importe quel fichier directement depuis l’explorateur de fichiers et de bénéficier de bien de fonctions qu’un simple rollback de fichiers :

  • la gestion des changesets : pour quelle raison (=commentaire sur le changeset) a été modifié un fichier (ou un ensemble de fichiers) par qui et quand,  et quel a été le diff exact
  • permet de savoir quels sont les fichiers en cours de modification et par qui, et support des merge en cas de modification multiple
  • Gestion “nommée” de versions de source via des labels
  • etc.

Je ne vais pas vous le faire le coup du Allo ?!? Non mais allo, quoi… Mais vraiment utiliser DropBox comme gestionnaire de source me parait vraiment être d’un autre âge même pour toutes les petites structures et pour les petits projets.

image

Ce que SCRUM nous apporté : Gestion des problèmes

Qu’est-ce que t’as apporté SCRUM depuis que tu l’as mis en place ?

Cette question m’a été posé lors d’un des derniers évènements auquels j’ai pu participer et je dois bien avouer que j’ai eu du mal à formuler une réponse exhaustive tant le nombre d’avantages apporté par notre mise en place de SCRUM est important.

Au lieu de faire un post à rallonge indiquant tous les bénéfices que nous avons pu tirer de cette mise en place, je vous propose une série de posts sur différentes thématiques.

Première thématique abordée :

La gestion des problèmes

C’est une problèmatique simple qui doit être la base de toute démarche d’amélioration, mais qui m’a géné et ennuyé dans la plupart de mes expériences passées.

Chacun d’entre nous a probablement vécu le “syndrome du poisson pourri”. Tout le monde a consience qu’il y a un ou des problèmes bien puant(s) mais personne ne le(s) remonte.

image

Plusieurs raisons peuvent expliquer cela, je vais citer ici ceux qui m’ennuient le plus, le “c’est pas à moi de dire ça” autrement dit le “je ne veux surtout pas prendre la responsabilité de dire ce que je pense”, ou une autre raison (plus excusable sauf d’un point de vue management) le sentiment de ne pas avoir la parole.

SCRUM propose un artefact particulier pour cette gestion des problèmes : les obstacles.

Le principe est très simple : l’équipe doit durant chaque sprint lever les obstacles rencontrés qui empêchent le bon déroulement du projet (ou son meilleur déroulement).

Chaque création d’obstacle doit être signalée lors des scrum quotidiens et sont discutés avec toute l’équipe lors de la rétrospective.

D’un point de vue progression de l’équipe, et amélioration de son autonomie, on peut citer les phases de maturité suivantes : dans un premier temps, le ScrumMaster détecte les obstacles et trouve la solution à ces obstacles, l’objectif étant par la suite (et assez rapidement) que l’équipe lève elle-même les obstacles en les identifiant et en les formulant correctement pour arriver ensuite à à la fois identifier les obstacles mais également à les résoudre seule.

La gestion des obstacles dans TFS 2012

Depuis TFS 2012, Microsoft recommande l’utilisation de SCRUM (il s’agit en effet du process template par défaut des team projects), et propose une gestion d’obstacle simple mais efficace. Le plus compliqué est de trouver le point d’entrée de cette gestion :

image

Les obstacles (impediment en anglais) sont exposés sous la forme d’un type de Work Item particulier qui permet de gérer cette liste avec des obstacles ayant deux états (ouvert et résolu).

image

Conséquences sur l’équipe

Conséquence inattendue lors de la première rétrospective, un des membres de l’équipe avait préparé une liste longue comme le bras avec l’ensemble des problèmes non pas qu’il avait rencontré durant le sprint, mais plutôt des problèmes qui lui courraient sur le ciboulot depuis quelques temps.

Plus sérieusement, chaque membre de l’équipe se sent plus impliqué et sait qu’il a la parole pour remonter et discuter ouvertement des problèmes rencontrés.

Il ne reste plus qu’à arriver à trouver régulièrement ensemble les solutions à ces problèmes afin d’avoir une équipe qui progresse régulièrement et qui ne stagne pas.

image

Team Foundation Server Build qui tombe aléatoirement

Problème :

Votre serveur de build (installé sur le serveur TFS 2012 ou sur une machine dédiée) tombe aléatoirement et se remet à marcher comme par magie tout seul quelques heures après.

Symptômes :

Lorsque le serveur de builds ne fonctionne plus, les builds s’”accumulent dans la queue, et les builds en cours n’avancent pas, et aucun log n’est disponible sur celles-ci.

Si on se connecte sur la console d’administration on se rend compte que le controller et l’agent sont dans un état assez étrange :

image

Lorsque l’on clique sur le lien Détails du service de build on se retrouve avec le message d’erreur suivant :

image

HTTP code 500: System.ServiceModel.ServiceActionException

 

Solution :

Pour comprendre pourquoi vous rencontrez le problème il faut se se rendre dans l’Event Log du serveur TFS et non sur celui du serveur de build.

Dans notre cas, nous avions le message suivant :

image

Un service WCF ne peut pas se monter car il y a moins de 5% de RAM disponible sur le serveur TFS, et cela impacte le serveur de build.

Un petit tour vers le Task Manager pour trouver le fautif :

image

SQL Server prenant beaucoup de RAM, il a suffit de limiter le volume de RAM MAX pris par celui-ci afin de résoudre le problème :

image

Problem solved !

image

Les vidéos de l’ALM Summit sont disponibles

image

Les vidéos de l’ALM Summit 3 qui a eu lieu du 28 Janvier au 1er février au conference center de Microsoft à Redmond sont disponibles sur Channel 9 :

http://channel9.msdn.com/Events/ALM-Summit/ALM-Summit-3

Les sessions de ce summit sont organisées autour de 4 tracks :

Je vous recommande de passer un peu de temps à consulter les enregistrements de certaines de ces sessions, elles sont très souvent d’excellente qualité.

Je n’ai pour ma part pas encore eu le temps d’en visionner la majorité d’entre elles, mais je reviendrais vers vous lorsque cela sera le cas afin de vous recommander celle que j’ai trouvé les plus pertinentes.

image

VM de démo d’un scénario DevOps avec TFS et SCOM

Brian Keller a publié le mois dernier une VM vous permettant de tester le scénario DevOps proposé par Miccrosoft grâce à TFS et SCOM : http://blogs.msdn.com/b/briankel/archive/2013/02/07/team-foundation-server-2012-and-system-center-2012-operations-manager-integration-virtual-machine-and-hands-on-lab-demo-script.aspx

L’idée est simple et l’implémentation prometteuse : votre service IT monitore le bon fonctionnement de vos applications grâce à System Center Operations Manager (SCOM) et lors d’un incident, il a la possibilité (en cas de détection d’un potentiel bug et non d’un incident d’exploitation) de créer un Work Item de type Operational Issue dans TFS.

Ce WI peut ensuite être traité par le service développement efficacement car il peut contenir les informations liées à une exception mais également un fichier de trace IntelliTrace plus ou moins riche en fonction du fait que l’IT ait activé ou non la collecte directement depuis SCOM.

Un scénarion de communication entre IT et Dév très intéressant que vous pouvez consulter via cette démonstration :

image

ou via la VM de démonstration proposée dans le post indiqué ci-dessus. Attention, il vous faudra un “monstre” pour être capable de la faire fonctionner correctement. La VM est en effet un contrôleur de domaine avec TFS, Sharepoint, SQL Server, SCOM, Visual Studio d’installé, il vous faudra donc au bas mot 12Go de RAM de disponible et un disque dur bien rapide pour la faire fonctionner dans des conditions acceptables.

image

Forcer les developpeurs a mettre des commentaires de changesets pertinents

Ecrire des commentaires de checkins pertinents fait parti  des tâches simples que l’on a du mal à faire comprendre et accepter des équipes.

Les tâches non liées à l’écriture de code mais qui sont là pour faciliter la maintenance des applications (via dans le cas présent une meilleure traçabilité des modifications effectuées) sont il est vrai souvent considérées par les développeurs comme des tâches moins importantes, moins prioritaires, des tâches de seconde classe.

Par fainéantise, ou par désintérêt on se retrouve le plus souvent avec ce type de commentaire :

image

Des commentaires (lorsqu’ils sont présent ce qui n’est pas le cas pour le changeset 7817) qui n’ont aucune valeur.

Le problème est important puisque cela conduit à ce genre de choses :

image

Un historique de fichier inutilisable  où on ne sait pas ce qui s’est passé sauf à passer beaucoup de temps à faire des compare entre chaque changeset.

Lors d’une discussion avec un responsable ALM, celui-ci m’indiquait qu’il n’arrivait pas à arriver à ce type de résultat :

image Un résultat certes imparfait mais quand même de qualité, avec des information utiles qui pourront être consultées dans le futur.

Pour parvenir à cela, et bien évidemment après avoir expliqué à l’équipe en quoi il est important de placer des commentaires pertinents, j’ai été obligé de passer en mode “dictateur”, et TFS propose une solution simple pour y arriver : les alertes.

Afin “d’encourager” les membres d’une équipe il suffit de se créer une alerte sur tous les checkins lié à un Team Project :

image

Une fois le mail d’alerte reçu, sachez qu’il est possible de directement répondre à ce mail afin de communiquer avec le développeur. – Je vous invite à consulter cet ancien post qui décrit le process -.

Ainsi vous pouvez réagir très rapidement à ces mauvais commentaires en demandant au développeur fautif de modifier à posteriori son commentaire afin qu’il soit pertinent.

Après avoir reçu plusieurs mails de rappel à l’ordre demandant de corriger le problème, les plus récalcitrants rentrent ainsi dans le bon chemin sur une période de temps assez courte (environ 1 mois dans mon cas).

SNAGHTML62193f3

Faire du reporting simplement avec TFS OData et Tableau

Lors de la session sur la visibilité des applications Windows 8, j’ai présenté certaines fonctionnalités à partir de l’application exemple TFSDashboard.

Cette application utilise les services OData exposés via ce package additionnel : http://www.microsoft.com/en-us/download/details.aspx?id=36230

A noter que ces services OData sont installés par défaut et disponibles sur TFS Service : https://tfsodata.visualstudio.com/

Une fois ce package installé vous pouvez requêter directement les informations stockées par TFS (Team Projects, Work Items, Builds, Changesets, etc.) depuis des applications tiers (Windows 8, Windows Phone, Web, etc.) sans avoir à utiliser le SDK de TFS.

Autre possibilité, utiliser ces services afin de proposer à certains utilisateurs (ScrumMaster ou Product Owners) de créer leur propre reporting.

Afin d’illustrer cela, je vous propose d’utiliser Tableau Public, cette version de Tableau est gratuite et permet aux utilisateurs finaux de créer des rapports intéractifs depuis des fichiers Excel, des fichiers texte ou encore des services OData.

Pour cela créer une nouvelle connection en spécifiant la requête que vous souhaitez exécuter :

SNAGHTML62193f3

Indiquer les champs que vous souhaitez utiliser en lignes et colonnes mais également vos filtres :

SNAGHTML62397a3

Une publication plus tard et on dispose d’un rapport interactif permettant d’avoir une vision de l’activité des développeurs par rapport à leurs checkins :

En savoir plus :
Télécharger TFS OData
Télécharger Tableau Public