DevOps pour les Nuls

pour résoudre les problèmes métier. L'intention peut être de résoudre des problèmes métier internes (tels que créer un système de gestion de la relation client plus performant) ou d'aider leurs clients ou utilisateurs finals (en fournissant une nouvelle application mobile).

Cependant, de nombreuses organisations ne mènent pas à bien leurs projets logiciels, et leurs échecs sont généralement liés aux défis inhérents au développement et à la livraison des logiciels. Bien que la majorité des entreprises aient conscience que le développement et la livraison des logiciels sont des activités essentielles, une étude récente d'IBM dans le secteur indique que seulement 25 % d'entre elles ont le sentiment que leurs équipes sont efficaces. Ces échecs dans la réalisation se traduisent par des pertes d'opportunités commerciales.

Ces difficultés sont amplifiées par une évolution majeure des types d'applications que les entreprises doivent fournir, des systèmes d'enregistrement aux systèmes d'engagement.

• Systèmes d'enregistrement : les applications logicielles traditionnelles sont de grands systèmes qui fonctionnent comme des systèmes d'enregistrement contenant d'énormes volumes de données et/ou de transactions, et qui sont conçus pour être très fiables et stables. Comme ces applications n'ont pas besoin d'être modifiées fréquemment, les entreprises peuvent satisfaire leurs clients ou leurs propres besoins métier en fournissant une ou deux nouvelles versions majeures chaque année.
• Systèmes d'engagement : avec l'avènement des communications mobiles et l'évolution des applications Web, les systèmes d'enregistrement sont complétés par des systèmes d'engagement auxquels les clients peuvent accéder directement et utiliser pour interagir avec l'entreprise. Ces applications doivent être simples à utiliser, très performantes et pouvoir être modifiées rapidement pour répondre à l'évolution des besoins des clients et des contraintes du marché.

Comme les systèmes d'engagement sont utilisés directement par les clients, l'expérience utilisateur, la rapidité de livraison et l'agilité revêtent une importance extrême. En d'autres termes, ils nécessitent d'adopter une approche DevOps.

Les systèmes d'engagement ne sont pas des systèmes isolés et ils sont souvent liés à des systèmes d'enregistrement. Par conséquent, lorsque les systèmes d'engagement changent, les systèmes d'enregistrement doivent changer aussi. En fait, tout système nécessitant une mise à disposition rapide des innovations requiert DevOps. Ces innovations sont issues principalement des technologies émergentes, telles que le cloud computing, les applications mobiles, le Big Data et les réseaux sociaux, qui peuvent concerner tous les types de systèmes. Nous aborderons ces technologies émergentes à la lumière de DevOps dans les chapitres 4 et 5.

DevOps applique les principes Agile et Lean à l'ensemble de la chaîne logistique logicielle. Il permet à une entreprise d'optimiser la rapidité de livraison d'un produit ou d'un service, de l'idée initiale à la version en production, aux retours client et aux améliorations apportées en réponse à ces retours.

Comme DevOps améliore la manière dont une entreprise apporte de la valeur à ses clients, fournisseurs et partenaires, il constitue un processus métier essentiel, et non une simple fonctionnalité informatique.

DevOps génère un retour sur investissement significatif dans trois domaines :

• amélioration de l'expérience client ;
• accroissement de la capacité à innover ;
• accélération du retour sur investissement.

Les sections suivantes portent sur ces trois domaines.

II-B-1. Amélioration de l'expérience client▲

II-B-2. Accroissement de la capacité à innover▲

II-B-3. Accélération de la production de valeur▲

Le mouvement DevOps a produit divers principes qui ont évolué dans le temps et qui continuent d'évoluer. Des fournisseurs de solutions, notamment IBM, ont développé leurs propres variantes de DevOps. Cependant, tous ces principes adoptent une approche holistique de DevOps, et les organisations de toutes tailles peuvent les adopter. Ces principes sont les suivants :

• développement et test sur des systèmes similaires à ceux de la production ;
• déploiement avec des processus réutilisables et fiables ;
• surveillance et validation de la qualité opérationnelle ;
• amplification des boucles de retour.

Ces principes sont expliqués plus en détail dans les sections suivantes.

II-C-1. Développement et test sur des systèmes de type « production »▲

Ce principe provient du concept shift left,de DevOps dans lequel les problèmes de la production sont traités en amont dans le cycle de vie de distribution de logiciel jusqu'au développement (voir l'illustration 1-1).

L'objectif vise à permettre aux équipes de développement et d'assurance qualité (QA) de développer et de tester l'application par rapport à des systèmes qui se comportent comme des systèmes de production afin de déterminer le comportement et les performances de l'application avant son déploiement.

La première exécution de l'application sur un système de type production doit intervenir le plus tôt possible dans le cycle de vie pour résoudre deux problèmes potentiels majeurs. Cela permet d'une part de tester l'application dans un environnement similaire à l'environnement de production réel où l'application sera déployée, et d'autre part de tester et de valider les processus de mise en production eux-mêmes en amont.

Du point de vue du développement, également, ce principe est très efficace. Il permet à l'équipe des opérations de déterminer en amont dans le cycle la manière dont se comportera son environnent lors de la prise en charge de l'application, et de créer un environnement d'application optimisé.

II-C-2. Déploiement de processus réutilisables et fiables▲

II-C-3. Surveillance et validation de la qualité opérationnelle▲

II-C-4. Amplification des boucles de retour▲

Une architecture de référence fournit un modèle d'une solution éprouvée en utilisant un ensemble de méthodes et fonctionnalités préférées. L'architecture de référence DevOps traitée dans ce chapitre, aide les utilisateurs à accéder et utiliser les instructions, les directives et d'autres documents nécessaires afin de structurer et concevoir une plateforme DevOps qui s'adapte aux personnes, processus et technologies (voir le chapitre 3).

Une architecture de référence peut fournir des fonctionnalités via divers composants. Chacune de ces fonctionnalités peut être couverte par un seul composant ou un groupe de composants fonctionnant conjointement. Par conséquent, vous pouvez voir l'architecture de référence DevOps, représentée dans l'illustration 2-1, du point de vue des principales fonctionnalités qu'elle est supposée fournir. Au fur et à mesure que l'architecture définie se concrétise, ces fonctionnalités seront supportées par un groupe de personnes compétentes, de pratiques définies et d'outils d'automatisation.

L'architecture de référence DevOps de l'illustration 2-1 propose les quatre groupes de chemins d'adoption suivants :

• Pilotage ;
• Développement/test ;
• Déploiement ;
• Opération.

Les sections suivantes du chapitre examinent en détail ces chemins d'adoption.

Ce chemin d'adoption est constitué d'une seule pratique axée sur la définition des objectifs métier et leur ajustement en fonction des retours des clients : planification métier continue.

