Category: DevOps

DevOps – Comment joindre l’ITIL à l’agréable ?

Le chemin vers le DevOps peut être long et sinueux. Nous ferons face à de nombreux obstacles, à la fois culturels et organisationnels.  Une équipe DevOps doit être avant tout Agile et s’adapter en toutes circonstances. L’objectif de cet article et de partager une vision long terme et les étapes qui nous y amènent.

Pourquoi l’ITIL ?

La plupart des grosses structures ont, par définition et d’un point de vue RH, des groupes d’entités « métier » et « techniques ». Les entités métiers ont pour but d’apporter de l’innovation dans le métier de l’entreprise, d’augmenter le chiffre chiffre d’affaire et optimiser les dépenses. Les entités techniques, quant à elles, ont pour objectif d’implémenter, d’héberger et d’assurer le fonctionnement des outils nécessaires aux entités métiers pour exercer leurs fonctions. Les besoins sont multiples : performance, stabilité, sécurité, disponibilité. Afin que l’ensemble de ces critères soit satisfait, des méthodes et process ITIL ont été mis en place dans le but de contrôler et canaliser les changements pour plus de stabilité opérationnelle.

Un peu d’historique

Avant l’avènement des méthodes agiles, la plupart des projets suivaient un cycle de livraison en V. Les principes de cette méthode s’inspirent directement de l’industrie. On commence par recueillir le besoin initial puis définir des Blueprints d’architecture. L’ensemble des besoins est ensuite détaillé à la fois sur les aspects fonctionnels et techniques. Vient ensuite les phases d’implémentation, de test et de déploiement.

Cette méthode couplée à des processus ITIL permet une stabilité opérationnelle optimale. On modifie peu la production et lorsque cela arrive on canalise au maximum le changement via des processus définis. Cette façon de fonctionner a fait ses preuves durant de nombreuses années. Cependant, elle est de plus en plus controversée au bénéfice d’approches plus agiles. En effet, la plupart des équipes de développent travaillent en agile au plus près du métier. Elle délivrent des incréments régulièrement et sont souvent confrontés à la latence des process une fois l’incrément livré. Cela apporte de la frustration à la fois au niveau métier mais aussi au niveau des équipes de développement.

« Individuals and interactions over processes and tools »

Il s’agit du premier concept souligné par l’agile manifesto. Les fondements de l’agile sont la transparence, l’inspection et l’adaptation. Le principe est d’analyser les situations, d’apprendre de ses échecs et d’évoluer de manière empirique dans des environnements complexes. Le chemin vers l’agile et de DevOps peut être long et complexe, voici quelques étapes à franchir en s’inspirant de l’échelle de Tuckman :

Forming – Démarrer du bon pied

Devops est une histoire de personnes et de compétences avant tout. La formation est nécessaire afin que l’ensemble des équipes adoptent l’état d’esprit et la philosophie portée par le DevOps.

Storming – Etre confronté à la réalité

Une fois sur le terrain, les équipes formées feront face aux vraies difficultés. Durant cette phase, les interactions devront se mettre en place et les rôles et responsabilités de chacun en découler.

Norming – Mettre de l’huile dans les rouages

Une fois les process éprouvés, chaque équipe DevOps devra :

  • Mettre en place des processus d’amélioration continue.
  • Mesurer pour mieux améliorer.
  • Adapter et simplifier les process devant l’être.
  • Être pragmatique. Les objectifs communs seront l’augmentation de la réactivité des équipes et la diminution du Lead Time à son minimum.

Performing – en route vers l’excellence

À ce stade, l’équipe tire les fruits des changements opérés dans l’étape Norming. Les processus d’amélioration continue tireront l’équipe DevOps vers l’excellence, à la fois technique et collaborative. L’objectif : Changer son métier pour plus d’innovation et de performance !

Exemples à suivre: Amazon, Netflix, Spotify

En conclusion, DevOps est une histoire de personnes avant tout ! Les process ne doivent pas en bloquer l’adoption. Ils devront être au cœur de la transformation et potentiellement adaptés grâce à l’expérience des équipes. Une vision long terme est déterminante dans le succès d’une transformation Agile et DevOps. Changez votre métier pour le meilleur !

Les 7 points clés de la réussite du DevOps

Beaucoup d’articles parlent de DevOps, des clés du succès de DevOps sur leur projet, dans leur contexte. Voici ma vision des 7 ingrédients principaux qui font pour moi le succès d’une approche DevOps réussie. Cette liste n’est pas exhaustive, le sujet est vaste, d’autres ingrédients pourront être ajoutés suite à vos commentaires

1. Une culture commune

La culture sont la clé de voûte du DevOps. On parle aussi de DevOps comme un mouvement culturel, une philosophie qui vise à rapprocher les Dev des Ops. La culture du DevOps est pour moi la culture d’entreprise, du métier qui induit le professionnalisme des équipes. Une culture similaire facilite les échanges et la communication entre les personnes et ainsi créé une bonne synergie pour accomplir de grands exploits !

