Devops pour les managers SI

Share

Devops

Qu’est-ce que devops ?

Le mot DevOps est une combinaison de deux mots anglais « dev » qui est utilisé pour désigner les « Dev engineers » qui ont pour mission de faire évoluer le système d’information et les « ops » ou « Ops engineers » qui exploitent et maintiennent les applications au sein d’une organisation. Il a pour but d’améliorer la collaboration entre ces deux entités afin de produire des valeurs pour l’entreprise tout en augmentant simultanément la fiabilité, la stabilité, la résilience et la sécurité de l’environnement de production. Cela est possible par la réduction du temps de la mise sur le marché d’un nouveau produit. Historiquement, le début du mouvement DevOps a commencé aux alentours de l’année 2009 avec l’avènement des autres mouvements tels que « l’infrastructure as code » par Mark Burgess et Luke Kanies, l’ « Agile Infrastructure » d’Andrew Shafer, « l’administration du système Agile » de Patrick Debois et tant d’autres.

DevOps n’est pas un outil, c’est une méthodologie et culture issue du principe Agile.

illustration-devops

Figure: Illustration de DevOps

La méthode Agile

Généralités sur la méthode Agile

Comme DevOps a été conçu à partir de la méthodologie Agile, il est préférable de connaitre cette méthodologie.

Les méthodes agiles sont des ensembles de pratiques de projets de développement en informatique qui peuvent  s’étendre et appliquer à d’autres types de projet. Les méthodes agiles sont des ensembles de pratiques de projets de développement en informatique qui peuvent  s’étendre et appliquer à d’autres types de projets. Ces méthodes sont réputées pour être pragmatique par rapport aux méthodes traditionnelles. Leur philosophie est la satisfaction réelle du client. En effet, elles impliquent au maximum le client et permettent une grande réactivité à ses demandes. Ces méthodes sont axées sur une structure commune, une structure  qui est à la fois itérative, incrémentale et adaptative. Maintenant, nous allons voir les deux méthodes agiles les plus utilisées qui sont la méthode Scrum et la méthode XP Extreme programming.

La méthode Scrum

Scrum est la méthode agile qui a la plus de popularité. C’est un schéma d’organisation de développement de produits complexes. Le principe de cette méthode est le découpage d’un projet en boite de temps ou « sprints ». La durée de sprints varie entre quelques heures et un mois (la durée normale est de deux semaines). Une estimation est faite au début de chaque sprint puis après on réalise une planification opérationnelle. Pour clôturer un sprint, on réalise toujours une démonstration de ce qui a été achevé. A chaque démarrage d’un nouveau sprint, l’équipe réalise une rétrospective. Par contre, aucune technique d’ingénierie du logiciel n’est couverte par scrum. Dans le cas d’un développement de logiciel, il est nécessaire de l’utiliser avec des pratiques de qualité logiciel. L’un des objectifs de cette méthode est l’amélioration de la productivité.

scrum

Figure : La méthode scrum

La méthode XP Extreme programming

L’extreme programming (XP) est une méthode agile utilisée plus particulièrement en génie logiciel. Elle combine la gestion de projet et la réalisation d’une application. L’extreme programming est faite pour des équipes réduites avec des besoins dynamiques. Ci-après les principes de la méthode XP:

  • Une revue de code sera faite en permanence par un binôme, c’est une bonne pratique
  • Puisque les tests sont utiles, avant chaque mise en œuvre, on fait des tests systématiques
  • Vu l’importance de la conception, elle sera faite tout au long du projet (refactoring)
  • Il faut toujours choisir la solution la plus simple, car la simplicité permet d’avancer plus vite
  • On définit et faire évoluer ensemble des métaphores puisque la compréhension est importante
  • Puisque l’intégration des modifications est cruciale, on l’effectue plusieurs fois par jour
  • Puisque les besoins évoluent vite, on fait des cycles de développement très rapides pour s’adapter au changement