Aujourd'hui, les entreprises doivent être agiles et pouvoir réagir rapidement aux retours des clients. La réalisation de cet objectif repose sur la capacité d'une organisation à faire les choses de manière juste et appropriée. Malheureusement, les approches traditionnelles en matière de livraison de logiciels sont trop lentes par rapport à la vitesse actuelle du monde des affaires, en partie parce que ces approches dépendent de processus de développement personnalisés et manuels, et que les équipes travaillent de manière isolée en silos. Les informations requises pour planifier et replanifier rapidement, tout en optimisant la capacité de fournir de la valeur, sont généralement fragmentées et incohérentes. Souvent, le retour d'utilisation pertinent n'est pas reçu suffisamment en amont pour atteindre le niveau de qualité approprié et la véritable valeur à fournir.

En outre, les équipes éprouvent des difficultés à prendre en compte les retours susceptibles de prioriser les investissements et du coup à collaborer en tant qu'organisation capable de gérer correctement l'exécution d'un modèle de livraison continue. Certaines équipes considèrent la planification comme une tâche de gouvernance intrusive qui les ralentit, et non pas comme une activité qui leur permet de fournir de la valeur rapidement.

Une capacité à délivrer le logiciel plus rapidement rend l'entreprise plus agile, mais il faut également gérer la vitesse avec l'assurance que ce qui sera délivré correspondra à ce qui était attendu. Vous ne pouvez distribuer rapidement des logiciels si vous ne croyez pas en la justesse de vos objectifs métier, vos mesures de suivi et d'analyse et votre infrastructure.

DevOps permet de rapprocher ces perspectives antagonistes en aidant les équipes à définir ensemble les objectifs métier et à les modifier en continu en fonction des retours de manière à améliorer à la fois l'agilité et les résultats d'entreprise. En parallèle, les entreprises doivent gérer les coûts. En identifiant et éliminant les gaspillages dans le processus de développement, les équipes deviennent plus efficaces, mais améliorent également les problèmes de coût. Cette approche permet aux équipes d'établir un équilibre optimal entre tous ces points, dans toutes les phases du cycle de vie DevOps vers un modèle de distribution continue.

Ce chemin d'adoption met en œuvre deux pratiques : le développement collaboratif et les tests continus. Comme tel, il forme le cœur des fonctionnalités de développement et d'assurance qualité (QA).

III-C-1. Développement collaboratif▲

La distribution des logiciels dans une entreprise implique un grand nombre d'équipes multifonctionnelles, des analystes métier, des architectes d'entreprise et logiciels, des développeurs, des spécialistes Assurance-Qualité, des responsables des opérations, des experts en sécurité, des fournisseurs et des partenaires. Les utilisateurs de ces équipes travaillent sur différentes plateformes et peuvent être répartis entre plusieurs sites. Le développement collaboratif leur permet de collaborer en fournissant un ensemble commun de pratiques et une plateforme commune qu'ils peuvent utiliser pour créer et délivrer les logiciels.

