Bonjour à tous!
Nous avons imprimé le
livre «DevOps Philosophy», et nous prévoyons également de faire un nouveau livre sur ce sujet.
De nombreuses copies sont cassées sur ce qu'est DevOps et ce qu'il n'est pas, ainsi que sur la relation entre DevOps et l'intégration continue. Par conséquent, nous vous demandons de parler le plus objectivement possible, partagez-vous le point de vue de l'auteur d'aujourd'hui Adam Mackay (Adam Mackay) concernant l'essence de DevOps - ou, à votre avis, l'image qu'il a proposée est quelque peu incomplète ou biaisée?
Nous lisons et commentons!
J'ai travaillé dans le domaine technologique toute ma vie et sous mes yeux, plusieurs méthodologies de développement de logiciels ont mûri et se sont formées. La plupart des idées qui les sous-tendent se résument à l'optimisation habituelle de la productivité dans un esprit de bon sens et sont empruntées à différents secteurs de l'économie. Il y a quelques années, tout le monde voulait passer d'un modèle de développement en cascade à un développement agile et agile. Je suis récemment allé travailler dans une entreprise progressiste, où ils essaient d'implémenter DevOps. Cette entreprise, Verifa, adhère depuis longtemps à Agile et essaie d'étendre les avantages de ce modèle non seulement au développement de logiciels, mais également à l'entreprise dans son ensemble.
DevOps est un nouveau mot à la mode dans l'industrie du logiciel. Ce concept combine beaucoup d'idées solides sur l'intégration des affaires et du développement, ainsi que la formulation d'un récit qui nous permet de parler du développement, de la livraison et du fonctionnement des logiciels dans un contexte unique.
DevOps est une approche dans laquelle les ingénieurs de développement et les ingénieurs administratifs participent ensemble à l'ensemble du cycle de vie d'un produit logiciel, de la conception et du développement au support produit complet. Ainsi, DevOps est conçu pour éliminer la désunion traditionnelle, où une équipe écrit le code, l'autre le teste, la troisième se déploie et la quatrième est responsable de l'opération.
Avec DevOps, les employés de sysadmin commencent à utiliser, avec le soutien des systèmes qui leur sont confiés, bon nombre des techniques qui ont été fixées dans l'arsenal du développeur. Dans DevOps, l'ingénierie des systèmes est construite exactement comme un flux de tâches pendant le développement. Toutes les ressources sont entrées dans le système de comptabilité source et couvertes par des tests appropriés.
Nous avons plusieurs sujets clés DevOps dans notre entreprise: valeurs, principes, méthodes, pratiques et outils.
Les valeursTout ingénieur est emprisonné pour avoir trouvé une solution, et une telle aspiration se traduit parfois par un rejet des nouvelles technologies, une réticence à expérimenter de nouvelles choses, qui s'exprime de différentes manières: du syndrome du "rejet du développement d'autrui" aux tentatives contre-productives de défendre sa niche. Pour vraiment passer à DevOps, ces préjugés doivent d'abord être reconnus puis surmontés. Aucune technologie, ni Docker, Kubernetes ou Amazon Web Services ne résoudra vos problèmes si vous ne comprenez pas quelle est la proposition de valeur.
"Tiens la main, mes amis!"
Instantané Rawpixel de
UnsplashPrincipesLes principes de notre entreprise sont basés sur le modèle Three Ways. Il a été développé par Gene Kim, auteur de «Visible Ops» et «The Phoenix Project», et Mike Orzen, auteur de «Lean IT». Nous recommandons de créer un environnement dans lequel la pensée systémique est stimulée, les cycles de rétroaction sont renforcés et une culture d'expérimentation et d'apprentissage continue est instillée.
Pensez constamment à l'ensemble du système. Demandez-vous: "Comment obtenez-vous encore plus de boucles de rétroaction?" La surveillance, les métriques et la journalisation sont trois de ces cycles qui aident les administrateurs à participer à la conception. Dans un environnement DevOps sain, les processus qui favorisent la création de cycles de rétroaction courts et efficaces sont stimulés, des exemples de tels processus sont la gestion des incidents, l'analyse objective de l'autopsie, la transparence ...
«Poignée de main avant MacBook Pro», un instantané de
rawpixel de
UnsplashLes méthodesGestion flexibleFlexible = simple. Divisez votre projet en petits domaines de travail, construisez, limitez la limite de progression, implémentez des boucles de rétroaction et réalisez la visualisation. C'est mon élément préféré de tout projet; des techniques de gestion flexibles donnent une sortie plus efficace, notamment en améliorant le débit et la stabilité du système; les employés subissent moins de stress au travail et obtiennent plus de satisfaction au travail.
Les gens d'abord, puis les processus, puis les outilsL'une des premières méthodologies proposées par les pionniers de DevOps est formulée comme «d'abord les gens, puis les processus, puis les outils». Dans notre entreprise, il est recommandé que vous conveniez d'abord de qui est responsable d'une tâche de travail spécifique. Ensuite, nous déterminons quels processus sont nécessaires pour résoudre ce problème. Après cela, les outils nécessaires à la mise en œuvre du processus sont sélectionnés. Sur le papier, tout cela semble logique, cependant, les ingénieurs et les gestionnaires succombent souvent à la «hâte accrocheuse pour l'obtenir!» des fournisseurs et dans ce cas, ils essaient de faire exactement le contraire: acheter un outil, puis former l'ensemble du flux de tâches pour lui.
Livraison continueCe terme est tellement présent sur toutes les lèvres qu'il est parfois même confondu à tort avec DevOps. En principe, c'est la pratique de la programmation dynamique et des tests de logiciels, fournissant des versions rapides de très petits fragments complets et prêts à l'emploi. En général, une livraison continue peut améliorer la qualité et la vitesse globales. La livraison continue est un élément clé du projet, qui doit être établi le plus tôt possible, le moteur de la réussite de la mise en œuvre de DevOps.
Gestion du changement
D'après mon expérience, il existe une corrélation directe entre la qualité de fonctionnement du système et l'organisation de la gestion du changement. Cela ne signifie pas que vous devez implémenter un contrôle traditionnel, ce qui ralentit le développement et est plus susceptible d'être nuisible que d'aider. Dans ce cas, vous avez besoin d'une plate-forme évolutive et fiable pour une livraison continue. Concentrez-vous sur l'élimination des artefacts fragiles, la reproductibilité du processus de génération, la gestion des dépendances et la création d'un environnement propice à l'amélioration continue.
Infrastructure en code (Configuration en code ... Tout en code)L'une des révélations que l'entreprise actuelle m'a enrichies est que tout système peut et doit être interprété comme du code. Les spécifications du système sont entrées dans les systèmes de contrôle de version et examinées par les pairs. En utilisant des mécanismes de déploiement modernes, en particulier Docker et Kubernetes, vous pouvez automatiquement construire, tester et créer de vrais systèmes basés sur les spécifications et les gérer par programme. Cette approche vous permet de compiler et d'exécuter le système, et de ne pas rendre les béquilles à long terme laborieuses, qui au fil du temps deviennent très difficiles à développer.
PratiqueDans toutes les organisations informatiques précédentes où je travaillais, l'approche des projets était la suivante: «écrivons quelque chose ... puis nous demanderons à quelqu'un de le tester et de le déployer.» Cette méthode ne cadre pas bien avec les plans. Le timing change et lorsque l'équipe de développement passe au projet suivant, les coûts d'exploitation deviennent insupportables.
«Montagnes russes sous un ciel bleu et des nuages blancs», un instantané de
Priscilla Du Preez de
UnsplashDans l'organisation actuelle, nous nous efforçons de tenir les développeurs au courant du service qu'ils ont créé et partiellement responsables de son fonctionnement. Le résultat est des cycles de rétroaction plus efficaces qui aident l'équipe à répondre beaucoup plus rapidement non seulement aux bogues, mais aussi aux nouvelles fonctionnalités et garantissent que le produit se développe dans la bonne direction.
Les outilsNous aimons nos outils! Ils aident l'ingénieur à programmer, assembler, tester, empaqueter, publier, configurer et suivre les systèmes et les applications. Nous possédons magistralement nos outils et connaissons toute la gamme de solutions qui nous intéressent - à la fois open source et commerciale. Avant le développement du paradigme DevOps, l'innovation et les outils étaient en stagnation. J'ai longtemps utilisé les mêmes outils qu'au tout début de ma carrière (je programme depuis 2000). De nombreux outils utilisés dans DevOps sont incroyablement polyvalents et aident à organiser le cycle de vie du service d'une manière complètement nouvelle.
«Toutes sortes d'outils de menuiserie dans l'atelier» de la collection
Barn Images d'
UnsplashVous devez choisir des outils fiables pour DevOps. Il n'y a pas d'outil unique pour toutes les occasions, vous avez besoin d'une gamme complète, dont l'inventaire peut être combiné en tenant compte des besoins existants. Et puisque nous voulons que tout cela fonctionne ensemble ... n'importe quel outil n'est aussi utile qu'il aide notre système tout entier.
Vous devez choisir des outils qui fonctionnent bien avec le reste de votre inventaire. Les outils devraient aider à automatiser tout travail. Ils doivent être faciles à appeler depuis l'API ou depuis la ligne de commande. En principe, les outils qui dépendent fortement de l'interface utilisateur ne s'adaptent pas très bien même dans des outils bien intégrés.
Et ensuite ...Téléchargez l'image docker et commencez à expérimenter. Forkez le code de quelqu'un d'autre et commencez à le construire. Déployez un serveur ou un cluster de serveurs avec Kubernetes. Vous faites donc du DevOps. Démarrez sur votre propre ordinateur, puis accédez au cloud.
«Un garçon debout dans les escaliers et à la recherche des nuages», tourné par Samuel Zeller de UnsplashLorsque vous entendez parler pour la première fois du paradigme de «l'infrastructure en code» ou de la «livraison continue», vous voulez immédiatement dire «non, cela fonctionne différemment avec nous». Cependant, pour réussir avec DevOps, vous devez maîtriser progressivement ces techniques, elles ne sont pas si compliquées. Pendant de nombreuses années, l'industrie a utilisé des méthodes qui sont exactement à l'opposé de DevOps, mais DevOps fonctionne vraiment.