L’extreme programming est axé sur des cycles rapides de développement. Nous allons voir ci-après les étapes de ces cycles :

  • On détermine et fournit les scénarios « client » pendant la phase d’exploration
  • L’équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels
  • Chaque développeur s’attribue des tâches et les réalise avec un binôme
  • Une fois tous les tests fonctionnels effectués, on livre le produit

Extreme-programming

Figure : La méthode Extreme programming

Quelle est la différence entre Agile et DevOps ?

Nous avons vu qu’Agile est une méthodologie de travail qui permet de fournir un produit de façon incrémentale. En effet, elle permet des caractéristiques potentiellement livrables à la fin de chaque sprint (généralement toutes les deux semaines). Face à ces taux élevés de déploiement, l’équipe des opérations est très sollicitée et n’arrive plus à suivre la cadence. Clyde Logue, fondateur de StreamStep, a dit: «Agile a joué un rôle dans le développement et la  reconquête de la confiance dans l’entreprise, mais il a involontairement laissé derrière l’IT Operations ».

Par contre, DevOps est un moyen pour l’entreprise de cerner l’ensemble de l’organisation informatique. DevOps est particulièrement complémentaire au processus de développement logiciel Agile. En effet, il étend et complète le processus d’intégration et de livraison continue en veillant à ce que le code soit prêt pour la production et fournisse de la valeur au client. En somme, par rapport à Agile, DevOps permet d’avoir beaucoup plus de flux continue dans les opérations informatiques.

Les trois processus  DevOps

Nous allons voir les 3 principaux piliers du DevOps à savoir : l’intégration continue, la livraison continue et le déploiement continue.

L’intégration continue

L’intégration continue est l’un des trois piliers de DevOps. Il consiste à compiler, tester et déployer continuellement sur un environnement d’intégration. L’objectif est de détecter les bugs le plus tôt possible. Pour ce faire, on doit réaliser des tests autant que possible sur les non-régressions du livrable. Ces tests sont réalisés par des outils de tests. Cette méthode permet de simplifier le déploiement sur la plateforme d’intégration. Par conséquent, ce déploiement peut être fait directement par l’équipe du développement sans passer par l’équipe opérationnelle.

L’intégration continue comprend un serveur centralisé. Ce serveur peut être du Jenkins, Bamboo ou autre, il permet d’assurer le jeu des tests unitaires, la compilation des codes, le packaging, le déploiement ou encore l’exécution des tests dans un environnement d’intégration.

intégration-continue

Figure: Principe de l’intégration continue

La livraison continue

La livraison continue est la méthode de développement où on compile, teste et livre une application à chaque étape de son cycle de vie. Cette approche permet de faire de la construction, des tests et de diffusion des logiciels plus rapidement et plus fréquemment. De ce fait, le coût, le risque ainsi que le temps pour fournir les changements sont réduits.

L’objectif de livraison en continu est de livrer le plus tôt que possible les nouvelles fonctionnalités que les développeurs créent, aux clients et aux utilisateurs. Le principe est de ne pas envoyer à l’équipe assurance qualité tous les versions qui sortent du processus d’intégration continue, seules celles qui ont des fonctionnalités qui ont besoin d’être tester sont envoyées chez eux. La livraison est enclenchée quand l’équipe de contrôle qualité approuve que la version soit stable et répondent aux fonctionnalités voulues. Certaines organisations ont pris cette notion de livraison continue à l’extrême. En effet, ils livrent de façon régulière chaque mise à jour faite par les développeurs, voir même plusieurs mis à jour par jour. Bien que cela fonctionne très bien pour un site web, ce n’est pas très pratique pour les logiciels critiques utilisés par des entreprises.

livraison-continue

Figure : Principe de livraison continue

Le déploiement continu

Le déploiement continu est un procédé de production. En effet, la phase de compilation, de test, et de déploiement de l’application sont tous réalisés en production. Ce processus nécessite que le processus d’intégration continue et de livraison continue aient été fait avec succès. Le déploiement est réalisé de façon automatique. Après le déploiement, il doit être possible de faire la mesure des impacts. En cas de problème, un processus automatisé de retour arrière ou rollback peut être lancé.