L'une des principales fonctionnalités dans le développement collaboratif est l'intégration continue (voir l'illustration 2-2), une pratique dans laquelle les développeurs de logiciels intègrent en continu ou fréquemment leur travail à celui des autres membres de l'équipe de développement.

L'intégration continue a été vulgarisée par la mouvance Agile. Le concept consiste pour les développeurs à intégrer leur travail à celui des autres développeurs de leur équipe, puis à tester le travail intégré. Dans le cas des systèmes complexes constitués de plusieurs systèmes ou services, les développeurs intègrent également régulièrement leur travail à d'autres systèmes et services. L'intégration régulière du travail produit permet d'identifier et de révéler en amont les risques d'intégration. Dans les systèmes complexes, elle dévoile les risques connus et inconnus — à la fois techniques et relatifs à la planification.

III-C-2. Tests continus▲

Le chemin d'adoption Déploiement constitue la source des principales fonctionnalités de DevOps. La livraison et le déploiement continus font passer le concept d'intégration continue à l'étape suivante. La pratique qui permet la livraison et le déploiement permet également de créer un pipeline de distribution (voir le chapitre 3). Ce pipeline facilite le déploiement continu des logiciels vers les environnements d'assurance qualité, puis vers la production de manière automatisée et efficace. L'objectif de la livraison et du déploiement continus vise à fournir aux clients et aux utilisateurs les nouvelles fonctionnalités dès que possible.

La plupart des outils et des processus qui constituent le cœur de la technologie DevOps existent pour faciliter l'intégration, la livraison et le déploiement en continu. Ces points sont abordés en détail dans les chapitres suivants.

Le chemin d'adoption des opérations inclut deux pratiques qui permettent aux entreprises de surveiller le fonctionnement des applications mises en production et d'avoir des retours clients. Ces données permettent aux entreprises d'interagir avec agilité et de changer leurs plans métier, si nécessaire.

III-E-1. Surveillance continue▲

III-E-2. Retours continus des clients et optimisation▲

Cette section explique comment démarrer avec DevOps, notamment créer la culture appropriée, identifier les défis économiques et déterminer les goulots d'étranglement à éliminer.

IV-A-1. Identification des objectifs métier▲

IV-A-2. Identification des goulots d'étranglement dans le pipeline de distribution▲

Cette section porte sur l'aspect humain de l'adoption de DevOps et la création de la culture nécessaire.

IV-B-1. La culture DevOps▲

IV-B-2. L'équipe DevOps▲

Dans la section précédente, nous avons vu le rôle des individus et de la culture dans l'adoption de DevOps. Les processus définissent ce que font ces personnes. Votre organisation peut avoir instauré une culture efficace de collaboration, mais si les individus font ce qu'elles font, les bonnes et les mauvaises choses, mais de la mauvaise manière, il existe une probabilité d'échec.

Un grand nombre de processus sont identifiés avec DevOps — ils sont trop nombreux pour être couverts dans ce manuel. Cette section porte sur les principaux processus à la lumière de leur adoption dans l'entreprise.

IV-C-1. DevOps comme processus métier▲

IV-C-2. Processus de gestion des changements▲

IV-C-3. Techniques DevOps▲

Les technologies permettent aux individus de se concentrer sur le travail de création à forte valeur ajoutée tout en déléguant les tâches routinières à l'automatisation. Elles donnent également la possibilité aux équipes d'ajuster et d'optimiser le temps et leurs capacités.

Si une organisation crée et gère plusieurs applications, tout ce qu'elle fait doit pouvoir être répété de manière fiable pour garantir la qualité dans chacune des applications. Il ne faut pas tout recommencer depuis le début à chaque nouvelle sortie de version ou correction d'erreur des applications. Elle doit réutiliser les actifs, le code et les pratiques pour réduire les coûts et être efficace.

La standardisation de l'automatisation rend également les individus plus efficaces (voir « Les individus dans DevOps » dans les pages précédentes de ce chapitre). Les organisations peuvent être confrontées au remplacement des employés, des sous-traitants ou des fournisseurs de ressources ; les personnes peuvent changer de projet. Par contre, un ensemble d'outils communs permettra aux utilisateurs de travailler sur n'importe quel projet, et de nouveaux membres d‘équipes n'auront à apprendre à maîtriser qu'un seul ensemble d'outils — un processus efficace, économique, réutilisable et évolutif.

IV-D-1. Infrastructure programmable▲

IV-D-2. Pipeline de distribution▲

Un pipeline de distribution est constitué des étapes par lesquelles passe une application, du développement à la production. L'illustration 3-1 montre un ensemble d'étapes types. Ces étapes peuvent varier en fonction de l'organisation, mais également de l'application, selon les besoins, le processus de distribution du logiciel et la maturité de l'entreprise. Le niveau d'automatisation peut également varier : certaines organisations automatisent complètement leurs pipelines de distribution. D'autres soumettent leur logiciel à des vérifications et étapes manuelles du fait d'exigences réglementaires ou propres à la société. Il n'est pas nécessaire de traiter toutes les étapes immédiatement. Commencez par traiter les parties critiques de l'organisation — pas tout d'un coup — puis incluez progressivement chacune des étapes.

Un pipeline de distribution type comporte les étapes décrites dans les sections suivantes.

IV-D-2-a. Environnement de développement▲

Le développement d'une application se déroule dans un environnement de développement qui fournit des outils permettant aux développeurs d'écrire et de tester le code. Mis à part les outils IDE (Integrated Development Environment) que les développeurs utilisent pour écrire le code, cette étape inclut des outils qui permettent le développement collaboratif, tels que des outils de gestion de configuration logicielle, de gestion des éléments de travail, de collaboration, de test unitaires et de planification de projet. Les outils dans cette étape sont généralement des outils multiplateformes et multitechnologies basés sur le type de développement à réaliser.

IV-D-2-b. Étape de génération▲

L'étape de génération est l'étape au cours de laquelle le code est compilé pour créer et tester les fichiers binaires à déployer. Plusieurs outils de génération peuvent être utilisés à ce stade en fonction de besoins multiplateformes et multitechnologies. Les équipes de développement utilisent généralement des serveurs de génération pour faciliter un plus grand nombre de générations nécessaires en permanence dans le cadre d'une intégration continue.

IV-D-2-c. Référentiel de package▲

Un référentiel de package(appelé également référentiel d'actifs ou référentiel d'artefacts) est un mécanisme de stockage commun pour les fichiers binaires créés pendant la génération. Ces référentiels doivent également contenir les actifs associés aux fichiers binaires pour faciliter leur déploiement, tels que les fichiers de configuration, les fichiers d'infrastructure programmable et les scripts de déploiement.

IV-D-2-d. Environnement de test▲

Un environnement de test est l'emplacement dans lequel les équipes d'assurance qualité, les équipes d'acceptation utilisateur et celles de développement/test exécutent les tests. Divers types d'outils sont utilisés au cours de cette étape, en fonction des besoins de qualité. Voici quelques exemples :

• Test de gestion de l'environnement : ces outils facilitent le provisionnement et la configuration des environnements de test. Ils incluent les technologies d'infrastructure programmable et (si l'environnement est dans le cloud) les outils de provisionnement et de gestion du cloud ;
• Gestion de la donnée de test : pour une organisation qui veut mettre en place les tests continus, la gestion des données de test est une fonction essentielle. Le nombre de tests pouvant être exécutés et leur fréquence d'exécution sont limités par le volume de données disponibles pour les tests et la vitesse à laquelle les données peuvent être actualisées ;
• Test d'intégration, fonctionnel, de performance et de sécurité : des outils automatisés sont disponibles pour chacun de ces types de tests. Ces outils doivent être intégrés à un outil ou un référentiel de gestion des actifs de test commun où tous les scénarios de test, scripts de test et résultats associés peuvent être stockés et la traçabilité effectuée vers le code, les exigences et les défauts ;
• Virtualisation des services : les applications actuelles ne sont pas des applications monolithiques simples. Il s'agit de systèmes complexes qui dépendent d'autres applications, serveurs d'applications, bases de données et même d'applications et de sources de données tierces. Malheureusement, lors des tests, ces composants peuvent ne pas être disponibles ou peuvent être coûteux. Les solutions de virtualisation de services simulent le comportement — la fonctionnalité et les performances — des composants d'une application pour permettre les tests de bout en bout de l'application dans son ensemble. Ces outils créent des « bouchons » de simulation (composants virtuels) des applications et services nécessaires à l'exécution des tests. Le comportement et les performances de l'application peuvent être testés lorsqu'elle interagit avec ces parties de code du bouchon de simulation. IBM Rational Test Virtualization Server fournit ces fonctions de virtualisation des tests.

IV-D-2-e. Environnements de promotions et de production▲

Les applications sont déployées dans les environnements de promotions et de production. Les outils utilisés au cours de ces étapes incluent les outils de gestion et de provisionnement de l'environnement. Les outils pour l'infrastructure programmable jouent également un rôle essentiel dans ces étapes du fait de l'étendue des environnements au cours de ces étapes. Avec l'avènement des technologies de virtualisation et de cloud, les environnements de promotions et de production peuvent être constitués aujourd'hui de centaines, voire de milliers de serveurs. Les outils de surveillance permettent aux organisations de surveiller les applications déployées dans l'environnement de production.

IV-D-3. Automatisation du déploiement et gestion des versions▲

DevOps a pour principal objectif de réduire les goulots d'étranglement dans le pipeline de distribution pour le rendre plus efficace. L'un des principaux goulots d'étranglement auxquels font face les entreprises concerne la disponibilité et la configuration des environnements. Il n'est pas rare de voir les utilisateurs, notamment les développeurs et les testeurs, demander un environnement par le biais d'un système de gestion de tickets traditionnels, la satisfaction de ces demandes pouvant prendre des jours, voire des mois.

DevOps offre l'avantage, entre autres, de pouvoir développer et tester dans un environnement similaire à la production. Au goulot d'étranglement de la disponibilité de l'environnement s'ajoute le risque d'avoir un environnement disponible différent de celui de production. Cette discordance peut se limiter à de simples différences dans la configuration de l'environnement — au niveau du système d'exploitation ou du middleware, ou bien elle peut être beaucoup plus grave avec la présence d'un type de système d'exploitation ou de middleware dans les environnements de développement, totalement différent de celui de l'environnement de production.

L'absence de disponibilité des environnements se traduit par des délais d'attente potentiellement longs pour les utilisateurs. La discordance entre les environnements de développement et de production peut poser des problèmes de qualité significatifs, car les développeurs ne peuvent pas vérifier le comportement de l'application telle qu'elle sera déployée dans l'environnement de production, ou pire, ne peuvent pas valider que le processus de déploiement validé sur les environnements de tests fonctionnera lorsqu'il faudra déployer dans l'environnement de production.

Le cloud résout ces problèmes de la manière suivante :

• la rapidité du provisionnement d'environnement sur les plateformes cloud peut fournir aux utilisateurs un accès d'usage en libre-service avec une disponibilité d'environnement et un accès à la demande ;

• la possibilité de provisionner et de décomissionner dynamiquement ces environnements en fonction des besoins, améliore la gestion des environnements et diminue les coûts en réduisant la nécessité d'avoir des environnements de tests statiques permanents ;
• la possibilité d'exploiter des technologies qui s'appuient sur des « modèles » et qui donnent la possibilité aux organisations de définir et versionner les environnements comme du logiciel permet de fournir des environnements qui répondent exactement aux besoins des utilisateurs — et qui correspondent surtout à des environnements de type production ;

• du point de vue de l'automatisation, la disponibilité des technologies d'automatisation du déploiement des applications, telles que IBM UrbanCode Deploy, permet avec un seul outil de provisionner l'environnement cloud et de déployer les versions appropriées vers ces environnements en fonction des besoins et quand cela est nécessaire. Ces technologies peuvent également configurer rapidement l'environnement et l'application pour répondre aux besoins des utilisateurs ;
• la disponibilité des technologies de virtualisation de services, telles qu'IBM Rational Test Virtualization Server, fonctionnant conjointement avec les environnements cloud, permet de simuler les services nécessaires aux tests sans avoir à provisionner des instances réelles de ces services.

L'illustration 4-1 montre comment les environnements cloud fonctionnent conjointement avec les technologies d'automatisation du déploiement et de virtualisation de services pour fournir des environnements de développement/test de bout en bout.

Le cloud sans DevOps c'est perdre tous les avantages qu'offre le cloud. L'adoption de DevOps avec des environnements hébergés dans le cloud permet d'offrir aux organisations qui développent et déploient des applications logicielles l'ensemble des fonctionnalités et des bénéfices qu'elles peuvent tirer du cloud.

Le déploiement d'une application cloud consiste à déployer l'application et à configurer l'environnement cloud où elle s'exécute. Ces deux tâches peuvent être exécutées séparément, mais lorsqu'elles sont combinées, cette opération s'appelle le déploiement de pile complète. Ces deux approches sont traitées plus en détail dans cette section.

La première approche consiste à séparer le provisionnement d'environnement cloud du déploiement de l'application. Dans ce cas, il n'existe pas un point unique d'orchestration des environnements cloud et des applications qui y sont déployées. L'outil d'automatisation du déploiement d'application considère les environnements cloud comme des environnements statiques. Ce scénario n'optimise pas les avantages du déploiement dans le cloud.

La seconde approche consiste à utiliser l'outil d'automatisation du déploiement applicatif comme outil d'orchestration unique pour le provisionnement d'environnement cloud et pour le déploiement des applications dans ces environnements provisionnés. Cela peut se faire en créant des « modèles » qui définissent l'environnement cloud et sa topologie et qui associent les composants d'application et la configuration aux nœuds définis dans l'environnement cloud.

Plusieurs technologies de modèles, telles que les modèles IBM Virtual System Patterns et OpenStack Hot, peuvent être utilisées pour définir des modèles d'environnements Clould. Les outils d'automatisation du déploiement, tels qu'IBM UrbanCode Deploy with Patterns, peuvent fournir un provisionnement de pile complète en utilisant ces modèles. Cela inclut le provisionnement de l'environnement cloud défini dans le modèle et le déploiement de l'application dans ce nouvel environnement. Une fois l'environnement provisionné, des modifications d'application, de configuration et de contenu peuvent être déployées en continu dans l'environnement cloud sous forme de mises à jour.

Les organisations peuvent également décider de procéder à un déploiement de pile complète lorsque les environnements et les applications associées sont toujours provisionnés ensemble comme un seul et même actif à déployer. Dans ce cas aucune mise à jour n'est apportée à l'environnement existant.

Lors de l'adoption du cloud, vous devez d'abord déterminer l'ensemble des responsabilités que vous souhaitez voir prises en charge par la plateforme cloud et celles que vous souhaitez prendre en charge vous-même. Il existe deux principaux modèles de service pour le cloud : Infrastructure as a Service (IaaS) et Platform as a Service (PaaS).

V-C-1. Iaas▲

Lors de l'adoption du cloud dans un modèle IassS, la plateforme cloud gère l'infrastructure sous-jacente et fournit les fonctionnalités et les services qui permettent de gérer toute l'infrastructure virtualisée. L'installation, les correctifs et la gestion du système d'exploitation, le middleware, les données et l'application restent dans le domaine de responsabilité de l'utilisateur.

Dans le contexte de l'adoption de DevOps dans un contexte de travail dans le cloud, le choix du modèle de service cloud à utiliser détermine la manière dont DevOps sera adopté. Pour le modèle de service IaaS, l'organisation d'utilisateurs est chargée de gérer l'ensemble du pipeline de distribution. Tous les outils et intégrations du pipeline de déploiement deviennent la responsabilité des équipes utilisateurs, y compris l'acquisition des outils adéquats et leur intégration pour définir le pipeline de distribution. En outre, ils doivent s'assurer que la collaboration entre les équipes de développement et celles des opérations respecte bien l'approche DevOps. Ce n'est pas parce qu'une plateforme cloud est utilisée comme service cloud qu'il n'est plus nécessaire de supprimer les silos de responsabilités entre les développeurs qui fournissent le code et les équipes des opérations qui fournissent l'infrastructure.

Bien que le cloud apporte une valeur considérable en fournissant une infrastructure IaaS aux équipes de livraison et déploiement des applications, cela n'empêche pas que ces équipes ont toujours besoin de toutes les fonctionnalités de DevOps pour pouvoir fournir la valeur que DevOps peut leur apporter.

Séparation des responsabilités L'un des principaux problèmes liés à l'exploitation de DevOps sur le cloud IaaS réside dans la définition de la séparation des responsabilités entre la plateforme cloud et l'outil de déploiement d'application. Quel outil pour quelle responsabilité ? Une approche simple en la matière consiste à se placer du point de vue des actifs de la pile cloud selon qu'ils aient besoin d'évoluer rapidement ou lentement. Le tableau ci-dessous montre les différentes couches de la pile matérielle/logicielle, des couches système d'exploitation, stockage et réseau jusqu'à l'application. Les couches de configuration d'application, de données et de middleware évoluent rapidement par nature. Elles évoluent souvent, car l'application, ses données et son utilisation se renouvellent sans arrêt. Le changement peut être très rapide pour une application qui est toujours en cours de développement. Les couches inférieures dans ce cas incluent le middleware (serveur d'applications, base de données, etc.), le système d'exploitation et le stockage, et elles ne changent pas si fréquemment. Comme la mise à jour et le réapprovisionnement de toutes les couches pour une simple modification qui affecte uniquement l'application, son contenu et la configuration ne seraient pas une méthode efficace, il est logique de séparer les responsabilités de ces couches à évolutions lente et rapide entre un outil de déploiement d'application et un outil de gestion cloud. Les couches à évolution rapide sont gérées et automatisées par l'outil de déploiement d'application et les couches à évolution lente le sont par le logiciel de gestion cloud fourni par la plateforme cloud.

V-C-2. PaaS▲

Le terme cloud hybride est très employé dans le domaine du cloud. Il est probablement un peu galvaudé pour décrire des scénarios cloud où plusieurs technologies cloud coexistent ou dans lesquels une infrastructure cloud et une infrastructure physique coexistent.

Une méthode simple pour définir un cloud hybride consiste à examiner cette multitude de scénarios de cloud.

• Infrastructure cloud et infrastructure physique : scénario de cloud hybride très courant. Il s'agit du scénario standard, à moins que l'entreprise soit née dans le cloud. Toutes les organisations ont des charges de travail et des applications qui s'exécutent dans leur infrastructure physique existante. Dans la plupart des cas, certaines de ces applications continuent de fonctionner sur l'infrastructure physique. Les applications mainframe et les systèmes d'enregistrements à forts volumes de données qui ne peuvent être migrés vers le cloud du fait des contraintes technologiques et de coût sont des exemples types. Même si une organisation migre toutes ses charges de travail vers le cloud, la migration ne peut pas être exécutée du jour au lendemain, et l'infrastructure physique coexistera avec l'infrastructure cloud pendant une période plus ou moins longue.
• cloud sur site et cloud hors site : dans ce scénario, une entreprise peut adopter un cloud hors site (public ou privé virtuel) pour certaines applications et charges de travail, et un cloud sur site (privé) pour les autres. Il peut s'agir, par exemple, d'une organisation qui exploiterait un cloud hors site économique pour gérer ses environnements de développement, et un cloud sur site autogéré dans son propre centre de données pour toutes les charges de travail de production.
• IaaS et PaaS : ce scénario inclut les clients ayant adopté un modèle de service Cloud PaaS pour certaines charges de travail — nouveaux systèmes innovants d'applications de type engagement, par exemple — et IaaS pour un système plus traditionnel de charges de travail d'enregistrement.

Pour l'adoption de DevOps, l'existence d'un cloud hybride présente de nouveaux défis, car dans ce cas, il existe des pipelines de distribution d'applications qui couvrent des environnements de cloud hybride et physiques complexes. Exemples d'environnements cloud hybride :

• une organisation peut décider d'utiliser un cloud public pour le développement, les tests et les autres environnements de non-production, et un cloud sur site, ou même une infrastructure physique, pour la production ;
• une organisation peut disposer d'un système d'applications d'engagement déployé dans un environnement cloud, alors que les systèmes d'applications d'enregistrements qui fournissent les services back-end pour les principales applications métier peuvent toujours résider dans l'infrastructure physique, par exemple un mainframe ;
• les organisations peuvent tirer parti d'un PaasS public pour l'expérimentation avec les applications innovantes et vouloir les placer dans un cloud privé lorsqu'une expérimentation aboutit ;
• les organisations peuvent vouloir porter les charges de travail d'application sur plusieurs plateformes cloud pour ne pas être dépendantes d'un seul fournisseur ou pour permettre de déployer les charges de travail critiques sur des clouds de plusieurs fournisseurs.

Le déploiement d'applications dans ces divers environnements cloud et physiques constitue la principale nécessité de l'adoption DevOps dans un cloud hybride. Les applications, telles qu'IBM UrbanCode Deploy with Patterns, utilisent des modèles pour associer les applications et les configurations à plusieurs environnements, physiques ou cloud, ce qui permet d'utiliser le déploiement automatisé dans les environnements cloud hybrides.

Dans une entreprise, en règle générale, les applications mobiles ne sont pas des applications autonomes. Leur logique applicative sur l'appareil mobile est très limitée, et ces applications font surtout office d'interfaces avec les applications d'entreprise déjà utilisées dans l'entreprise. Ces applications d'entreprise back-end peuvent être aussi bien des systèmes de traitement de transactions que des portails employés ou encore des systèmes d'acquisition de clients. Le développement et la fourniture d'applications mobiles sont complexes et nécessitent de fournir un ensemble de services dépendants de manière coordonnée, avec toute la fiabilité et l'efficacité nécessaires.

Pour les applications mobiles d'entreprise, les cycles de publication et les publications de nouvelles fonctions doivent être coordonnés avec les applications et services qui interagissent avec elles. Par conséquent, l'adoption de DevOps doit englober impérativement les équipes dédiées aux applications mobiles, ainsi que les autres équipes de développement de logiciels dans l'entreprise.

Quatre-vingts pour cent des données d'entreprise proviennent du mainframe, et soixante-dix pour cent de toutes les transactions touchent un mainframe. L'ouverture d'un chemin d'accès mobile vers ces fonctions de mainframe peut changer la manière de mener l'entreprise et d'approcher les clients, mais l'objectif peut s'avérer compliqué. Vous pouvez être confronté à un manque de compétences, à des silos organisationnels ou à une hétérogénéité de plateformes qui allongent les cycles de livraison, génèrent des retards inutiles et consomment énormément de ressources. Pour fournir un mobile à ces applications, les entreprises utilisent DevOps, une approche de distribution de logiciel qui repose sur la rapidité et l'efficacité sans sacrifier la stabilité et la qualité.

Aucun concept ou principe DevOps spécifique ne s'applique uniquement aux applications mobiles. Cependant, les applications mobiles nécessitent d'autant plus de recourir à DevOps que leurs cycles de développement sont courts et leur évolution rapide inhérente.

ALM (Gestion du cycle de vie des applications) est l'ensemble des processus déployés pour gérer le cycle de vie d'une application, de l'idée (besoin) à la réalisation de l'application qui est déployée et à la fin en maintenance. Ainsi, en considérant DevOps comme une fonctionnalité métier de bout en bout, ALM devient le concept fondamental qui sous-tend le processus DevOps. DevOps élargit le champ ALM pour inclure les responsables métier, les clients et les opérations dans le processus.

Le chemin d'adoption Développement/Test DevOps (voir le chapitre 2 pour plus d'informations) est plus en conformité avec les fonctionnalités ALM traditionnelles de gestion des besoins, des changements, du contrôle de version, de la traçabilité et de gestion des tests. Cependant, les autres fonctionnalités ALM, telles que le suivi et la planification, interviennent dans le chemin d'adoption Pilotage. Les tableaux de bord et les rapports sont quant à eux inclus dans le chemin d'adoption Exploitation.

