|
Devops
  Cet article ne cite pas suffisamment ses sources (). Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
Le devops — ou DevOps (selon la graphie habituellement utilisée en langue anglaise) — est un mouvement en ingénierie informatique et une pratique technique visant à l'unification du développement logiciel (dev) et de l'administration des infrastructures informatiques (ops), notamment l'administration système. Apparu autour de 2007 en Belgique avec Patrick Debois, le mouvement Devops se caractérise principalement par la promotion de l'automatisation et du suivi (monitoring) de toutes les étapes de la création d'un logiciel, depuis le développement, l'intégration, les tests, la livraison jusqu'au déploiement, l'exploitation et la maintenance des infrastructures. Les principes Devops soutiennent des cycles de développement plus courts, une augmentation de la fréquence des déploiements et des livraisons continues, pour une meilleure atteinte des objectifs économiques de l'entreprise[1],[2],[3],[4]. Origine du nomDevops est la concaténation des trois premières lettres du mot anglais development (développement) et de l'abréviation usuelle ops du mot anglais operations (exploitation), deux fonctions de la gestion des systèmes informatiques qui ont souvent des objectifs contradictoires. À la conférence "Agile" de Toronto en 2008, Patrick Debois et Andrew Shafer introduisent le mot "Agile Infrastructure"[5] pour la première fois dans leur conférence. Le terme a été largement repris notamment pour la création d'une série de conférences sur le sujet appelée Devopsdays [6] dont la première a été organisée à Gand en Belgique, en octobre 2009. Apparition du concept devopsDistinction entre dev et opsAux débuts de l'informatique d'entreprise, les applications étant de taille limitée et peu intégrées les unes avec les autres, la distinction entre dev et ops n'avait pas lieu d'être : l'équipe qui s'occupait de l'administration du système se chargeait également d'y apporter les changements nécessaires pour le développement de nouvelles fonctionnalités. Mais l'évolution de l'information d'entreprise a introduit de nouvelles contraintes qui ont conduit à un nouveau paradigme :
Pour ces raisons, il est alors apparu plus efficace de séparer les aspects dev et ops en plaçant les responsabilités respectives dans des équipes séparées. On parle alors souvent de « build » pour la conception, de « run » pour l'exploitation et de « change » pour l'évolution, généralement réalisée en mode projet[réf. nécessaire]. Dans ce nouveau paradigme, les équipes sont organisées autour des mêmes systèmes et sont donc amenées à travailler main dans la main. Antagonisme des objectifsDans la réalité, cette séparation des devoirs entre les deux types d'équipes a rapidement mené à un conflit perpétuel du fait de l'incompatibilité des objectifs respectifs. Ceci peut être illustré en considérant les trois contraintes de la gestion de projet : coût, qualité/cadre de fonctionnalités et temps. En effet, l'objectif principal d'une équipe ops est de garantir la stabilité du système. De ce fait, l'équipe se concentre sur la contrainte qualité, au détriment du temps et du coût. La meilleure manière d'atteindre son objectif est de contrôler sévèrement la qualité des changements qui sont apportés au système qu'elle maintient. De son côté, l'équipe de développement a pour objectif principal d'apporter les changements nécessaires au moindre coût et le plus vite possible, souvent au détriment de la qualité lorsque des retards viennent mettre le plan en péril. L'antagonisme de ces objectifs, intrinsèques à l'activité de chaque type d'équipe, est encore exacerbé par la séparation des devoirs, au point de conduire à un rejet de sa propre responsabilité et au blâme de l'équipe « sœur », l'équipe de développement blâmant son alter ego ops pour les retards, et l'équipe d'exploitation tenant l'équipe de développement responsable des problèmes de qualité du code et des incidents survenus en production de ce fait. Plus généralement, organiser une entreprise comme un ensemble d'équipes ayant des objectifs indépendants les uns des autres avec des indicateurs spécifiques à chaque équipe va générer des optimums locaux et des guerres entre équipes, ce qui globalement pour l'entreprise n'est pas la meilleure chose. Un changement de paradigme est donc à nouveau nécessaire. Lien avec l'agilitéLe mouvement devops est né d'une part de la volonté de globaliser les méthodes agiles à l'ensemble du système d'information et d'autre part de l'application des principes de l'agilité à la production. Il est cependant possible d'être agile dans une équipe uniquement de développement, comme il est possible de mettre en place certains principes devops dans un environnement de développement en cascade. DevopsdaysLes DevOpsDays sont une série mondiale de conférences techniques sur le développement de logiciels, les opérations d’infrastructure informatique et entre leurs interactions. Chaque événement est organisé par des bénévoles de la région. La plupart des événements de DevOpsDays proposent une combinaison de conférences organisées et de contenu auto-organisé par l'espace ouvert à tous[7]. Les premiers devopsdays ont eu lieu à Gand, en Belgique, en 2009. Depuis, les événements de devopsdays se sont multipliés.  Changement culturelLes initiatives DevOps peuvent créer des changements culturels dans les entreprises[8] en transformant la façon dont les opérations, les développeurs et les testeurs collaborent pendant les processus de développement et de livraison. Faire en sorte que ces groupes travaillent de manière cohérente est un défi critique dans l'adoption de DevOps d'entreprise[9],[10]. DevOps concerne autant la culture que la chaîne d'outils[11]. Construire une culture DevOpsLe rapport State of DevOps 2015 a révélé que les sept principales mesures présentant la plus forte corrélation avec la culture organisationnelle sont:
AdoptionDe nombreuses sociétés dans le monde adoptent les principes DevOps. D'autres pratiques industrielles sont parfois comparées au DevOps, à l'exemple des équipes de Site Reliability Engineering (SRE) mises en place par Google à partir de 2003, dédiées à l'amélioration de la disponibilité et la fiabilité des sites web et applications. En 2017, 35 % des directions informatiques ont adopté la démarche DevOps[12]. Comment atteindre cette fluidité entre développement et exploitationSanjeev Sharma et Bernie Coyne[13] recommandent :
Voir aussiNotes et références
Liens externes |
Portal di Ensiklopedia Dunia
