Le DevOps , et après ?
Répondre
Archives par mot-clé : continuous integration
DevOps sur PlovDev
De retour de la conférence PlovDev, j’ai eu à répondre à quelques questions pour la newsletter de mon ESN Proxiad. Si j’y suis responsable DevOps, je suis surtout un passionné et un profond convaincu de ce mouvement. Il entre dans la dynamique du surgissement d’un nouveau monde. Une ère passionnante s’ouvre à nous !
Ayant à coeur de dynamiser et partager cette nouvelle approche, je me permets de publier ici cet interview.
Une application est absolument tout ce qui existe et se passe entre le push et l’exploitation d’un commit. Quand on intègre cette notion, on comprend le DevOps.
Welcome to the era of DevOps!
Installation de GitLab sur Debian
Le partage, un des maitres-mots du mouvement DevOps, commence par l’usage d’un référentiel (Repository pour les anglophones) communautaire. Il sert bien sûr pour partager des sources de codes que chacun pourra corriger et améliorer, mais il sert aussi au perfectionnement des configurations. La mise en commun des configurations, ce grand travail collectif précédemment abordé, permet une mise en lumière sur des besoins spécifiques, les dépendances de certains packages ou certaines versions de logiciels, ou encore certains paramétrages d’intergiciel (middleware pour les anglophones), ou les paramétrages des équipements réseaux. Quant une équipe mets en place un logiciel utilisant un port particulier autant qu’elle l’insère elle-même directement dans le fichier de configuration des plages de ports à ouvrir. A contrario de l’usage propriétaire où il faut opérer à une demande auprès de l’équipe réseau pour reprendre l’exemple, cette démarche de modification par tous -et pour tous- n’est possible que dans une dynamique communautaire.
Un des plus célèbres référentiels communautaires est GitHub.com, or pour différentes raisons, entre autre de confidentialité, il peut être interdit d’usage dans certaines sociétés (OVH : Pourquoi j’ai interdit GitHub ?). Il est donc intéressant de trouver une solution interne. Un de ces gestionnaires de référentiel Git est GitLab qui propose une Community Edition (CE) et une Enterprise Edition (EE), ainsi qu’une Continuous Integration qui sort de notre actuel sujet. Voyons dans cet article comment installer GitLab CE.
DevOps – Présentation – 3
Le facteur humain est, à mon sens, le plus important dans une démarche DevOps. Dans les deux articles précédents, je décrivais « bonheur de produire de la qualité ensemble », et je vulgarisais rapidement les concepts de Continuous Integration et Continuous Delivery apportant respectivement le bien-être du développeur et le confort de l’exploitant. Concentrons-nous ici sur le « produire ensemble », sur la charnière entre ces deux mondes, autrement dit sur la collaboration de ces deux ensembles d’équipes.
Le terme d’ensemble est choisi pour sa confusion entre l’adverbe et le nom, subtilité de la langue française dont j’abuse. La notion d’ensemble des équipes est important et mérite une présentation. Ce qui nous aménera à se poser la question de leur collaboration ensemble.
DevOps – Présentation – 2
Le rapprochement entre les équipes de développement et d’exploitation est l’élan principal du mouvement DevOps. Pour appréhender l’interactions entre ces deux équipes, il faut comprendre le cycle de vie d’une application. Si celui-ci comporte une phase initiale d’analyse des besoins et d’études de faisabilité entre autre, il passe, pour ce qui concerne notre sujet, par une chaine de montage (un workflow pour les anglophones) qui va de la conception à la mise en production. Du développement à l’exploitation.
Cette présentation est plus de la vulgarisation qu’un discours hautement académique, je prends donc le parti de la simplification et de présenter le cycle de vie comme l’adjonction de deux cycles distincts, celui du développement et celui du déploiement dans les environnements de recette et de production. On pourrait palabrer sur la pertinence de cette césure, et il est vrai que certaines méthodes voire outils ne les distinguent pas aussi franchement, mais le but avoué de cet article est de présenter les deux concepts qui ainsi s’appuient sur un cycle de vie, respectivement le Continuous Integration et Continuous Delivery (Intégration continue et Livraison continue pour les francophones).
Conte de faits
A mes débuts dans les banques on ne disait pas « le service informatique », mais on parlait de « L’informatique ». Le service était bicéphale : la production et le bureau des études.
A la production où régnait une odeur de café, était le pupitre, opérateur technique qui contrôlait, vérifiait, parfois procédait à des relances principalement motivées par les retards des partenaires. Les incidents étaient extrêmement rares, et dans ce cas, le pupitre analysait l’historique, en s’appuyant sur le code source. Après quoi il s’adaptait pour résorber le souci et procédait à une démarche assez simple qui consistait à prendre un papier, un stylo, et le couloir.
Au bureau des études où régnait une odeur de mélange de thés, étaient les études, fonctionnels soucieux des standards de production qui inventaient, préparaient, développaient les processus de demain. Et à de rares occasions, accueillaient le pupitre pour voir avec lui l’incident rencontré et surtout comment le résoudre au plus vite.
Découvert au petit matin, l’incident était pris en charge rapidement par les études. Une nouvelle version du programme était livrée en recette avant midi pour qu’à 14H00 le batch quotidien de recette le valide pour 18H00. La mise en production était effectuée après les sauvegardes de 19H00.
A noter que ce batch quotidien de recette de 6 heures en avance sur la production était une garantie de détecter et anticiper d’éventuels problèmes à venir.
Cette organisation réactive qui n’avait pas de nom serait qualifiée aujourd’hui d’agile et continuous something.
Et puis un jour, un bien-pensant s’est mis en tête de structurer tout ça !..