Le développement selon les principes Lean et Agile sont les points clés de l'approche DevOps — l'un des résultats étant la réduction du gaspillage avec des équipes plus performantes. L'efficacité et la répétition des meilleures pratiques accélèrent les cycles de développement en permettant aux équipes d'être plus innovantes et plus réactives et donc d'augmenter la valeur client. L'extension des principes d'efficacité et d'agilité (Lean et Agile) au-delà de l'équipe de développement à une équipe d'équipes et à l'ensemble du cycle de vie de livraison des produits et des applications est au cœur de l'approche DevOps.

La plupart des équipes ont déjà adopté l'agilité et veulent étendre leurs processus actuels dans leur adoption à DevOps. En règle générale, de nombreux modèles courants sont disponibles à cet effet. Ces modèles comprennent Scaled Agile Framework (SAFe) et Disciplined Agile Delivery (DAD). Certaines entreprises ont aussi étendu efficacement leur processus Scrum à de très grandes équipes. Ces modèles ont pour vocation de fournir une méthodologie pour adopter l'agilité au niveau de l'entreprise. Cela implique de tenir compte non seulement du développement du code, mais également de l'architecture, du financement du projet et de la gouvernance des processus et des rôles qu'impose la gestion, en appliquant précisément les mêmes principes d'efficacité et d'agilité que ceux qui se sont avérés efficaces au niveau de l'équipe. Quelle que soit l'infrastructure utilisée pour étendre l'agilité, on utilisera les principes de base de l'agilité et on appliquera les meilleures pratiques pour les exploiter afin d'instaurer l'efficacité et l'efficience dans l'entreprise.

