François Desrosiers

As the saying goes, it’s not about the destination, it’s about the journey. The same could be said about DevOps and its implementation in an organization. Yes, the result is magic since it aims to deliver daily business value, but the journey is even more interesting. This journey is full of organizational, technological, but especially human discoveries.

Comme dit le dicton ce n'est pas la destination, mais la route qui compte. On pourrait dire la même chose pour DevOps et de son implantation dans une organisation. Oui, le résultat est magique puisqu'il vise à nous faire livrer quotidiennement de la valeur d'affaires, mais le périple l'est d'autant plus. Ce périple est rempli de découvertes organisationnelles, technologies, mais surtout humaines. Dans les dernières années, j’ai beaucoup accompagné d’entreprise qui débutait ou qui avait déjà amorcé leur transition vers l’agilité et la plupart de ces clients, sans le dire explicitement, voulaient mettre en place une pratique, voir, une culture DevOps dans leur organisation. Tandis que d’autres me posaient directement la question : Comment puis-je mettre en place la pratique DevOps ? Dans tous les projets et compagnies, j’ai vu émerger un « pattern » qui est devenu, avec les années, un ordre d’implantation, pour mettre en place une pratique DevOps. Ce n’est certainement pas la seule approche, loin de là, mais c’est celle que j’ai vu fonctionner chez nombreux clients. Voici ce que j’appel le DevOps Cake… En expliquant ce "pattern" dans les dernières semaines, j’ai dessiné ce qui ressemble à un gâteau de mariage, donc voici la raison derrière son nom… Comme un gâteau, chaque étape se repose sur les étapes précédentes pour être solide et donner le meilleur des résultats. Étape 1 – Intégration continue Cette première étape est la fondation, voire la pierre angulaire, de tout ce qui va suivre par la suite. La raison pour lequel c’est la première c’est que généralement, l’implantation de l’agilité commence toujours au niveau d'une ou des équipes de développement et l’intégration continue est souvent la première chose qu’une équipe Scrum va mettre en place. L'intégration continue bouleversera que l’équipe Scrum et épargnera le reste de l’organisation donc fait de cette étape une option stratégique. Durant cette étape, l’équipe sera forcée de concevoir et développer de manière à pouvoir s’intégrer sur une base quotidienne ou sinon complexifiera énormément leur travail et deviendra même un bloquant. Malheureusement, c’est à cette étape que plusieurs organisations resteront bloquées puisque la prochaine étape, la conception par les essais, est la première étape qui amènera des changements à l’extérieur de l’équipe. Étape 2 – Test automatisé / conception par les essais Cette deuxième étape est l’une de mes préférées pour plusieurs raisons. Premièrement, cette étape permet de valider si la conception et le développement suivent de bonnes pratiques agiles. Ensuite, elle permet de valider si l’organisation comprend et croit en l’agilité parce que l’étape précédente ne bousculait que l’équipe de développement tandis que celle-ci va élargir la portée des changements qu’elle apporte et ce à plusieurs niveaux : Cette étape bouleversera la gestion, habituée à une vélocité passée n’incluant pas le développement de tests automatisés, la nouvelle vélocité à la baisse de ou des équipes perturbera leur planification. Les tests d’acceptations automatisés vont bouleverser les gens affaires exemple: le responsable de produit. L’introduction de cette pratique, si l'on veut qu’elle soit un succès, forcera ceuxci à découper leurs récits (stories) d’une manière différente et penser en cas d’utilisation affaire. Ensuite, pour permettre à l’équipe de développement de bien concevoir les tests en amonts, les critères d’acceptations devront être bien définis pour le sprint planning. C’est souvent lors de cette étape que Scrum en prend un coup et que les compromis débuteront pour ne pas bouleverser les façons de faire ou mettre les gens en situation d’inconfort, mais d’apprentissage. C’est pour cette raison que plusieurs organisations restent prises à cette étape ou même arrêtent complètement l’implantation des tests automatisés. En faisant ça, leur perception et compréhension de la pratique des tests automatisés reste teintée du coût en monté de compétence sans jamais bénéficier des résultats positifs de la pratique. Cette étape est l’une de mes préférés parce que c’est souvent lors cette étape que le déclic se produit avec l’équipe de développement. C’est durant cette étape que l’équipe réalise la valeur réelle de l’intégration continue et les avantages d’avoir une bonne batterie de tests automatisés, tant unitaires que d’acceptation. Étape 3 – Intégration des bases de données dans le développement itératif Lorsque l’équipe Scrum a atteint un bon niveau de maturité avec les deux précédentes étapes et ça on peut l'observer quand durant les rétrospectives, l’équipe commence à identifier les bases de données comme étant un bloquant à livrer de la valeur affaires plus rapidement. C’est surtout vrai dans les organisations où la modélisation et les changements dans les bases de données peuvent être faits que par les DBA (administrateur de base de données). Une des raisons pourquoi cette problématique ne ressort pas plus tôt, c’est que les équipes de développement, lors des deux étapes précédentes, sont en montées de compétence ce qui permet au DBA de suivre la cadence des équipes Scrum tout en gardant leur façon de faire traditionnelle. À part l’arrivé des bases de données NoSQL, le monde des bases de données n’a pas beaucoup évolué dans ses façons de faire comparativement au aux autres sphères du développement logiciel, c’est pourquoi cette étape va apporter différents défis pour les DBA : Avec la cadence des sprints, les équipes de développement ne pourront pas toujours prévoir plusieurs semaines voir plusieurs jours d’avance les modifications aux modèles de données. Ce qui fera que les DBA seront surchargés de demandes en début de sprint et cette surcharge deviendra un bloquant pour les équipes de développement. Il est donc essentiel que les équipes de développement soient autonomes à faire des modifications au schéma de la base de données puisque prévoir plusieurs sprints d'avance les changements n'est pas la solution. Une piste de solution, est d'ajouter un élément à la définition de terminer pour qu’un DBA regard les modifications au schéma, un peu comme le code review. Puisque les changements de base de données peuvent être faits par tout membre de l’équipe de développement, ces changements doivent suivre les mêmes règles que le reste du code: être automatisé, versionné et fusionné quotidiennement. Donc, leur demander du jour au lendemain de changer leur façon de faire leur travail et souvent les outils pour être en mesure de suivre la cadence des équipes Scrum peut être insécurisant. Je crois qu’ils ont tout à gagner de faire le changement pour faire pleinement bénéficiers l’organisation de leur connaissance plutôt que d’être responsable de concevoir et d’exécuter des scripts SQL. Cette étape est cruciale pour la prochaine si on veut être en mesure d’automatiser l’ensemble du processus de déploiement pour y inclure les bases de données. Étape 4 – Livraison continue La prochaine étape pour une équipe Scrum et une organisation qui vise à implanter DevOps est l’automatisation des déploiements. Habituellement, cette étape fait son apparition quand l'équipe ou les équipes atteignent un niveau de maturité avec les étapes précédentes et veulent inclurent le déploiement dans leur processus de livraison de valeur ou définition de terminer. Après l'introduction des DBA avec l'étape précédente, ce coup-ci on introduit l'équipe d'infrastructure au sens large. Un peu comme les équipes de DBA, l'équipe d'infrastructure doit changer leur manière de travailler, ce qui implique de donner plus de latitude aux équipes de développement. Ce que je veux dire par là, c'est que les équipes d'infrastructure, les Ops, doivent définir les recettes ou contenant, mais laisser libre aux équipes de développement, les Devs, d'y mettre ce qu'ils veulent. Pour ainsi avoir une infrastructure qui répond à leur besoin et non un "one size fit all" de l'infrastructure qu'on voit typiquement dans les organisations. Cette étape n'est souvent pas un défi technique, mais plus organisationnel, à part la courbe d'apprentissage des outils de déploiement automatisé, puisqu’habituellement comme dans la plupart des organisations, il y a un historique entre les Dev et les Ops. C'est pour cette raison que c’est à cette étape qu'on voit apparaître les dysfonctions qui seront les futurs défis à l'implantation de DevOps dans une organisation. L'équipe d'infrastructure (incluant les gestionnaires) ne doit plus voir les infrastructures comme leurs propriétés, mais plutôt comme un vecteur permettant aux équipes de développement de livrer plus rapidement de la valeur d'affaires. Étant responsable du contenant et non du contenu, il est impératif que les équipes Ops changent leur manière de voir les choses, pour ainsi respecter autant leurs objectifs que ceux de l'équipe de développement. À cette étape, habituellement, l'infrastructure de chacun des paliers (dev. pré-production et production) sera créée manuellement, mais les déploiements seront automatisés. Ce qui amènera, dans certains cas, à des inconsistances au niveau des paliers, mais surtout une pression énorme sur l'équipe Ops qui, par l'approche manuelle, aura du mal à suivre la cadence des équipes Scrum ou Kanban. Malheureusement pour passer à la prochaine étape, un peu comme les DBA, c’est la pression ou le désir d’apprendre et s’améliorer qui fera en sorte que les Ops se dirigeront vers l’automatisation de la création de l’ensemble de l’infrastructure. Étape 5 – "Infrastructure as code" Cette étape est la dernière, et c’est l’étape où la technologie sera la solution pour diminuer la pression sur une équipe, celle des Ops et du même coup accélérer le cycle de livraison des Devs. Comme je disais plus tôt, avant d'arriver à cette étape, il faut que l'organisation ainsi que les Ops perçoivent que les anciennes façons de faire, qui ne sont pas mal en soit, mais mal adaptées pour suivre la cadence qu'apporte l'agilité. Typiquement, lors de cette étape les Devs et les Ops de l'organisation, vont ensemble mettre en place les outils et les techniques pour respecter la mission de chacun qui, comme je l’ai dit dans un autre billet, va à l'opposée de l'une de l'autre. Et c'est seulement qu'après, qu'une pratique DevOps pourra être mise en place dans l’ensemble de l’organisation. Ces outils et méthodes vont permettre aux Ops de produirent des recettes technologiques automatisées, qu'ils rendront disponibles aux équipes de développement. Ainsi, l'infrastructure sera immuable et définis dans son ensemble par les Ops tout en permettant au Devs de les utiliser et d'y déployer les incréments logiciels priorisés selon la valeur affaires. Et après c'est fini ? Les organisations, dans leur aventure vers DevOps ou juste vers l'amélioration de l'implantation de l'agilité, suivent habituellement ce cycle et comme on voit, il y a plusieurs étapes avant d'y arriver. Et chaque fois, c'est quand les personnes deviennent matures avec tout ce que comporte l’étape courante qu’ils seront poussés à passer à la prochaine. C'est pour cette raison que je dis souvent qu'on ne peut pas être agile, c’est plutôt un idéal vers lequel il faut tendre puisqu'il y a toujours quelque chose qu'on peut améliorer, que ça soit nous ou nos façons de faire. J'en ai pas parlé explicitement mais c'est toujours le cadre de travail agile, comme Scrum ou Kanban, qui stimule l'amélioration continue nécessaire à une culture DevOps. Quand on regarde attentivement l'enchaînement des étapes, on peut y déceler 3 éléments fortement liés ensemble soit, le processus agile, les outils et les personnes. Et à la base c'est cette boucle continue qui permet de passer les 5 étapes et du même coup obtenir des gains pour l'ensemble de l'organisation. Quand on atteint la dernière étape ce n'est pas terminé, loin de là ! Le défi est maintenant de diminuer le temps de cycle de l'ensemble de l'organisation. Ce que je veux dire par là, c'est de diminuer le temps entre l'émergence d'une idée ou l’identification d’un nouveau besoin jusqu'à son déploiement en production. Et cela devient possible en inspectant et adaptant de manière continue notre processus de production de valeur avec l’aide d’un cadre de travail agile tel que Scrum ou Kanban. Comme je disais au début de mon billet, l’implantation de DevOps est un périple de découverte, de découverte de dysfonction dans l’ensemble de l’organisation. Ça peut sonner négatif, mais c’est loin de l’être puisque ces dysfonctions ne sont que des opportunités d’apprentissage et d’amélioration pour l’organisation et du même coup pour les personnes impliquées. Ensuite c’est la capacité d’une organisation à s’inspecter et s’adapter qui permet de ne pas rester coincée à une étape et ainsi ne pas atteindre le plein potentiel de l’implantation de DevOps ou même de l'agilité. Dans mon prochain billet je parlerai plus du volet technologique et technique de chacune des étapes, bon voyage !

