Nous avons déjà fourni un système de gestion électronique de documents à un client dans un établissement. Et puis vers un autre objet. Et un de plus. Et le quatrième et le cinquième. Nous nous sommes tellement emportés que nous avons atteint 10 objets distribués. Cela s’est avéré puissant… surtout lorsque nous avons commencé à apporter les changements. Dans le cadre de la livraison sur le circuit de production, 5 scénarios du système de tests ont finalement nécessité 10 heures et 6 à 7 collaborateurs. De tels coûts nous obligeaient à effectuer des livraisons aussi rares que possible. Après trois ans de fonctionnement, nous n’en avons plus supporté et avons décidé de pimenter le projet avec une pincée de DevOps.
Désormais, tous les tests se déroulent en 3 heures, et 3 personnes y participent : un ingénieur et deux testeurs. Les améliorations sont clairement exprimées en chiffres et conduisent à une réduction du TTM tant apprécié. D’après notre expérience, il y a beaucoup plus de clients qui peuvent bénéficier du DevOps que ceux qui le connaissent. Par conséquent, pour rapprocher DevOps des gens, nous avons développé un constructeur simple, dont nous parlerons plus en détail dans cet article.
Maintenant, laissez-nous vous le dire plus en détail. Une entreprise énergétique déploie un système de gestion des documents techniques dans 10 grandes installations. Il n'est pas facile de gérer des projets de cette envergure sans DevOps, car une grande partie du travail manuel retarde considérablement le travail et réduit également la qualité - tout travail manuel est semé d'erreurs. D'un autre côté, il existe des projets où il n'y a qu'une seule installation, mais où tout doit fonctionner automatiquement, constamment et sans panne - par exemple, les mêmes systèmes de flux de documents dans les grandes organisations monolithiques. Sinon, quelqu'un effectuera les réglages manuellement, oubliera les instructions de déploiement - et par conséquent, en production, les paramètres seront perdus et tout s'effondrera.
Habituellement, nous travaillons avec le client dans le cadre d'un contrat et, dans ce cas, nos intérêts divergent légèrement. Le client examine le projet strictement dans le cadre du budget et des spécifications techniques. Il peut être difficile de lui expliquer les bénéfices des différentes pratiques DevOps qui ne sont pas incluses dans les spécifications techniques. Que se passe-t-il s'il est intéressé par des versions rapides avec une valeur commerciale ajoutée ou par la création d'un pipeline d'automatisation ?
Hélas, lorsqu’on travaille avec un coût pré-approuvé, cet intérêt n’est pas toujours trouvé. Dans notre pratique, il y a eu un cas où nous avons dû reprendre le développement d'un entrepreneur sans scrupules et imprudent. C'était terrible : il n'y avait pas de codes sources à jour, la base de code d'un même système était différente selon les installations, la documentation était en partie absente et en partie de qualité épouvantable. Bien entendu, le client n’avait aucun contrôle sur le code source, l’assemblage, les versions, etc.
Jusqu'à présent, tout le monde ne connaît pas DevOps, mais dès que l'on parle de ses avantages, de réelles économies de ressources, les yeux de tous les clients s'illuminent. Ainsi, le nombre de requêtes incluant DevOps augmente avec le temps. Ici, afin de parler facilement le même langage avec les clients, nous devons connecter rapidement les problèmes commerciaux et les pratiques DevOps qui aideront à construire un pipeline de développement adapté.
Nous avons donc d’un côté un ensemble de problématiques, de l’autre des connaissances, des pratiques et des outils DevOps. Pourquoi ne pas partager l'expérience avec tout le monde ?
Création d'un constructeur DevOps
Agile a son propre manifeste. ITIL a sa propre méthodologie. DevOps a moins de chance : il n'a pas encore acquis de modèles et de normes. Bien que déterminer la maturité des entreprises à partir d’une évaluation de leur développement et de leurs pratiques opérationnelles.
Heureusement, la célèbre société Gartner en 2014 et analysé les pratiques DevOps clés et les relations entre elles. Sur cette base, j'ai publié une infographie :
Nous l'avons pris comme base de notre . Chacun des quatre domaines dispose d'un ensemble d'outils - nous les avons rassemblés dans une base de données, identifié les plus populaires, identifié les points d'intégration et les mécanismes d'optimisation appropriés. Au total, il s'est avéré 36 pratiques et 115 outils, dont un quart sont des logiciels open source ou libres. Ensuite, nous parlerons de ce que nous avons réalisé dans chaque domaine et, à titre d'exemple, de la manière dont cela a été mis en œuvre dans le projet de création de gestion de documents techniques, avec lequel nous avons commencé le message.
Processus
Dans le célèbre projet EDMS, le système de gestion de la documentation technique a été déployé selon le même schéma sur chacun des 10 objets. L'installation comprend 4 serveurs : serveur de base de données, serveur d'applications, indexation de texte intégral et gestion de contenu. Dans l'installation, ils fonctionnent au sein d'un seul nœud et sont situés dans le centre de données des installations. Tous les objets diffèrent légèrement en termes d'infrastructure, mais cela n'interfère pas avec l'interaction globale.
D’abord, selon les pratiques DevOps, nous avons automatisé l’infrastructure localement, puis nous avons amené la livraison au circuit de test, puis au produit du client. Chaque processus a été élaboré étape par étape. Les paramètres d'environnement sont fixés dans le système de code source, en tenant compte du fait que le kit de distribution est compilé pour une mise à jour automatique. En cas de modification de la configuration, les ingénieurs doivent simplement apporter les modifications appropriées au système de contrôle de version - et la mise à jour automatique s'effectuera alors sans problème.
Grâce à cette approche, le processus de test a été grandement simplifié. Auparavant, le projet comptait des testeurs qui ne faisaient que mettre à jour manuellement les stands. Maintenant, ils viennent voir que tout fonctionne et font des choses plus utiles. Chaque mise à jour est testée automatiquement, du niveau superficiel à l'automatisation des scénarios métier. Les résultats sont publiés sous forme de rapports distincts dans TestRail.
Culture
L'expérimentation continue est mieux expliquée à travers l'exemple de la conception des tests. Tester un système qui n'existe pas encore est un travail créatif. Lors de la rédaction d'un plan de test, vous devez comprendre comment tester correctement et quelles branches suivre. Et trouvez également un équilibre entre temps et budget pour déterminer le nombre optimal de contrôles. Il est important de choisir exactement les tests nécessaires, de réfléchir à la manière dont l'utilisateur va interagir avec le système, de prendre en compte l'environnement et les éventuels facteurs externes. Il est impossible de se passer d’expérimentations continues.
Parlons maintenant de la culture de l’interaction. Auparavant, il y avait deux camps opposés : les ingénieurs et les développeurs. Les développeurs ont déclaré : « Nous ne nous soucions pas de la manière dont il sera lancé. Vous êtes ingénieurs, vous êtes intelligents, assurez-vous qu'il fonctionne sans pannes". Les ingénieurs ont répondu : « Vous, les développeurs, êtes trop négligents. Soyons plus prudents et nous jouerons vos sorties moins souvent. Parce que chaque fois que vous nous fournissez un code qui fuit, nous ne savons pas comment interagir.. Il s’agit d’une question d’interaction culturelle structurée différemment du point de vue DevOps. Ici, les ingénieurs et les développeurs font partie d'une seule équipe qui se concentre sur des logiciels en constante évolution, mais en même temps fiables.
Au sein d’une même équipe, des spécialistes sont déterminés à s’entraider. Comme avant ? Par exemple, de grosses instructions de déploiement étaient en préparation, d'environ 50 pages. L'ingénieur l'a lu, n'a pas compris quelque chose, a juré et a demandé au développeur à trois heures du matin de commenter. Le développeur a commenté et maudit également - à la fin, personne n'était content. De plus, bien sûr, il y a eu quelques erreurs, car on ne se souvient pas de tout dans les instructions. Et maintenant, l'ingénieur, en collaboration avec le développeur, écrit un script pour le déploiement automatisé de l'infrastructure logicielle d'application. Et ils se parlent pratiquement dans la même langue.
personnes
La taille de l'équipe est déterminée par la portée de la mise à jour. L'équipe est recrutée lors de la constitution de la livraison, elle comprend les personnes intéressées de l'équipe générale du projet. Ensuite, un plan de mise à jour est rédigé avec les responsables de chaque étape, et l'équipe rend compte de son avancement. Tous les membres de l'équipe sont interchangeables. Au sein de l'équipe, nous avons également un développeur suppléant, mais il n'a presque jamais besoin de se connecter.
de la technologie
Dans le diagramme technologique, quelques points sont mis en évidence, mais en dessous se trouvent un tas de technologies - vous pourriez publier un livre entier avec leurs descriptions. Nous allons donc souligner les plus intéressants.
L'infrastructure comme code
Maintenant, probablement, ce concept ne surprendra personne, mais auparavant les descriptions des infrastructures laissaient beaucoup à désirer. , les environnements de test étaient uniques, ils étaient chéris et chéris, des particules de poussière en étaient soufflées.
Aujourd’hui, personne n’a peur d’expérimenter. Il existe des images de base de machines virtuelles et des scénarios prêts à l'emploi pour déployer des environnements. Tous les modèles et scripts sont stockés dans un système de contrôle de version et sont rapidement mis à jour. Auparavant, lorsqu'il fallait livrer un colis sur un stand, un écart de configuration apparaissait. Il ne vous reste plus qu'à ajouter une ligne au code source.
En plus des scripts et des pipelines d'infrastructure, l'approche Documentation as a Code est également utilisée pour la documentation. Grâce à cela, il est facile de connecter de nouvelles personnes au projet, de les présenter au système en fonction des fonctions décrites, par exemple, dans le plan de test, et également de réutiliser les cas de test.
Livraison et suivi continus
à propos de DevOps, nous avons expliqué comment nous avons sélectionné les outils pour mettre en œuvre la livraison et la surveillance continues. Souvent, il n'est pas nécessaire de réécrire quoi que ce soit - il suffit d'utiliser des scripts préalablement écrits, de construire correctement l'intégration entre les composants et de créer une console de gestion commune. Et tous les processus peuvent être lancés à l'aide d'un seul bouton ou d'un seul calendrier.
En anglais, il existe différents concepts, livraison continue et déploiement continu. Les deux peuvent être traduits par « livraison continue », mais il existe en fait une légère différence entre eux. Dans notre projet pour le flux de documents techniques d'une entreprise d'énergie distribuée, la livraison est plutôt utilisée - lorsque l'installation pour la production a lieu sur commande. Lors du déploiement, l'installation s'effectue automatiquement. La livraison continue dans ce projet est généralement devenue élément central du DevOps.
De manière générale, en collectant certains paramètres, vous pouvez clairement comprendre pourquoi les pratiques DevOps sont utiles. Et transmettez-le à la direction, qui aime vraiment les chiffres. Le nombre total de lancements, le temps d'exécution des étapes de script, la part des lancements réussis - tout cela affecte directement le délai de mise sur le marché préféré de chacun, c'est-à-dire le temps écoulé entre un engagement dans le système de contrôle de version et la sortie d'une version sur un environnement de production. Avec la mise en place des outils nécessaires, les ingénieurs reçoivent par mail de précieux indicateurs, et le chef de projet les voit sur le tableau de bord. De cette façon, vous pouvez évaluer immédiatement les avantages des nouveaux outils. Et vous pouvez les essayer sur votre infrastructure à l'aide du concepteur DevOps.
Qui aura besoin de notre ?
Ne faisons pas semblant : pour commencer, il nous est devenu utile. Comme nous l'avons déjà dit, il faut parler le même langage avec le client, et avec l'aide du concepteur DevOps, nous pouvons rapidement esquisser les bases d'une telle conversation. Les spécialistes métiers pourront évaluer eux-mêmes ce dont ils ont besoin et ainsi se développer plus rapidement. Nous avons essayé de rendre le concepteur aussi détaillé que possible, en ajoutant un tas de descriptions afin que tout utilisateur comprenne ce qu'il choisit.
Le format du concepteur vous permet de prendre en compte les développements existants de l’entreprise en matière de processus de construction et d’automatisation. Il n’est pas nécessaire de tout démolir et de tout reconstruire si vous ne pouvez choisir que des solutions qui s’intègrent bien aux processus existants et qui peuvent simplement combler les lacunes.
Peut-être que votre développement est déjà passé à un niveau supérieur et que notre outil vous semblera trop « capitaine ». Mais nous le trouvons utile pour nous-mêmes et espérons qu'il sera utile à certains lecteurs. Nous vous rappelons au concepteur - au contraire, vous recevez le diagramme immédiatement après avoir saisi les données initiales. Nous serons reconnaissants pour vos commentaires et ajouts.
Source: habr.com