Dans une grande entreprise informatique type, il n'est pas rare de trouver des applications multitiers qui couvrent plusieurs plateformes, ayant chacune ses propres besoins de processus de développement, outils et compétences. Généralement, ces systèmes multitiers intègrent des applications Web, des ordinateurs et mobiles sur les systèmes frontaux et back-end, telles que les applications du commerce, les systèmes d'entrepôt de données, les applications exécutées sur des mainframes et les systèmes milieu de gamme. La gestion et la coordination des versions des différents composants de ces systèmes multiniveaux, dont la plupart peuvent se trouver sur différentes plateformes, peuvent s'avérer compliquées, même pour l'entreprise informatique la mieux organisée.

Une approche raisonnée consiste à suivre des processus de fabrication, de configuration et de déploiement cohérents automatisés dans toutes les étapes du développement. Ainsi, vous êtes assuré de générer tous les composants — et seulement les composants dont vous avez besoin. Elle garantit également l'intégrité de l'application à mesure que des modifications sont apportées et pendant le cycle de test, de contrôle qualité et de production du projet. IBM UrbanCode Deploy dispose d'un modèle applicatif qui permet d'automatiser le déploiement complexe des applications multiniveaux.

La gestion d'outils distincts pour différentes équipes basées selon les plateformes est une réalité dans l'environnement multifournisseur et multiplateforme actuel. Dans ce contexte, des plateformes ouvertes, telles que IBM Jazz permettent d'intégrer des outils hétérogènes pour fournir une solution unifiée. Des pratiques de déploiement cohérentes permettent aux équipes d'exécuter un déploiement fiable et réutilisable sur les plateformes pour générer une réelle valeur métier.

