Archives mensuelles : mars 2013

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

image

Déploiement automatisé avec TFS 2012 (Partie 1)

Nous avons vu précédemment comment intégrer les modifications de schémas d’une base de données dans un process d’intégration continue, la prochaine étape naturelle après la mise en place d’un processus est d’arriver à automatiser le déploiement d’une application directement depuis une build.

Le principe est simple : arriver à déployer une build en un seul click que cela soit vers un environnement de tests ou un environnement de production.

image

TFSDeployer est un projet CodePlex qui permet de mettre en place cela assez simplement.

Le principe est simple, TFS permet de définir des indicateurs qualité de builds :

image

TFSDeployer permet de s’abonner au changement d’indicateur qualité sur une build et de déclencher un script batch ou un script powershell lors de changement.

Vous pouvez ainsi récupérer toutes les informations nécessaires sur la build en question et lancer votre script de déploiement.

Exemple : Un testeur va sur la fiche de la build qu’il souhaite tester, sélectionne la qualité “Ready for Initial Test”, et automatiquement la build se déploie sur son environnement de tests.

Pour l’installation de TFSDeployer et la préparation des scripts je vous laisse soin de suivre les instructions sur les pages dédiées :

Une fois la solution déployée, il vous faut donc définir votre processus déploiement.

Cela se fait en deux étapes :

  • La définition des déploiement
  • L’écriture de script de déploiement

Mise à jour d’un logiciel client

Commençons par le cas le plus simple, la mise à jour d’un poste client. Pour cela une build spécifique existe nous allons donc créer une définition de déploiement qui permettra de déployer sur une machine de test.

Pour cela créer le fichier xml adéquat (comme indiqué dans la doc) et le placer dans le contrôleur de code source.

Dans mon cas, plusieurs testeurs interviennent sur les différents projets et disposent de leurs propres environnements de tests (machines physiques ou VM).

J’ai donc commencé par créer un indicateur de qualité de build par personne :

image

Le fichier de définition des déploiements a été créé en conséquence :

image

Comme vous pouvez le constater, j’ai opté pour l’utilisation de scripts batch traditionnels et non de scripts Powershell.

J’ai également ajouté un paramètre de script additionnel “ScriptParameter” qui me permet d’indiquer le nom de la machine sur laquelle je souhaite déployer ma build.

Passons maintenant à la création du script en lui-même.

Pour comprendre comment créer des scripts de déploiement et récupérer les différents arguments, rendez-vous dans le dossier Samples de TFSDeployer vous y trouverez toutes les infos nécessaires.

Exemple pour un .bat :

image

Pour la copie vers la machine de tests, il suffit donc de faire une “simple copie” de fichiers à ceci près qu’il faut la faire sur une machine distante.

copy %1*.* C:LoginspaceAdb.net

C:LoginspaceAdb.net étant un chemin fixe d’installation du client WPF.

Pour cela deux possibilités :

  • On créé un partage réseau (ou on utilise un existant du type NomMachineC$ ) et on effectue directement la copie comme ceci.
  • Autre solution plus exotique mais vraiment très intéressante et très puissante : l’utilisation d’un super outil de Sysinternals nommé “PsExec”

PsExec

PsExec est un outil en ligne de commande de SysInternals qui permet de lancer des process sur des machines distantes sans prendre la main dessus :

image

Par exemple, nous sommes capable d’effectuer un ipconfig sur une machine distante nommée “Froggiestation” depuis la machine « Patrice-Tablet” et même de récupérer les résultats de cette exécution via la simple ligne de commande présente ci-dessus.

Nous allons donc utiliser cette technique pour effectuer la copie des fichiers assez simplement :

image

L’exécution de cette ligne de code effectuera la copie de fichiers non pas depuis la machine d’exécution du script mais depuis la machine passée en paramètre dans le script.

Ainsi le « C:LoginspaceAdb.net pourra dynamiquement être celui de la machine “VMDovadisChristine” ou “VMDovadisSandrine” ou autre en fonction des infos définies dans la définition du déploiement.

Une fois ce script fait il faudra le placer dans un fichier “DeployToTestEnvironment.cmd” en source control à côté de cette définition pour automatiquer le lancer lors du changement de la qualité d’une build.

Nous verrons ensuite dans la deuxième partie en quoi psexec peut nous permettre d’aller beaucoup plus loin dans l’automatisation de ces déploiements.

Dans les prochaines parties nous verrons en effet comment déployer les mises à jour de schéma de bases de données,  et comment déployer un service Windows (avec arrêt et démarrage à distance).

Stay tuned !

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.

Les webcast des Techdays 2013 sont disponibles

Ca y est ! Les webcast des sessions des TechDays 2013 sont à présent disponibles !

Microsoft TechDays - 12, 13, 14 février 2013 au Palais des Congrès de Paris

Vous pouvez y retrouver les deux sessions que j’avais présenté :

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_thumb.png

Intégration Continue de BDD avec SQLCompare de RedGate

Nous utilisons SQL Source Control de RedGate pour le gérer le versionning de nos bases de données ainsi que SQLCompare afin de générer les scripts de mise à jour d’une version à une autre. Cette solution est en effet peu coûteuse et à mon sens plus simple à utiliser que les outils proposés par Microsoft.

