TFS 2015 : automatiser la création d’une définition de build XAML.

Auteur original, de notre ancien blog : Laurent Jacques

xaml1

xaml2

Aujourd’hui nous étudierons un cas pratique d’utilisation avancée de TFS  (2012,2013 et 2015) et de ses mécanismes de build.

Nous chercherons à automatiser la création et la suppression des définitions de builds avec l’utilisation de l’API de Team Foundation Server avec Visual Studio 2013.

Pour le cas d’étude de ce billet, l’organisation du code source se présente ainsi :

  • une branche dev : le travail courant des développeurs, tous check-in leurs modificationdedans au jour le jour.
  • plusieurs branches uat : en fin de cycle de développement, une nouvelle branche uat_X.Y.Z est créée à partir du dev pour partir en validation (test d’intégration)
  • une branche master : une fois validée la branche uat_X.Y.Z devient la nouvelle branche master : version référence pour les développements.

Ce qui donne par exemple l’arborescence suivante :

/Projet/
       /dev
	       /Appli1
		/Appli2
       /master
		/Appli1
		/Appli2
	/uat_1.2.3
		/Appli1
		/Appli2
	/uat_1.3.0
		/Appli1
		/Appli2

 

L’équipe de développement a mis au point deux définitions de build basées sur la branche DEV :

  • une intégration continue, tournant les tests unitaires automatiques, générant la doc, fournissant les livrables dans un répertoire dépôt;
  • une nightly : déployant les applications sur l’environnement de test tous les jours à 23h.

Problématique 

Une fois validée en interne, le DEV est branché en UAT_X.Y.Z : les définitions de builds ne fonctionnent donc pas sur cette branche.

Actuellement : pour chaque nouvelle branche UAT le lead technique vient créer une nouvelle définition de build UAT et ajouter les différents paramètres.

Besoin 

Automatiser le processus.

Mise en oeuvre

Pour cette première version nous visons la mise en place d’une app console en c# qui ira, à intervalles réguliers, vérifier l’état des branches et gérer les définitions de builds.[…]

Avant toute chose: ajouter les références (v12) dans le projet :

xaml3

1ière étape:  récupérer la listes des branches UAT existantes.:

List<Branch> branchList = new List<Branch>();
using (var tfs = new TfsTeamProjectCollection(_TFSserver))
{
    VersionControlServer vcs = (VersionControlServer)tfs.GetService(typeof(VersionControlServer));
    var items = vcs.GetItems(sourceCodeArea, VersionSpec.Latest, RecursionType.OneLevel,
        DeletedState.NonDeleted, ItemType.Folder).Items;
    foreach (Item item in items)
    {
        // skip self
        if (!item.ServerItem.Equals(sourceCodeArea))
        {
            if (item.ServerItem.ToLower().Contains(filter.ToLower()))
                branchList.Add(new Branch(item.ServerItem, item.CheckinDate, project));
        }
    }
}

Dans le code présent la logique est la suivante:

  1. on fournit comme paramètres :
  • l’url d’accès au serveur TFS ,
  • la zone de départ dans le source (sourceCodeArea) , 
  • un fitre est indiqué qui va permettre de ne ressortir que les branches qui nous intéressent (filter) 
     2. on récupère la liste des folders (branche) ;
var items = vcs.GetItems(sourceCodeArea, VersionSpec.Latest, RecursionType.OneLevel,                                          DeletedState.NonDeleted, ItemType.Folder).Items;

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

if (item.ServerItem.ToLower().Contains(filter.ToLower()))

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:

    var tfs = new TfsTeamProjectCollection(_TFSserver);
    tfs.Authenticate();
    var buildServer = (IBuildServer)tfs.GetService(typeof(IBuildServer));
    var buildDefinitionList = new List<IBuildDefinition>(buildServer.QueryBuildDefinitions(TEAM_PROJECT));

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:

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();
                    }
                }

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

if (!buildDefinitionList.Exists(x => x.Name == TfsBuildServices.BuildName(projectName, branch)))

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 