L'entreprise actuelle dépend de la rapidité à laquelle l'informatique peut fournir le logiciel. Généralement, ces entreprises utilisent des systèmes d'applications d'enregistrement (développées en interne ou applications du commerce) déployées sur des systèmes mainframe ou milieu de gamme. Elles sont confrontées à une multitude de défis :

• obstacles réguliers ;
• complexité des processus ;

• exploitation inadéquate des compétences ;
• silos organisationnels ;
• plateformes et outils qui allongent les cycles de livraisons de versions, génèrent des retards inutiles et gaspillent les ressources.

DevOps au niveau de l'entreprise permet aux parties prenantes de la planification, du développement, des tests et des opérations de distribuer en continu le logiciel dans l'entreprise. Actuellement, les entreprises déploient des applications qui sont réellement interplateformes, qu'il s'agisse d'appareils mobiles ou de mainframes. L'approche DevOps du développement utilise les principes d'efficacité pour créer un pipeline de distribution efficient et efficace qui permet de déployer, tester et distribuer les applications, car il améliore la qualité et accélère le développement tout en réduisant ses coûts.

Compte tenu de la vraie nature multiplateforme des entreprises actuelles, avec l'existence d'applications mobiles, de cloud, réparties et mainframe — qui doivent être toutes créées, intégrées, déployées et exploitées, l'efficacité, la rationalisation et la collaboration qu'apporte DevOps deviennent un véritable différenciateur concurrentiel essentiel.

Face au recours croissant à l'externalisation et aux partenariats stratégiques pour apporter à l'entreprise les compétentes et capacités dont elle a besoin, les chaînes logistiques logicielles deviennent la norme. Une chaîne logistique est un système d'organisations, de personnes, de technologies, d'activités, d'informations et de ressources intervenant dans le processus de livraison d'un produit ou d'un service d'un fournisseur chez un client : les divers fournisseurs dans la chaîne peuvent être internes ou externes à l'entreprise.

Dans une entreprise qui a opté pour un modèle de chaîne logistique pour la fourniture de ses logiciels, l'adoption de DevOps peut relever du défi, car les relations entre les fournisseurs sont plus gérées par des contrats et des accords sur les niveaux des services que par la collaboration et la communication. Néanmoins, une telle entreprise peut toujours adopter DevOps. Les principales équipes du projet conservent la propriété des fonctionnalités de planification et de mesure, les autres fonctionnalités étant partagées entre les autres fournisseurs. Dans le pipeline de distribution, différents fournisseurs peuvent détenir différents morceaux du pipeline. L'utilisation d'un ensemble d'outils communs et d'un référentiel d'actifs communs est donc essentielle. Un outil de gestion des éléments de travail, par exemple, fournit des fonctions de génération de rapports sur tous les éléments à la charge de chacun des fournisseurs, et permet de transférer la propriété des demandes de travail aux fournisseurs. L'utilisation d'un référentiel d'actifs communs fournit un mécanisme pour transmettre les actifs dans le pipeline pour permettre la livraison en continu.

L'étape suivante importante pour DevOps est son évolution dans le domaine des systèmes et des appareils embarqués, où elle est généralement appelée ingénierie continue. Au début d'Internet, la plupart des données qui y étaient partagées étaient générées par des individus. Aujourd'hui, un nombre incalculable d'appareils connectés à Internet (capteurs et actionneurs, par exemple) génèrent largement plus de données que l'être humain. Ce réseau de périphériques interconnectés sur Internet s'appelle l'Internet des objets.

Dans cet espace, DevOps est potentiellement encore plus essentiel du fait de la coexistence du matériel et du logiciel incorporé qui s'y exécute. Les principes de DevOps sont reflétés dans l'ingénierie continue pour garantir que le logiciel embarqué dans les appareils est de très haute qualité avec les spécifications techniques appropriées.

Le service «Opérations» dans l'ingénierie continue est remplacé par des techniciens matériel ou système qui conçoivent des matériels personnalisés pour les périphériques. La collaboration entre les équipes de développement et de test et les ingénieurs système est cruciale pour développer et fournir des matériels et des logiciels d'une manière coordonnée, bien que le développement des matériels et des logiciels doive suivre des cycles de livraison différents. Les besoins en développement et en test pour la livraison continue restent les mêmes. Des simulateurs sont utilisés pour tester le logiciel et le matériel pendant le développement.

La culture est un fil invisible dans une organisation. Elle repose sur des valeurs et des comportements que les managers et les employés font tous évoluer. Bien souvent, vous ne comprenez pas la culture d'une organisation tant que vous n'êtes pas impliqué dans un projet de transformation significative. Il y aura toujours les sceptiques qui attendent afin de voir s'il ne s'agit pas simplement de l'engouement du mois. Des leaders de la transformation émergeront. Il est donc important d'établir une approche pour comprendre ces dynamiques et identifier les rôles de chacun de manière à bien identifier les vrais inhibiteurs.

Pour traiter la dynamique culturelle, les responsables d'IBM SWG ont adopté diverses approches :