2. Une communication ouverte et transparente

La transparence est un des pilier de Scrum et de l’Agile. L’ensemble des membres d’une équipe DevOps doivent communiquer le plus efficacement possible et de manière transparente avec un objectif de partage de connaissance maximale. C’est crucial pour assurer une bonne dynamique du projet. Cela réduit aussi le stress de l’équipe et partage le fardeau de la responsabilité  sur l’ensemble de l’équipe DevOps en réduisant considérablement le risque de syndrome du Héro. « Tout seul on va vite. Ensemble on va plus loin ! »

3. Des outils communs

Tout comme dans la mécanique, il faut avoir de bons outils pour travailler de manière professionnelle ! Les outils améliorent considérablement l’efficacité de l’équipe et réuni par nature les métiers nécessaire à la création d’un logiciel réussi. Ces outils peuvent travailler et doivent s’intégrer en toute ergonomie à l’environnement de travail de l’ensemble des membre de l’équipe DevOps.

La plateforme Visual Studio Team Services est un excellent exemple de plateforme DevOps. Via une interface intuitive, elle centralise l’ensemble des artefacts du projet et permet le suivi du déploiement continu sur les environnements cibles du projet. De plus, cette plateforme est extensible et peut s’élargir au besoin d’autre fonctionnalités à partir d’un market place bien fourni !

4. Partager les victoires et les défaites

Historiquement, les Dev et les Ops ne partagent pas la même culture et exercent des métiers très différents. Les uns cherchent à intégrer le plus de changement et d’innovation possibles dans un produit sur la base des besoins des utilisateurs. Les autres recherchent la stabilité, la sécurité et la performance de l’application en production. Il existe parfois des tensions ou des incompréhensions entre ces deux population qui sont la plupart du temps dues au manque de vision globale du projet. Le DevOps a pour but d’adresser ce problème en fournissant une vision plus large à l’ensemble des membre du projet. Tout comme en agile, les succès sont partagés et toute l’équipe doit être récompensée ou remerciée (c’est un minimum !). Il en est de même pour les défaites. Ensemble, l’équipe DevOps est bien meilleure dans la défaite et pourra en tirer les enseignements pour les futures version du produit !

5. Un budget partagé

C’est sans doute la point le plus difficile à adresser dans les grands groupes où les process des finances sont bien enracinées dans la culture traditionnelle. Il faudra donc s’adapter pour que l’équipe DevOps soit vue comme une équipe à part entière et non comme deux équipes distinctes. En DevOps, par définition, il n’y a pas de phase Projet et de phase de Run à proprement parler. On délivre une première version le plus rapidement en production (Minimum Viable Product) et on la fait évoluer le plus souvent possible avec une équipe polyvalente et compétente. Si possible la taille de l’équipe DevOps doit rester identique sur toute la durée du projet (Consistancy Removes Complexity). D’un point de vue budget, cela correspond un peu à un mode d’abonnement au mois où l’on va garder la même charge. En théorie, c’est plus simple à calculer. C’est un peu comme si l’on payait un forfait mobile avec un iPhone. Cela revient au même coût au final, mais on a pas besoin d’avancer le coût du téléphone à chaque nouvelle mise à jour.

Dans la pratique, c’est un peu plus compliquer à aborder, il faut donc s’adapter aux systèmes de facturation existants… (Inspect and Adapt !)

6. Une méthode commune et appliquée

Dans le cadre d’un projet DevOps, l’application d’un framework Agile doit être très rigoureuse et partagée par l’ensemble de l’équipe. En DevOps, tout le monde parle la même langue, utilise les mêmes outils et communique efficacement. Il est toujours plus facile de jouer à un jeu lorsque les règles sont clairement définies. Un Scrum Master veilleura à l’application de ces règles et à la suppression de tout obstacle (Impediment) empéchant l’évolution de l’équipe DevOps.

Je conseille vivement la mise en place d’un Framework Agile à la fois strict et simple à comprendre tel que Scrum pour que l’ensemble de l’équipe puisse connaitre et maitriser ces règles rapidement dès le début du projet.

7. Des objectifs communs

Cela va sans doute de soi mais lorsque l’on est sur l’autoroute du DevOps, tout le monde doit rouler dans le même sens ! Notre destination doit être commune et notre équipe doit évoluer de concert en visant un objectif commun à court terme et en partageant une vision commune du produit !

J’espère que ces quelques points vous ont permis de mieux comprendre les enjeux et la philosophie du DevOps. Je suis preneur de vos retours d’expérience.

DevOps, Rugged DevOps et DevSecOps ?

DevOps, Rugged DevOps et DevSecOps : depuis quelques temps, nous voyons fleurir sur les réseaux sociaux ces termes qui font le buzz. L’idée de cet article est de comprendre d’où provient cette tendance et les enjeux de la sécurité au cœur de développement logiciel dans les prochaines années.

Le chemin du DevOps