IBuildDefinition CIBuild = buildDefinitionList.Where(x => x.Name == projectName + "_CI").First();

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

var newbuild = buildServer.CreateBuildDefinition(TEAM_PROJECT);
  newbuild.CopyFrom(CIBuild);

4. la modification des paramètres

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

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);

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 : 
settings.ProjectsToBuild = new StringList(((BuildSettings)process["BuildSettings"]).ProjectsToBuild.ToString().Replace("DEV",branch));
  • de la même manière le default drop location contient celle de la build CI et doit être modifié : 
newbuild.DefaultDropLocation += @"" + projectName;
  • 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é : 
newbuild.Workspace.Mappings[0].ServerItem = newbuild.Workspace.Mappings[0].ServerItem.Replace("DEV", branch);

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

newbuild.Save();

 

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

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

var items = vcs.GetItems(area, VersionSpec.Latest, RecursionType.OneLevel, 
DeletedState.Deleted,
ItemType.Folder).Items;

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

IBuildDefinition UAT_CIBuild = buildDefinitionList.Where(x => x.Name == TfsBuildServices.BuildName(projectName, branch)).FirstOrDefault();
if (UAT_CIBuild != null)
{
   buildServer.DeleteBuilds(UAT_CIBuild.QueryBuilds());
}

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.

 

Soft’it est sponsor Gold de la conférence Ncrafts 2015

ncrafts1

Pour la deuxième année consécutive, c’est avec grand plaisir que nous sponsorisons la conférence sur le développement NCrafts qui se tiendra les 21 et 22 mai prochains à la Grande Crypte dans le 16ème arrondissement de Paris.

L’esprit CLT étant résolument agile depuis plusieurs années, nous ne pouvons qu’adhérer aux valeurs du Manifeste du Software Craftsmanship car pour nous, un logiciel qui fonctionne « tout court » ne saurait être suffisant pour délivrer constamment la valeur à nos clients. Le Crafts est bien plus que ça.