• Sélectionner le leader approprié : le leader a pour rôle de rassembler les différents points de vue afin d'orienter l'équipe vers un ensemble commun d'objectifs, d'inhibiteurs, de changements de processus et de décisions sur les premières étapes à mettre en œuvre ;
• Impliquer les parties prenantes : tous ces changements doivent absolument être soutenus par la direction, les managers et chaque contributeur individuel des différentes disciplines du développement. Il faut nommer et impliquer des leaders et experts du changement parmi les représentants métier, les architectes, les développeurs, les testeurs et les opérations ;
• Mesurer les améliorations et les résultats : il est essentiel de disposer d'un ensemble de mesures qui permettent de dégager l'efficacité et les résultats économiques de ces changements. Ces objectifs et mesures doivent placer la barre assez haut et rendre les personnes responsables en évitant le risque d'un désengagement ;
• Créer une dynamique avec les premiers succès : la compréhension des inefficacités existantes et la mesure des améliorations apportées par DevOps dans chaque domaine créent une dynamique du changement ;
• Communiquer et écouter : en tant que leader, il est important de comprendre la dynamique réelle de l'instauration du changement dans l'équipe. Le échanges 1 à 1 avec les individus et les interactions régulières en face à face entre les équipes techniques, les responsables et les leaders métier permettent d'évaluer l'adhésion de l'équipe, sa perception des inhibiteurs, et, tout aussi important, offrent une opportunité au management de partager ses perspectives sur les priorités et l'avancement.

Si vous êtes dirigeant d'entreprise, vous devez encourager les équipes et vous rendre disponible pour comprendre et éliminer les obstacles. Évoluer dans une équipe soudée avec des objectifs métier clairs est indispensable pour amener tout le monde à emprunter le même chemin.

L'équipe produit IBM SWG Rational Collaborative Lifecycle Management fait partie d'une entité plus large qui développe des outils de développement de logiciels dans les domaines de la planification, la livraison des logiciels, la gestion de la qualité des logiciels et la surveillance et l'analyse des applications.

Cette équipe produit d'IBM SWG est une grande équipe organisée à l'échelle mondiale en quatre équipes produit sur 25 sites de 10 pays. Avant d'adopter l'approche DevOps, l'activité du groupe reposait sur une planification de sorties produit annuelles, y compris une période de trois à six mois pour déterminer ce qu'il fallait mettre dans la sortie de la version annuelle.

L'équipe IBM SWG considéra qu'elle ne réagissait pas suffisamment rapidement à l'évolution du marché et des besoins des clients. Elle décida de raccourcir le cycle de sorties de versions, non seulement dans les phases de développement et de test, mais également pour la collaboration et les interactions avec les parties prenantes de l'entreprise et les clients. La décision fut prise de passer d'une planification annuelle à une planification trimestrielle.

Outre la nécessité d'accélérer son développement pour fournir de nouvelles fonctionnalités plus fréquemment, l'équipe devait également s'engager plus rapidement pour prendre en charge les modèles de distribution cloud, le développement et les tests d'applications mobiles et d'autres fonctionnalités afin de prendre en compte les évolutions technologiques. L'équipe décida donc d'adopter les principes et pratiques de DevOps pour changer le développement des logiciels afin de livrer plus rapidement et plus fréquemment de la valeur pour ses clients.

Une modification d'une telle ampleur imposait un changement culturel dans l'organisation. Il fut donc décidé de créer quatre groupes de travail constitués de membres à la fois du management et de responsables techniques. Ces groupes de travail examinèrent complètement les processus de sortie des logiciels et décidèrent de changer les méthodes de travail. Un ensemble de mesures et plans d'action fut mis en place pour traiter les principaux points du processus de développement. Une équipe d'experts en livraison continue fut créée, et une personne fut chargée de former les équipes et de communiquer les meilleures pratiques à l'ensemble de l'organisation.

L'adoption de DevOps par l'équipe IBM SWG commença en identifiant ces objectifs :

• rationaliser le processus et introduire les nouvelles méthodologies ;
• améliorer l'usage des outils en termes de cohérence, de mise à l'échelle sur d'autres équipes, de traçabilité et de mesures ;
• faire évoluer la culture vers l'amélioration permanente.

Cette section explique les étapes suivies par l'équipe d'IBM SWG pour faciliter sa transformation DevOps.

VII-D-1. Étendre les pratiques Agile▲

VII-D-2. Exploiter l'automatisation des tests▲

VII-D-3. Créer un pipeline de livraison▲

L'équipe IBM SWG décida de créer un pipeline de distribution améliorant l'usage des outils comme « services » afin de permettre aux développeurs de valider le code, de le tester et de le déployer dans un environnement de production en quelque 60 minutes au lieu d'un ou deux jours auparavant. Ce processus a permis de réduire les retours en arrière et d'optimiser la productivité.

L'équipe de déploiement détermina qu'un pipeline de distribution continue nécessitait d'appliquer les meilleures pratiques suivantes :

• exécuter les tests au plus tôt (« Shift-left ») et automatiser au maximum ;

• utiliser le même mécanisme de déploiement sur tous les environnements ;
• s'efforcer de maintenir constamment l'application en attendant d'être livrée aux utilisateurs ;
• traiter l'infrastructure comme une infrastructure programmable.

L'illustration 6-1 montre les produits et les fonctions fournis dans le cadre du pipeline de livraison continue adopté par IBM SWG.

Une meilleure pratique essentielle de l'implémentation d'un pipeline de livraison continue est de « traiter l'infrastructure comme une infrastructure programmable ». Cela implique que le développeur peut écrire des scripts pour configurer l'infrastructure requise pour l'application dans le code de cette dernière. Auparavant, cela était réalisé généralement par un administrateur système ou une personne chargée des opérations, mais désormais avec le contrôle et les gains d'efficacité que cela apporte, le développeur peut le faire directement. Puppet, Chef et IBM UrbanCode Deploy with Patterns sont des exemples des nouvelles catégories d'outils d'automatisation qui font de l'infrastructure programmable une réalité concrète.

Désormais, l'équipe d'IBM SWG traite son infrastructure comme une infrastructure programmable et suit ces meilleures pratiques :

• traiter les définitions de modèles de déploiement, les packages de scripts et les services comme du code ;
• versionner tout ;
• automatiser le déploiement des modèles de topologie vers le cloud ;
• gérer les versions de modèles dans plusieurs environnements cloud ;
• automatiser les tests des modèles ;
• nettoyer les ressources de catalogue pour éviter la propagation.

VII-D-4. Expérimenter rapidement▲

Le concept de livraison continue couvre non seulement les activités de développement, telles que l'intégration continue et le déploiement continu, mais également l'activité plus fondamentale d'apprentissage qui peut être réalisée de manière optimale via l'expérimentation et la mesure de résultats.

Lorsque des fonctionnalités ou des services sont ajoutés à une application, vous n'êtes pas sûr que le client en tirera les avantages escomptés. C'est la raison pour laquelle IBM considère qu'il est important d'expérimenter en amont et souvent, de demander aux clients des retours sur les fonctionnalités qui leur conviennent et de supprimer celles qui n'offrent que peu d'avantages ou qui peuvent peut-être même présenter un problème. Cette stratégie est décrite dans le diagramme de l'illustration 6-2.

L'équipe d'IBM SWG s'est enrichie de l'expérimentation fréquente et a développé les meilleures pratiques suivantes :