Pour avoir un aperçu de la perception et compréhension des personnes de quelque chose, il suffit de regarder les réseaux sociaux. Ce message qui provient d’une compagnie cherchant un lead DevOps me fait me poser de grosse question à propos de la perception et compréhension du marché vis-à-vis DevOps. Mais est-ce que DevOps est vraiment une personne ayant ce rôle dans l’organisation ? Mais avant tout, c’est quoi DevOps ? Selon Wikipedia, voici la definition: “A cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while automating the process of software delivery and infrastructure changes “ Essentiellement voici ma compréhension et interprétation de DevOps, C’est une pratique qui a pour objectif d’amener une empathie mutuelle à deux groupes, les Dev et Ops, qui ont des missions et responsabilités qui vont à l’ opposer de l’un de l’autre. Ainsi, l’application de la pratique DevOps va permettre l’atteinte des objectifs propres à chaque groupe tout en respectant les responsabilités de l’autre. Je mentionne deux équipes quand idéalement, il ne devrait en faire qu’une seule, mais malheureusement historiquement et même encore de nos jours ce sont deux groupes distincts qui n’ont pas les mêmes objectifs. L’un a pour objectif de livrer de la valeur affaires le plus rapidement possible tandis que l’autre c'est d’avoir des infrastructures le plus stable possible. Maintenant, pour que ça fonctionne il faut deux choses, premièrement il faut un framework pour structurer le processus de livraison de valeur affaires, par exemple Scrum ou Kanban. L’approche agile choisit, permettra à l’ensemble de l’organisation et les équipes de développement de produire de valeur affaire chaque itération voir chaque jour. Deuxièmement, il est nécessaire d’avoir un ensemble d’outils automatisés permettant aux « Ops » et au « Dev » de suivre la cadence de livraison de valeur d’affaire de l’organisation tout en respectant les objectifs et responsabilités de l’autre groupe. Pour maximiser les chances d’implanter une pratique DevOps dans une organisation, il faut absolument que les deux critères de bases soient présents, un framework pour structurer et guider le flux de production de valeur et une suite d’outils. Si la volonté d’implanter DevOps provient seulement des TI par les outils, l’ensemble de l’organisation ne pourra pas suivre et verra l’initiative comment une dépense sans réelle valeur. Si la volonté vient de l’organisation et du train de livraison agile et que l’équipe TI n’a pas les connaissances et les outils nécessaires, l’implantation de la pratique mettra beaucoup de pression sur l’équipe de développement et n’aura pas les succès attendus. Donc une première étape est de mettre en place un framework pour structurer et guider le flux de production de valeur, par exemple Scrum ou Kanban. Grâce à une bonne application de Scrum ou Kanban, l’organisation sera en mesure de supporter les livraisons fréquentes, voire quotidiennes, du besoin client de sa réalisation jusqu’à sa livraison. Par contre, pour être en mesure de mettre une pratique DevOps, il est nécessaire que le flux de production de valeur ait atteint un certain niveau de maturité dans l’ensemble de l’organisation. Ce que je veux dire par là, c’est qu’habituellement lorsqu’une organisation décide de prendre le virage agile avec Scrum ou Kanban, l’application du framework ne s’en tient qu’à l’équipe de développement. Avec l’augmentation de la maturité de l’équipe avec l’Agilité, l’équipe tant à élargir la portée de l’Agilité en incluant le volet affaires et le volet opérationnel TI. Ce n’est qu’à ce moment que l’organisation pourra plus facilement implanter les principes DevOps dans ses équipes de Dev et Ops à condition qu’ils aient les bons outils, ce qui nous amène au deuxième critère. Les outils sont le critère qui permettra, tant aux équipes de développement (Devs) qu’aux équipes d’infrastructure (Ops), d’atteindre les objectifs de leur groupe tout en permettant à l’autre d’atteindre les leurs. C’est pourquoi il est essentiel que les équipes aient un coffre d’outils contenant l’ensemble des outils permettant d’atteindre ces objectifs. Habituellement, on devra trouver un ou des outils pour chacune de catégories suivantes : Dépôts de contrôle de version Outil d’intégration continue Outils automatisés de test Analyse statique de code Outil de tests automatisés Outil de test de performance Outil de déploiement continue Programmation de l’infrastructure et gestionnaire de configuration Virtualisation et technologies de conteneurisation Si je reviens au début avec le post Linkedin d’une compagnie recherchant un lead DevOps, comme on voit il n’est pas possible qu’une seule personne, voire un groupe, soit responsable de la pratique DevOps. Donc si vous voulez mettre en place une pratique DevOps dans votre organisation, assurez-vous d’avoir en place les deux critères essentiels et surtout responsabiliser l’ensemble de l’organisation plutôt qu’une équipe ou une personne.