Cet événement à l’initiative de la communauté ALT.NET (bien qu’ouvert aux autres technos) est l’occasion de nous retrouver pour apprendre, échanger des pratiques et techniques de développement autour du Software Craftmanship.
Comme l’année dernière, le line-up des talks s’avère très intéressant avec des speakers de haut niveau : Hadi Hariri (de JetBrains), Tomas Petricek (MVP C# et expert F#), Jérémie Chassaing (acteur influant de la DDD, de l’EventSourcing et du CQRS) ou encore Emmanuel Gaillot et Tomasz Jaskula.

Si cela vous intéresse, vous pourrez venir nous rencontrer et échanger avec nous sur notre stand pendant la conférence ; la quasi-totalité de l’équipe Soft’it sera présente !

De plus, nous vous préparons quelques surprises originales qui sauront ravir tous les Craftsmen. Venez nombreux pour jouer avec nous.

A Bientôt !  

Le chemin vers la qualité est-il unique ? (Part 2 : la Production)

le chemin

Nous avons vu précédemment qu’il n’existait pas de méthodologie parfaite (agile ou non). Que nos besoins en tant qu’unité (équipe, société ou individu) allaient dicter les méthodologies que nous voulons ou pouvons suivre.

A présent, que se passe-t-il lorsque nous produisons ? Comment organiser notre travail effectif afin d’atteindre un niveau de qualité le plus élevé possible ?

Là où les méthodologies peuvent parfois s’arrêter, certaines nous donnent des clés pour améliorer notre code en plus de notre façon de travailler. Et comme le nombre de méthodologies, il est aisé de crouler sous le nombre de « bonnes pratiques » et finalement ne pas savoir par quoi commencer. Voire de s’y perdre et de ne rien faire du tout.

Ici aussi, y a-t-il une bonne méthode à appliquer ?

En plus de notre expérience, deux conférences de Paris Web peuvent nous aiguiller dans cette réflexion.

Tout d’abord, « Code de qualité : ce qu’il faut savoir«  par Julien Wajsberg et Anthony Ricaud et « 100 % de revue de code«  par Agnès Haasser.

 

Quels outils sont utilisés, pourquoi et comment sont-ils intégrés ?

La revue de code est le point commun entre ces deux conférences. Et à raison : cette pratique est initialement la plus […] simple à mettre en place (une chaise suffit !).

La manière classique consiste à faire venir un pair à côté de soi et relire ensemble le code produit à la recherche d’erreurs ou d’oublis techniques comme fonctionnels. Ensuite, de partager sur les améliorations possibles.

Son principal inconvénient reste son coût en temps effectif, tout comme les interruptions que le demandeur réalise auprès de ses collègues.

Chez Soft’it, nous avons pris la décision de ne pas nécessairement impliquer le demandeur dans la revue de code. Le temps est provisionné et c’est à chacun de vérifier ce que les autres ont envoyé. Si besoin, le relecteur fera une remarque directement ou validera simplement le code produit.

Du côté d’Agnès Haasser, les « pull requests » de Git se sont avérés être la meilleure réponse aux besoins de son équipe. Le principe est le même : soumettre son code à la validation des pairs de manière asynchrone. Ce qu’ils ont rajouté est une surcouche de sécurité : préserver la branche master de toute erreur éventuelle. De plus, tous les devs peuvent participer et/ou suivre cette relecture de code, réduisant drastiquement le bus factor.

Une autre pratique pouvant remplacer la revue de code est le pair programming. On place ici aussi 2 développeurs face à une même machine. La revue de code a lieu en même temps que le développement.

Seulement, ce type de mise en place est coûteuse en temps si les développements ne sont faits que de cette manière. Notre choix interne a été de ne l’utiliser que dans trois cas très précis : l’arrivée de nouvelles personnes dans l’équipe, la découverte de nouvelles technologies ou langages et enfin le développement de parties complexes et/ou critiques. Dans le premier cas, le nouvel arrivant participe à la production tout en apprenant. Et nous avons un filet de sécurité en cas de soucis. Ce filet existera également dans le deuxième cas, tout en apportant un recul aux développeurs qui s’émuleront mutuellement. Dans le dernier, l’intérêt est assez évident : deux paires d’yeux valent mieux qu’une. Et si la fonctionnalité est trop complexe, revenir sur le code de quelqu’un peut s’avérer compliqué et finalement faire perdre plus de temps que d’en gagner.

Même si de manière générale le pair programming implique qu’un des développeurs s’occupe du code de production et l’autre des tests, on peut coupler tests et vérification.

 

Le testing, justement. S’il est considéré comme obligatoire chez certains (c’est notre cas chez Soft’it), il ne l’est pas nécessairement d’après messieurs Wajsberg et Ricaud. Ou du moins dès le début.

La décision prise chez Mozilla est de ne pas rendre obligatoire les tests à la création d’une classe. Mais une fois que la première brique est posée, il ne doit plus y avoir de développement sans test.

Pourquoi ce choix ? Parce qu’il est parfois compliqué de définir un premier test concluant lorsque l’on commence à développer une nouvelle fonctionnalité.

Travailler en TDD rendrait évidemment cette règle absurde. Mais cette pratique n’est pas si évidente à mettre en place : certaines architectures, utilisant des ORMs par exemple, rendent l’utilisation de doublures de tests trop lourdes pour être réellement efficaces. On se tournera alors vers des tests d’intégration (qui arrivent plus tard dans le cycle de développement) afin de valider les cas d’utilisation.

Alors quand commencer à tester ?

Lorsque votre architecture le permet. Et elle le pourra toujours très tôt. Lorsqu’il est intéressant de tester également (le faire sur les getters et setters n’a pas d’intérêt en soi). Plus les tests commencent tard, plus il est compliqué de commencer (quel sera le premier test ? Dois-je revenir sur ce qui n’a pas encore été testé ?). 

Leur présence offre un filet de sécurité à l’équipe. Techniquement d’abord : en cas de besoin de refactoring ou de reprise de code par un autre développeur. Ils sécurisent la modification : si on casse quelque chose, on le sait très tôt.
Fonctionnellement, écrire des tests correspondant au cheminement d’un user donnera une meilleure confiance dans le produit terminé. Notamment lors de corrections de bugs. Idéalement, un ou plusieurs tests devront valider la correction, scelleront sa correction et serviront de gardiens face aux régressions.

 

Enfin, l’intégration continue. Le nom du produit varie, mais l’intérêt et l’implémentation restent les mêmes : s’assurer qu’à tout moment, on ne livre pas un produit cassé aux clients.
La solution est modulable : vous pouvez limiter son utilisation à une machine de build, les développeurs sont alors assurés que les fichiers disponibles sur le repository ne sont pas à même de les empêcher de travailler. Exécuter les tests automatiques (unitaires et d’intégration), voire utiliser un analyseur de code (FxCop, NDepend, …) afin de sécuriser les règles de développement. 

Si les pratiques se retrouvent souvent dans les organisations, leurs applications diffèrent parfois très fortement. L’intention est la même : sécuriser les développements et les développeurs. Mais comme dans toute équipe, les besoins et contraintes ne sont jamais les mêmes. Et suivant ces contraintes, chacun doit plier plus ou moins chaque principe ou philosophie. Il se peut que vous arriviez dans une équipe et que certaines de leurs pratiques, notions ou terminologies vous semblent étranges, voire contre-productives. Mais gardez en tête qu’ils ont peut-être des contraintes très fortes qui ne leur permettent pas d’appliquer à la lettre les bonnes pratiques.

Comprenez vos besoins et ceux de l’équipe avant d’amener une réponse toute faite. Prenez en compte leurs peurs, limites et attentes et apportez-leur les pratiques qui leur conviennent.
C’est là le fondement même de l’agilité, utilisez des canevas de solutions plutôt que de vous baser sur celles que vous avez pu connaître avant.

« Livrer chaque jour ce qui est prêt ! » – Le Continuous Delivery chez LesFurets.com, par Dimitri Baeli

Sous l’impulsion de Rui Carvalho, Yannick Grenzinger et Soft’it, le groupe « Continuous Delivery Paris » se relance et a été finalement renommé en « Continuous Delivery to Lean Enterprise – Paris ».

Pour notre premier event public, nous avons la chance d’accueillir un grand nom de la communauté Agile & DevOps : Dimitri Baeli.
Ce dernier est R&D Team Mentor chez LesFurets.com, et aussi organisateur de Lean Kanban France.


Dimitri Baeli va donc faire une conférence/retour d’expérience sur le Continuous Delivery mis en place chez LesFurets.com.
Un site grand public a toujours de fortes contraintes de disponibilité ; il est donc indispensable de pouvoir le faire évoluer continuellement sans impacter le trafic et les utilisateurs, au risque de les perdre.

Le Continuous Delivery est le thème DevOps du moment. Facebook, Etsy, Amazon, et cie. sont en mesure de déployer plusieurs milliers de fois par jour en production et de manière transparente…pourquoi pas nous !
Vous verrez donc différentes techniques, outils et process permettant de garantir à tout moment que chaque développement n’amène pas de régression et peut être délivré en production.

CLT/Soft’it hoste l’événement dans ses propres locaux ; un réagencement de ces derniers a donc été réalisé pour l’occasion. Plus d’une cinquantaine de participants sont attendus. La soirée promet d’être enrichissante !

Nous ne manquerons pas de vous faire suivre cet événement, et de vous donner notre feedback par la suite.

Si vous désirez plus d’informations et/ou vous inscrire au Meetup, c’est ici : http://www.meetup.com/Paris-Continuous-Delivery-to-Lean-Enterprise/events/220046012/

Twitter

http://platform.twitter.com/widgets/follow_button.a5bbbb7216610af1306d56b0f28a67d7.fr.html#_=1424729059607&dnt=false&id=twitter-widget-0&lang=fr&screen_name=softitclt&show_count=false&show_screen_name=true&size=l
window.twttr=(function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],t=window.twttr||{};if(d.getElementById(id))return;js=d.createElement(s);js.id=id;js.src= »https://platform.twitter.com/widgets.js &raquo;;fjs.parentNode.insertBefore(js,fjs);t._e=[];t.ready=function(f){t._e.push(f);};return t;}(document, »script », »twitter-wjs »));

http://platform.twitter.com/widgets/follow_button.a5bbbb7216610af1306d56b0f28a67d7.fr.html#_=1424729059609&dnt=false&id=twitter-widget-1&lang=fr&screen_name=dbaeli&show_count=false&show_screen_name=true&size=l
window.twttr=(function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],t=window.twttr||{};if(d.getElementById(id))return;js=d.createElement(s);js.id=id;js.src= »https://platform.twitter.com/widgets.js &raquo;;fjs.parentNode.insertBefore(js,fjs);t._e=[];t.ready=function(f){t._e.push(f);};return t;}(document, »script », »twitter-wjs »));

DevOps, le monitoring des applications Web comme point d’entrée


De nos jours, les applications web connaissent un boom incroyable. Tout le monde a compris qu’internet est un outil business très efficace qui permet d’augmenter la visibilité de l’entreprise (Marketing), étendre ses marchés (boutique en ligne),…etc.

Voici quelques chiffres sur la situation du commerce en ligne en 2013 :

  • Le nombre des acheteurs en ligne a augmenté de 5% en 2013.
  • La fréquence des achats en ligne est en progression avec une moyenne de 18 transactions par an et par acheteur, contre 16 en 2012.
  • Le nombre de sites marchands actifs a dépassé les 138 000.

* Statistiques avancées par  Elioweb (http://www.elioweb.com/statistiques-e-commerce-france.html)

Donc, contrairement aux débuts d’internet qui étaient constitués de sites vitrines essentiellement. On se retrouve, aujourd’hui, avec des applications Web capables de récolter et de capter les actions des utilisateurs.

Cette révolution a considérablement complexifié les applications Web : logique métier complexe, sécurité, performances…etc.

En outre, de plus en plus d’entreprises abandonnent le développement d’applications lourdes et les remplacent par des applications Web. Cela permet de réduire, voir d’éliminer, les processus de déploiement des applications et des mises à jour sur les postes utilisateurs.
De ce fait, les applications Web apportent un gain de temps considérable et une réactivité presque immédiate quand il s’agit de résoudre des bugs ou de déployer de nouvelles versions.

Du point de vue des équipes informatiques, l’enjeu est énorme. Les applications sont plus complexes, plus sensibles et ont un réel impact financier. Il faut donc avoir un niveau de qualité très élevé en même temps qu’une productivité accrue.

En général, les équipes informatiques sont organisées en plusieurs sous-équipes : les développeurs d’un côté et les opérationnels (administrateurs système, réseau, base de données, messagerie, etc…) d’un autre côté.
Les développeurs ont pour rôle de créer l’application et de la faire évoluer au fil du temps. Ils sont aussi responsables de la correction des éventuels bugs détectés. Les opérationnels, quant à eux, sont responsables de la mise en place des environnements techniques, du déploiement de l’application et du monitoring de l’infrastructure.

Chaque équipe possède ses propres méthodes de travail, ses propres priorités et ses propres métriques.
Cette organisation pose un réel souci pour la collaboration des équipes. Il n’est pas rare de rencontrer l’analyse suivante suite à un problème de performance, par exemple :

  • Admin réseau : « Pas de congestion, tous les routeurs fonctionnent ».
  • Admin système : « Les serveurs ont suffisamment de CPU et de mémoire ».
  • Devs : « Le code de l’application est bon, le même code fonctionne correctement sur l’environnement de pré-production ».

Au lieu de travailler ensemble pour identifier le problème, chaque équipe va analyser le problème de son point de vue et tenter de démontrer que « ça ne vient pas de chez nous »; voire dans certaines cas, essayer de mettre en cause les autres équipes. Mais, malheureusement, il y a bien un problème du point de vue des utilisateurs.

Ce genre de situation peut coûter cher à l’entreprise : perte de clients pour un site e-commerce, planification de stock erronée pour une usine, etc….

Afin d’éviter de tomber dans ce type de situation, une entreprise doit faire évoluer sa culture pour se concentrer sur l’humain, l’organisation du travail et le bon choix des outils de gestion du cycle de vie des applications et des infrastructures.

Cette culture est le cœur même de la philosophie DevOps visant à rapprocher les équipes Dev et Ops. Ce rapprochement permettra aux équipes de communiquer plus efficacement, de partager les mêmes objectifs et de réfléchir continuellement aux différentes pistes d’améliorations de leur travail.

La Journée DevOps Day, qui a eu lieu le 25 novembre 2014 à Paris, s’est penchée sur la problématique de mise en place du processus DevOps dans les projets informatique (voir l’article Tour d’horizon du Microsoft DevOps Day – « Infrastructure as Code » pour avoir une idée sur le contenu de cette journée).

La mise en place d’une culture DevOps au sein d’une entreprise nécessite un travail de sensibilisation et de conviction des équipes. Il ne s’agit pas d’installer un outil, mais de changer complètement les mentalités, la façon de travailler des collaborateurs voire même l’organisation des équipes. Toute tentative de mise en place d’une culture DevOps par simple décision émanant de la direction subira inévitablement un échec et engendrera plus de méfaits que de bienfaits ; la conduite du changement a une place prépondérante ici.

La notion de DevOps est une notion vaste qui couvre tout le cycle de vie d’une application, de son développement à sa mise en production en passant par les différents environnements techniques. Il est vital de mettre en place le processus DevOps de façon graduelle. Vouloir adopter ce processus dans tous les aspects du cycle de vie applicatif en même temps peut s’avérer complexe, voire même périlleux.

Un point d’entrée intéressant pour la mise en place de DevOps est le monitoring des applications déjà en production. Les équipes Dev et Ops pourront coopérer pour mieux réagir aux problèmes rencontrés sur les applications en production.
Le monitoring est, en fait, un bon point de coopération pour les Dev et les Ops. Un mauvais comportement d’une application engagera la responsabilité des Dev et des Ops en même temps. Si les deux parties sont convaincues qu’ils forment la même équipe, ils mettront toutes leurs compétences et leur énergie pour améliorer le processus de monitoring :

  • Choix des bons outils qui reflètent le réel état des applications.
  • Mettre à disposition des Devs des rapports afin qu’ils puissent anticiper les éventuels problèmes lors des prochaines versions.
  • Collaborer en temps réel pour la résolution des problèmes urgents
  • …etc

Se baser sur le monitoring pour une première mise en place de DevOps a pour avantage de démontrer l’intérêt de cette approche (applications plus stable, réaction plus efficace aux problèmes de production…etc.) et, donc, de faciliter son adoption pour les autres étapes du cycle de vie applicatif.

Cela-dit, il faut garder à l’esprit que le DevOps n’est pas un objectif en soi, mais une quête vers une amélioration continue de la collaboration des équipes Devs et des Ops.
La façon de mettre en place DevOps varie inévitablement d’une entreprise à une autre, voire même, d’un service à un autre au sein d’une seule et même entreprise. C’est un processus lent qui nécessite beaucoup de patience et une implication sans failles des différents acteurs.

Cependant, une fois sur les rails, DevOps apportera énormément à l’entreprise: des équipes soudées, un environnement de travail sain et des livrables de meilleur qualité, donc, des utilisateurs satisfaits [et il faut malheureusement trop souvent rappeler que c’est ce pourquoi nous travaillons tous].  

Une partie de l’équipe Soft’it présente au Microsoft DevOps Day !

.equipe main .detail div .profil {
width: 22%;
float: left;
margin-right: 2.6%;
margin-bottom: 2.6%;
border: 1px solid #ccc;
position: relative;
background: #ec6707;
font-weight: 400;
}

.equipe main .profil .photo {
width: 100%;
height: auto;
position: relative;
display: block;
z-index: 100;
border-bottom: 5px solid #ec6707;
}

.equipe main .profil .texte {
margin: 0 auto;
top: 0;
height: 100%;
width: 100%;
padding: 8%;
position: absolute;
z-index: 101;
color: #ec6707;
}

.equipe main .profil .texte h3 {
margin-bottom: 35px;
margin-top: 0;
font-family: « Georgia »,arial;
font-weight: normal;
font-size: 1.375em;
cursor: default;
}
.equipe main .profil .texte span {
text-transform: uppercase;
font-size: .75em;
font-weight: bold;
cursor: default;
}

@media screen and (max-width: 800px) {
.equipe main .detail div .profil {
width: 31.6%;
margin-right: 2.6%;
}
}

@media screen and (max-width: 600px) {
.equipe main .detail div .profil:nth-child(odd) {
margin-right: 2.6%;
}

.equipe main .detail div .profil {
width: 40%;
}
}

@media screen and (max-width: 400px) {
.equipe main .detail div .profil {
width: 100%;
margin-right: 2.6%;
}
}

Chez Soft’it, on aime la technique mais surtout la qualité. Un des axes d’amélioration de la qualité les plus pertinents du moment est la réconciliation/le rapprochement entre le développement et l’exploitation (« ops » en anglais) : le DevOps.

Cela permet de penser un développement dans son ensemble : de la réalisation à la livraison.
Le mouvement « DevOps » a pour objectif de casser les silos existants entre ces 2 étapes, tout en se basant sur une approche agile.


Microsoft et Cellenza organise le « Microsoft DevOps Day« , le 25 novembre 2014 au centre de conférence de Microsoft (Issy-les-Moulineaux).

1 journée pour parler du DevOps et ses origines, puis pratiquer de l’IaaC (« Infrastructure as a Code »), Continuous Delivery (déploiement continu) et du Monitoring. Pour finalement terminer sur le rôle et le futur de Microsoft dans le milieu du DevOps.

Evidemment quelques membres de l’équipe Soft’it seront présents.

Ikbal Benakila

Ikbal
Benakila

Laurent Jacques

Laurent
Jacques

Pier-Lionel Sgard

Pier-Lionel
Sgard

Jérôme Veneziani

Jérôme
Veneziani

Si vous ne pouvez pas y assister, l’équipe tweetera demain et fera quelques feedbacks/résumés des confs dans les jours/semaines à venir. Stay tuned !

window.twttr = (function (d, s, id) {
var t, js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.src= « https://platform.twitter.com/widgets.js &raquo;;
fjs.parentNode.insertBefore(js, fjs);
return window.twttr || (t = { _e: [], ready: function (f) { t._e.push(f) } });
}(document, « script », « twitter-wjs »));

Red Gate vs. Giant Octopus (Deploy)

Annoncé au début de ce mois, la société Red Gate – notamment connue pour ses produits d’aide aux DBAs (« SQL Compare » en tête) – a investi pas moins de 2 millions de dollars dans la société Octopus Deploy

Cette dernière édite une solution de déploiement automatique surtout axée .NET.

Qu’est-ce que cela change ?

Déjà, Red Gate retire sa propre solution (Deployment Manager, qui a déjà disparu du site) du marché. Et cela signifie qu’elle va aider ses clients actuels à passer à un nouveau produit … Octopus Deploy évidemment, en envoyant une version gratuitement aux équipes.

[IIS 7+] Compte d’exécution du pool d’application

Le truc bête qu’on ne connait pas toujours: depuis IIS 7 (IIS 7, IIS 8 et IIS 8.5), le compte d’exécution des pools d’application n’est pas le même que sous IIS 6.

En effet, pour chaque pool, un nouveau compte local est disponible, de la forme: « IIS APPPOOL<nom_du_pool> » (attention au 3 « P »)

Exemple:
Pour un pool nommé « MyB »:


Vous pouvez rechercher et obtenir le compte « IIS APPPOOLMyB »:

Donc si vous avez des problèmes de droits d’écriture dans des dossiers par exemple, il faudra penser à ajouter des droits sur ce compte pour le répertoire en question.