• définir des mesures et des critères de succès/d'échec ;
• déterminer ce qui fonctionne par expérimentation— des petits tests par un petit groupe d'utilisateurs afin de déterminer l'utilité d'une fonctionnalité ;
• lancer en continu plusieurs expérimentations ;
• prendre rapidement des décisions à partir de faits ;
• distribuer rapidement pour expérimenter plus rapidement ;
• créer un mécanisme pour permettre l'expérimentation au niveau du système (Google Analytics, IBM Digital Analytics, etc.) ;
• envisager différents modèles d'expérimentation (tests A/B classiques, MAB MultiArmed Bandit, etc.) ;

• suivre deux chemins simultanément pour les projets associés : expérimenter sur un projet cloud et utiliser les données des expérimentations pour, non seulement déterminer la direction du projet sur le cloud, mais également celle des projets associés sur site.

VII-D-5. Améliorer en continu▲

Une approche DevOps a permis à l'équipe d'IBM SWG d'obtenir des gains significatifs au niveau de l'amélioration de la satisfaction client et d'une meilleure adoption client et, finalement, de connaître une croissance à deux chiffres de son chiffre d'affaires. Les délais plus courts ont stimulé les équipes de livraison au sein d'IBM, ce qui s'est traduit par des livraisons plus rapides des mises à jour des solutions sur site, ainsi que la livraison de nouveaux services cloud, tels Bluemix, DevOps Services for Bluemix ou Collaborative Lifecycle Management as a Managed Service (CLM aaMS).

L'illustration 6-3, un exemple du succès de l'approche DevOps chez IBM, montre les résultats mesurés atteints par l'équipe produit IBM SWG Rational Collaborative Lifecycle Management.

Ce que l'on appelle généralement DevOps, provient des entreprises « nées sur le Web » (sociétés qui proviennent d'Internet), telles que Etsy, Netfix et Flickr. Cependant, les grandes entreprises utilisent des principes et des pratiques DevOps pour distribuer les logiciels depuis des dizaines d'années. En outre, les principes DevOps actuels, décrits dans ce manuel, se caractérisent par un niveau de maturité qui permet de les appliquer aux grandes entreprises disposant de technologies multiplateformes et d'équipes réparties.

Les équipes d'opérations écrivent depuis toujours des scripts pour gérer les environnements et les tâches répétitives, mais avec l'évolution de l'infrastructure programmable, ces équipes ont eu besoin de gérer ces énormes volumes de code avec les pratiques de l'ingénierie logicielle, telles que la gestion de version de code, le check-in, le check-out, le développement en parallèle et la fusion. Actuellement, une nouvelle version d'un environnement est générée par un membre d'une équipe d'opérations en créant une nouvelle version du code qui la définit. Cependant, cela n'implique pas que les équipes des opérations doivent apprendre à coder en Java ou C#. La plupart des méthodologies d'infrastructure programmable utilisent des langages tels que Ruby qui sont relativement simples à maîtriser, notamment pour les personnes qui savent créer des scripts.

Bien que le terme laisse penser qu'il concerne le développement et les opérations, DevOps s'adresse à toute l'équipe. Toutes les parties prenantes dans la livraison de logiciel — les métiers, les utilisateurs, le management, les partenaires, les fournisseurs, etc. — sont concernées par DevOps.

Certaines personnes craignent que les fonctionnalités DevOps, telles que la livraison continue, ne soient pas compatibles avec les vérifications et les processus prescrits par ITIL (Information Technology Infrastructure Library), un ensemble de meilleures pratiques pour la gestion des services informatiques. En fait, le modèle de cycle de vie ITIL est compatible avec DevOps. La majorité des principes définis par ITIL sont parfaitement compatibles avec les principes DevOps. Cependant, ITIL pâtit d'une mauvaise réputation dans certaines organisations du fait de son implémentation avec des processus Waterfall lents qui ne permettent pas d'effectuer rapidement des modifications et des améliorations. L'alignement des pratiques entre les équipes de développement et des opérations est l'essence même de DevOps.

Les secteurs réglementés ont un besoin global de vérifications et protection et s'assurer de l'approbation des parties prenantes chargées de la conformité et de l'audit. L'adoption de DevOps améliore la conformité s'il est appliqué correctement. L'automatisation des flux de processus ainsi que l'utilisation d'outils disposant de fonctionnalités intégrées pour enregistrer les informations d'audit peuvent être bénéfiques.

Les organisations dans les secteurs réglementés auront toujours des points de contrôle ou points de passage nécessitant des interventions manuelles, mais ces éléments ne sont pas incompatibles avec DevOps.

Les équipes externalisées doivent être considérées comme des prestataires ou des fournisseurs de fonctionnalités alimentant le pipeline de distribution DevOps. Cependant, les entreprises doivent s'assurer que les pratiques et les processus des équipes des fournisseurs sont compatibles avec ceux de leurs équipes de projet internes.

L'utilisation d'outils communs de planification de versions, de gestion des éléments de travail et de référentiel d'actifs améliore de manière significative la communication et la collaboration entre les équipes métier, les fournisseurs et les équipes projet, et elle permet d'appliquer les pratiques DevOps. L'utilisation d'outils de gestion de versions d'applications peut améliorer considérablement la capacité d'une organisation à définir et coordonner l'ensemble du processus de sorties de versions entre tous les participants.

Quand on pense à DevOps, on pense souvent au cloud du fait de sa capacité à provisionner dynamiquement les ressources d'infrastructure pour les développeurs et les testeurs, ce qui permet d'obtenir rapidement des environnements de test sans attendre des jours/semaines la réponse positive à une demande manuelle. Cependant, le cloud n'est pas nécessaire pour adopter les pratiques DevOps dès lors qu'une organisation dispose de processus efficaces pour provisionner les ressources nécessaires aux déploiements et tests des nouvelles modifications de l'application.

La virtualisation est facultative. Le déploiement continu vers des serveurs physiques est possible si les serveurs peuvent être configurés et déployés suffisamment rapidement pour satisfaire les équipes.

Les systèmes complexes ont besoin de la discipline et collaboration qu'apporte DevOps. Ces systèmes se caractérisent généralement par des composants logiciels et/ou matériels ayant chacun leurs propres cycles et jalons. DevOps facilite la coordination de ces cycles de distribution et la planification des versions au niveau système.

Certains membres de la communauté DevOps ont inventé des termes humoristiques, tels que ChatOps (les équipes effectuent toutes les communications via des outils de communication, tels qu'Internet Relay Chat) et HugOps (DevOps se concentre uniquement sur la collaboration et la communication). L'origine de ces termes découle, à tort, que la communication et la collaboration peuvent résoudre tous les problèmes.

Certes la communication est un élément important de DevOps, mais une meilleure communication combinée à des processus sources de gaspillage n'améliore pas les déploiements.

Cette vision erronée provient des organisations qui déploient uniquement des applications. Certaines de ces entreprises indiquent fièrement sur leurs sites Web qu'elles déploient tous les jours en production. Cependant, le déploiement quotidien est non seulement impossible dans les grandes entreprises qui déploient des applications complexes, mais peut être également impossible du fait des restrictions réglementaires ou de l'entreprise. DevOps ne se limite pas simplement au déploiement, et certainement pas au déploiement continu vers la production. L'adoption de DevOps permet aux organisations de mettre en production lorsqu'elles le décident et non pas en fonction d'une simple date marquée sur un calendrier.