La philosophie de DevOps est de fluidifier au maximum le flux de livraison entre l’idée provenant du métier et l’utilisateur final. Sur ce chemin, nous faisons face à de nombreux obstacles ou freins. Je reviendrai sur ces challenges de manière exhaustive dans un prochain article. Le challenge le plus important est celui de la communication entre les individus ne partageant pas le même métier. Souvent, en gestion de projet, nous prenons l’exemple de la tour de Babel. Un projet colossal de l’antiquité qui n’a jamais vu le jour à cause du manque de compréhension entre les ouvriers qui ne parlaient pas le même langage. C’est un peu la même chose avec le DevOps. La réussite d’un projet dépend du professionnalisme de l’ensemble des personnes impliqués au projet et surtout à leur aptitude à travailler en synergie dans un objectif commun.

Sur un projet informatique, on retrouve souvent le même schéma d’organisation:

Sur toute la durée du projet, on retrouve:

  • Le métier
  • Les analystes fontionnels et les testeurs
  • Les développeurs (Les Devs !)
  • L’équipe en charge des opérations (Les Ops !)

Et ponctuellement, on fait appel à des experts pour :

  • L’exécution de tests spécifiques : Tests de Performance, Penetration Tests
  • La revue et la validation de l’architecture
  • La revue des process de sécurité
  • Etc.

En résumé, sur un projet complexe, beaucoup de personnes sont impliquées dans le dispositif et n’exercent pas le même métier à priori. Cependant, leur objectif et intérêt commun reste le même: « réussir le projet ».

Du Métier au Dev

Depuis plusieurs années, les méthodes et Frameworks Agiles ont permis de rapprocher les métier de l’équipe de développement et ainsi de travailler le manière itérative avec pour priorité principale de satisfaire l’utilisateur final. Ces équipes Agile font souvent face à beaucoup de frustration lors de la mise en production de leur incrément à l’issue de chaque itération. Les contraintes et process existant dans l’organisation n’ont pas été conçus pour absorber le flux de déploiement continu des équipes Agiles en perpétuelle évolution.

Du Dev à l’Ops

Le DevOps est né de ce besoin. L’élargissement des méthodes de travail jusqu’à l’équipe opérationnelle a permis de fluidifier les échange et voir les groupes travaillant sur le même projet comme une seule et unique équipe à part entière. Les processus d’ALM (Application Lifecycle Management) ont évolués aux besoins de l’agilité, ce sont transformés en Continuous Integration puis Continuous Delivery pour déployer de manière automatisée et systématique les incréments livrés par l’équipe de Dev à l’issue de chaque Sprint. La production est rarement l’environnement de destination de l’incrément à l’issue du Sprint. Dans la plupart des cas, cet incrément est déployé sur un environnement d’UAT (User Acceptance Test) ou encore sur la pré-production. A ce stade, il reste encore à obtenir le « Go » de la « Sécu » et cela peut prendre un certain temps suivant les contraintes de sécurité du projet ou de l’organisation…

La Sécu : l’affaire de Tous !

La sécurité est l’affaire de tous. Les aspects de sécurité doivent être pris en compte au cœur du design de l’application, de son développement et de ses opérations. La plupart des failles de sécurité se retrouvent la plupart du temps en production par manque de vigilance dès la conception même de l’application. Si l’on veut conserver la dynamique agile d’un projet DevOps et que l’on a de grosses contraintes de sécurité, il est primordial de considérer la sécurité comme la clé de voûte du projet dans son ensemble.

Tout comme le DevOps, le DevSecOps vise à fluidifier la communication entre les Devs,les Ops et les équipes sécurité grâce à la mise en place de process et d’outils communs.

« Rugged DevOps is about Tools, DevSecOps is about people »

Image result for devsecops

Rugged DevOps est un terme « Buzz » désignant les outils et process permettant de fluidifier le cycle de livraison d’un projet jusqu’en production en prenant en compte les contraintes de sécurité dès l’implémentation du code de l’application. Alors que DevSecOps s’appuie sur les personnes, Rugged DevOps s’appuie sur les outils.

L’idée derrière tout ça est de faciliter le travail des équipes sécurité et des Pen Testers en fournissant un niveau d’information à jour sur la qualité du code produit d’un point de vue sécurité. La prise en compte des aspects sécurité est dès lors pris en compte par l’équipe de developpement lors de l’implémentation du code et les cycle de continuous delivery intègrent potentiellement une validation automatique du code à l’aide de « Quality Gates ». La génération de rapport d’analyse statique de code (SAST) facilitent grandement l’exécution des tests de pénétration et l’approbation de l’autorité de sécurité  de l’organisation pour le déploiement en production.

Conclusion

Le DevSecOps et le Rugged DevOps sont intimement liés. Le DevOps n’étant pas une méthodologie à part entière mais plus un mouvement culturel, il en va de même pour le DevSecOps. L’objectif est de trouver le chemin qui abouti plus de fluidité et d’efficacité  à tous les étages du projet. Un changement de philosophie, une adaptation des processus et la mise en place d’outils performants permettront cette transformation au rythme que se fixera l’équipe DevOps.