To get an insight into people's perception and understanding of something, just look at the social networks. This message coming from a company looking for a lead DevOps makes me ask myself a big question about the perception and understanding of the market about DevOps. But is DevOps really a person with that role in the organization? But first of all, what is DevOps? According to Wikipedia, here is the definition: “A cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while automating the process of software delivery and infrastructure changes “ Essentially, here is my understanding and interpretation of DevOps, It is a practice that aims to bring mutual empathy to two groups, the Dev and Ops, who have goals that go against each other. Thus, the application of the DevOps practice will allow the achievement of the objectives specific to each group while respecting the responsibilities of the other. I mention two teams when ideally, it should only make one, but unfortunately historically and even today these are two distinct groups that do not have the same goals. One is to deliver business value as quickly as possible while the other is to have the most stable infrastructure possible. Now, to make it work it takes two things, firstly there needs to be a framework to structure the business value delivery process, for example Scrum or Kanban. The agile approach chooses, will allow the entire organization and development teams to produce value-worth each iteration even every day. Secondly, it is necessary to have a set of automated tools allowing the Ops and the Dev to follow the delivery rate of business value of the organization while respecting the objectives and responsibilities of each group. To maximize the chances of implementing a DevOps practice within an organization, it is imperative that the two basic criteria are present, a framework to structure the business value delivery process and a suite of tools. If the willingness to implement DevOps comes only from IT through tools, the entire organization will not be able to follow and see the initiative like an expense without real value. If the will comes from the organization and the agile delivery train and the IT team does not have the necessary knowledge and tools, implementation of the practice will put a lot of pressure on the organization, it will not have the expected successes. So a first step is to set up a framework for structuring and guiding the value workflow, for example Scrum or Kanban. With a good application of Scrum or Kanban, the organization will be able to support the frequent or even daily deliveries of the customer's need from its realization to its delivery. On the other hand, to be able to implement a DevOps practice, it is necessary that the business value delivery process has reached a certain level of maturity throughout the organization. What I mean by that is that usually when an organization decides to take the agile turn with Scrum or Kanban, the application of the framework only sticks to the development team. With the team's growing maturity with Agility, the team expand the reach of Agility by including business side and IT operational. This is when the organization can more easily implement DevOps practices in its Dev and Ops teams. On the other hand, it’s possible only if they have the right tools, which leads to the second criterion. This is why it is essential that teams have a toolbox containing all the tools to achieve these objectives. Usually, one or more tools will need to be found for each of the following categories: Version control and artifact repositories Continuous Integration/Continuous Delivery Quality check Automated testing tools including static code analysis checkers automated test frameworks performance testing tools Automated release/deployment tools Infrastructure as Code: software-defined configuration management. Virtualization and containerization technologies If I go back to the beginning with the Linkedin's post of a company looking for a lead DevOps, as we see it is not possible that only one person, or even a group, is responsible for the DevOps practice. So if you want to set up a practical DevOps in your organization, make sure you have both essential criteria in place and especially empower the entire organization rather than a team or person.

Comme on l'a vu durant la présentation, l'Agilité a des impacts à tous les niveaux et touche même les bases de données. Pour être capable de travailler efficacement dans un contexte Agile, le DBA doit ajuster sa manière de travailler autant en conception, que durant la réalisation ainsi qu'au moment de déployer l'application. Dans les prochaines semaines, j'écrirai une série d'articles détaillant les différentes pratiques que j'ai présentées lors de ma conférence l'Agile Tour de Québec. Comme premier billet, je parlerai de lecture plus que pertinente avant de rentrer dans le vif. Malheureusement, il n'y a pas qu'un livre qui parcourt l'ensemble du sujet mais plutôt plusieurs qui, chacun à leur manière, contribuent au large éventail de connaissances et d'outils qu'un DBA doit posséder. La conception de l'architecture de vision UML 2 et les design patterns La conception est une partie essentielle de tout projet Agile si on veut être en mesure de définir l'architecture de vision qui sera à l'image du domaine d'affaire et de ses besoins. Dans ce livre, Craig Larman, au travers d'une étude cas, nous transmet étape par étape différentes pratiques et outils de conception Agile où le domaine d'affaires est au centre des préoccupations. Ce livre très utile pour supporter la conception de données Agile est un incontournable pour tout architecte voulant débuter un projet Agile. Conception et modélisation de données Agile Agile Database Techniques Comme je parlais en introduction de la conférence, peu d'auteurs se sont aventurés à parler des bases de données dans un contexte Agile. Ce livre entrecroise celui de Craig Larman qui couvre le cycle de conception et développement tandis que celui-ci ne porte que sur la modélisation Agile des données. Ce livre est un coffre d'outils de concepts essentiels pour, oui les DBA, mais tout développeur ou architecte travaillant avec les bases de données relationnelles. Intégration continue et déploiement Team Foundation Server 2013 Excellent livre à propos de Team Foundation Server qui est l'outil de gestion du cycle de développement de Microsoft qui comporte de nombreuses fonctionnalités dont l'intégration continue. Si c'est l'outil sélectionné de votre organisation pour gérer l'intégration de vos équipes, ce livre est essentiel pour tirer au maximum des capacités du logiciel. Gestion de la persistance Entity Framework Code First L'uilisation d'un ORM (Object Relational Mapping) est incontournable si on veut être en mesure de rapidement appliquer les évolutions rapides du domaine de votre système. L'ORM présenté dans ce livre est celui de Microsoft qui en est un parmi d'autres. Ce livre couvrira les bases pour mettre en place une solide couche d'accès aux données pouvant supporter différents types d'architectures. Sur ce bonne lecture et on se voit lors du prochain billet qui parlera de comment définir l'architecture de vision et les stratégies pour bien définir les sous-domaines d'informations qui la compose. Pour qu’à même titre que l’architecture, que la base de données devrait être à l’image du domaine d’affaire.

Recently discussing design and programming with an external programmer, he explained me his approach of defensive programming. But before going in detail of his explanations, Wikipedia help us to define the defensive programming: Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. The idea can be viewed as reducing or eliminating the prospect of Finagle's law having effect. Defensive programming techniques are used especially when a piece of software could be misused. We understand that it is one "mind set" which is excellent, because it allows us to deliver less fragile code. Furthermore, this way of seeing things is in direct link with the creation of unit test (the TDD or TLD (Test Last Development) but I will not go into this debate here? J). Here is an illustration of its vision (of the developer) The developer explained me that it is essential to put of the management of exception in Service123 but also in all the functions of all the classes of the utilitaire assembly. Also, that it was imperative to put some validation of parameters everywhere, but also in the classes marked as internal, thus not visible and usable from everything outside of the assembly which contains them. It is at this moment that I said to myself: "Can the defensive programming in its limits can quickly become of the paranoiac programming?" I give some explanation, the try catch and the validations have impacts at several levels among which on the performance and the code’s readability to name only these. I, above all I try to identify the entry points of my components which can bring irregularities in the functioning of my system. Also, I try to identify the places where I have a dependence towards contexts outside my application (Web service, database, physical file) because these dependences can weaken my component or class. The rest I trust my unit tests to validate my non-regression and the smooth running of the features of my classes. Thus if we return to our example, the entry points of this micro-system are ProduireDoc of Service123 and CreerPatente of the ComponentA class. These two places should validate their parameters. Since, Service123 depends on ComposanteA thus, then Service123 should manage exception for various reasons (masking interne exception, management client’s experience, logging, etc.). Then, the function FaitXYZ of ComposanteB should not make validations on what the component ComposanteA passed as parameters but only the validations of the logic that it takes care and it’s the same thing for the exceptions, it should be captured by the entry point CreerPatente of ComposanteA. And you, how do you manage your programming, are you more a defensive or paranoiac type?