L’objectif de la mise en place d’intégration continue est d’arriver à déployer de manière automatique toutes les modifications sur une base de données destinée aux tests.

Pour notre scénario exemple, j’ai donc une base de données DBTest liée au source control, et une base de données DBTest_CI non liée au source control et qui sera automatiquement mise à jour par le serveur de builds (celle-ci peut évidemment être sur un autre serveur) :

image

Pour arriver à impacter la base DBTest_CI à chaque checkin d’une modification sur la base versionnée, il est donc nécessaire de créer un processus de build en intégration continue :

image

Une fois le processus de build défini, il est nécessaire de rajouter une tâche au processus de build : cette tâche permettra d’appeler SQL Compare selon le principe suivant :

image

SQL Compare ne va pas effectuer un compare entre le source control et la base de données d’intégration mais entre le dossier de scripts présent sur le source control et cette même base.

Pour cela nous allons utiliser le fait que le processus de build par défaut un getlatest pour directement récupérer la dernière version des scripts SQL.

Pour avoir de souplesse dans les modifications du processus de builds je préfère souvent externaliser les commandes à réaliser via un fichier .bat ou un fichier powershell. L’intêret est que le développement en est beaucoup plus simple (plus besoin de fait un checkin/checkout de la définition de la build à chaque modification), l’inconvénient est que cette définition n’est donc pas versionnée.

Vous pouvez donc utiliser cette technique dans vos phases de définition/personnalisation de de builds et ensuite pousser vos modifications sur le source control une fois que vous avez terminé pour garder les avantages des deux solutions.

Pour lancer la commande vous pouvez utiliser l’activité InvokeProcess et spécifier en argument de la commande à lancer les informations souhaitées :

image

De plus comme vous pouvez le voir, afin d’avoir un retour dans le log de la build, j’ai placé une activité WriteBuildMessage au niveau de la gestion de l’output ce qui permettra d’avoir une tracabilité au niveau des actions effectuées.

Concernant mon .bat donc, la commande est assez simple :

SNAGHTML61b1df96

J’indique à SQL Compare d’utiliser le dossier de scripts SQL qui a été getlatesté par le processus de build, j’indique ensuite les informations de connexion au second serveur. A noter que j’utilise l’authentification SQL afin de me simplifier la vie. Le paramètre /sync indique enfin à SQL Compare de directement exécuter le résultat du compare pour synchroniser les deux sources de données.

Le résultat est que lorsque l’on checkin un ajout d’un nouveau champ dans une table de la base DBTest :

image

Une nouvelle build se déclenche automatiquement :

image

Build qui a pour effet d’automatiquement intégrer les modifications sur la base d’intégration continue :

imageimage

continousintegration

Critique : Continous Integration in .net

Comme indiqué dans le titre de l’ouvrage, ce livre traite de la mise en place du principe d’intégration continue au sein de projets .net.

Pour rester général, les auteurs évoquent cette mise en place via 3 environnements : CruiseControl.net, Team Foundation Server et Team City.

Le message distillé au long des plus de 300 pages est clair, la mise en place d’intégration continue ne nécessite pas un investissement financier important (peut être gratuit via les 3 produits cités sous différentes conditions), il nécessite un investissement en montée en compétence, et en temps d’implémentation qui va très vite être rentabilisé.

Gestion des sources, compilation, feedback, mise en place de tests, analyse statique via FxCop, StyleCop et NDepend, gestion des changements de schéma de BDD, génération de projets de setup, et génération de documentation, tous les sujets techniques sont évoqués et décris de manière pratique.

Le parti pris d’évoquer les 3 environnements à certainement pesé sur le fait que l’ouvrage ne décrit pas en profondeur les fondamentaux, ne donne pas la part belle à “la théorie”, au pourquoi du comment, ni aux concepts associés (les feature flags par exemple).

Continuous Integration in NET est un bon ouvrage pour les débutants en intégration continue qui souhaite se mettre de manière pratique via un des 3 environments cités ci-dessus. Ceux d’entre vous qui maitrisent déjà les notions de base et qui cherchent un ouvrage de référence préférerons passer le chemin et se diriger vers un ouvrage plus théorique.

image

FeatureFlags : Initial Checkin sur CodePlex

Comme indiqué dans le titre, je viens de faire un premier checkin de mon état d’avancement de la librairie de gestion de FeatureFlags sur CodePlex.

image

Vous pouvez accéder au portail du projet à cette adresse : http://featureflags.codeplex.com

Pour rappel du scope actuel :

  • Création de Feature
  • Gestion de Flip au niveau code ou au niveau UI (WPF uniquement)
  • Persistence de l’état des features dans une base SQL Server

Je vais très prochainement faire une vraie application de démo pour montrer l’utilisation de librairie ainsi que la documentation pour montrer comment étendre le stockage de l’état des features.

Toutes les remarques, idées, critiques sont les bienvenues ! N’hésitez pas à m’en faire part via l’issue tracker du projet directement sur CodePlex.