déploiement-continu

Figure  : Principe de déploiement continu

Interaction entre DevOps et ITIL

ITIL ou Information Technology Infrastructure Library (Bibliothèque pour l’infrastructure des technologies de l’information) est un ensemble de 5 ouvrages qui traitent les bonnes pratiques en matière de gestion de système d’information. En résumé, ces 5 ouvrages abordent les topiques suivantes :

  • Organisation d’un système d’information
  • Amélioration de l’efficacité d’un système d’information
  • Réduction des risques
  • Augmentation de la qualité des services informatiques

La dernière version d’ITIL est la version 3. Cette dernière version met l’accent sur la maitrise du cycle de vie des services. Nous allons voir ci-après les cinq livres principaux qui constituent la version 3 d’ITIL.

  • La stratégie des services (Service Strategy) qui est composée de : le management stratégique, la gestion du portefeuille des services, la gestion financières, la gestion de la demande et les gestions des relations business.
  • La conception des services (Service Design) qui traite : la conception et la Coordination, la gestion des catalogues de service, la gestion des niveaux de service, la gestion de la disponibilité, la gestion de la capacité, la gestion de la continuité, la gestion de la sécurité de l’information et la gestion des fournisseurs.
  • La transition des services (Service transitions) qui englobe : la planification et support à la transition, la gestion des changements, la gestion des actifs et des configurations, la gestion des mises en production et déploiements, la validation et tests, l’évaluation et la gestion des connaissances.
  • L’exploitation des services (Service Operations) qui parle de : la gestion des événements, la gestion des incidents, l’exécution des requêtes, la gestion des problèmes, la gestion des accès.
  • L’amélioration continue des services (Continual Service Improvement) qui a pour rôle : de surveiller l’alignement des services par rapport aux besoins du business, surveiller l’évolution de la demande du business et la mise en œuvre des plans d’amélioration des services.

Intégrer DevOps dans ITIL

Objectif de l’intégration

Pour rester compétitif, les organisations, quelle que soit leurs tailles, doivent réduire au minimum les risques d’interruption de service lors de déploiement d’une nouvelle fonctionnalité ou de mise à jour. Comme nous avons vu, ITIL v3 fournit tous les indicateurs sur le processus et les fonctions nécessaires pour offrir des services informatiques de qualité alignés avec les objectifs et les buts commerciaux. L’objectif de l’intégration de DevOps dans ITIL est la réduction du temps de la mise sur le marché ou « Time-to-Market » d’un nouveau produit. En effet, les différences de culture entre les équipes de développement et les équipes d’exploitation, ainsi que le fonctionnement de la gestion de projet entrainent une augmentation de délais de la mise en œuvre d’un produit au sein d’un fournisseur de services informatiques.

Base de données de la gestion de configuration

ITIL propose beaucoup de pratiques, l’une d’entre elles est la mise en place de la base de données de gestion de configuration (Configuration Management DataBase ou CMDB en anglais). Cette base de données de gestion de configuration est utilisée pour la vérification des versions des composants de code sur le serveur de production et pour la détection des modifications non autorisées.

Le Système de gestion de configuration (Configuration Management System ou CMS en anglais) est un composant indispensable de tout système de gestion du changement. Si on met en place ces pratiques, votre organisation peut bénéficier les avantages de l’agilité. Vous pouvez également gérer et réduire les risques liés aux mises à jour de tout système complexe. ITIL suggère de faire de suivi sur les changements au niveau des éléments de configuration et leurs interfaces, par contre, il ne donne pas d’instructions précises sur la façon de suivre les changements au niveau technique. C’est la raison pour laquelle il est intéressant d’intégrer la méthodologie DevOps dans la mise en place d’ITIL, car elle explique comment suivre les changements pendant la phase build, package et déploiement de l’application. En somme, les pratiques de DevOPs aident à maintenir la mise à jour et l’exactitude de l’information dans le CMS et CMDB.

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Posted in Agilité d'entreprise and tagged , , .

One Comment

  1. Pingback: Devops pour les managers SI  | Transformat...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *