D'une manière ou d'une autre, nous avons mis le client sur un système de gestion électronique de documents à un seul objet. Et puis à un autre objet. Et un de plus. Et les quatrième et cinquième. Ils ont été tellement emportés qu'ils ont atteint 10 objets distribués. Puissant s'est produit ... surtout quand nous sommes arrivés à la livraison des changements. Dans le cadre de l'approvisionnement du circuit de production pour 5 scénarios de système de test, cela a pris 10 heures et 6-7 employés. Ces coûts nous ont obligés à livrer le moins possible. Après trois ans de fonctionnement, nous n'avons pas pu le supporter et avons décidé d'assaisonner le projet avec une pincée de DevOps.
Maintenant, tous les tests passent 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 bien-aimé. D'après notre expérience, DevOps peut aider beaucoup plus de clients que ceux qui le savent même. Par conséquent, pour rapprocher DevOps des personnes, nous avons développé un constructeur simple, dont nous parlerons plus en détail dans cet article.
Maintenant, nous allons dire plus en détail. Dans une entreprise énergétique de 10 grandes installations, un système de gestion des documents techniques est en cours de déploiement. Il n’est pas facile de trouver 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 le travail manuel est semé d’erreurs. D'autre part, il y a des projets où l'installation est une, mais il faut que tout fonctionne automatiquement, en permanence et sans échec - par exemple, les mêmes systèmes de gestion de documents dans les grandes organisations monolithiques. Sinon, quelqu'un effectuera le réglage manuellement, oubliera les instructions de déploiement - et en conséquence, les paramètres seront perdus sur le prod et tout plantera.
Habituellement, nous travaillons avec le client via un contrat, auquel cas nos intérêts divergent un peu. Le client regarde le projet strictement dans le cadre du budget et des savoirs traditionnels. Il peut être difficile de lui expliquer les avantages des différentes pratiques DevOps qui ne font pas partie des savoirs traditionnels. Et s'il s'intéresse aux releases rapides à valeur ajoutée pour l'entreprise, à la construction d'un pipeline d'automatisation?
Hélas, en travaillant avec une valeur pré-approuvée, cet intérêt n'est pas toujours possible à trouver. Dans notre pratique, il y avait un cas où nous devions reprendre le développement pour un entrepreneur sans scrupules et bâclé. C'était une horreur: il n'y a pas de codes source réels, la base de code du même système sur différentes installations est différente, la documentation manquait en partie, en partie d'une qualité terrible. Bien sûr, le client n'avait pas de contrôle de source, d'assemblage, de versions, etc.
Jusqu'à présent, tout le monde ne connaît pas DevOps, mais cela vaut la peine de parler de ses avantages, de la véritable économie de ressources, les yeux s'illuminent pour tous les clients. Il y a donc de plus en plus de demandes impliquant DevOps au fil du temps. Ici, afin de parler facilement la même langue avec les clients, nous devons connecter rapidement les problèmes commerciaux et les pratiques DevOps, ce qui aidera à construire un pipeline de développement approprié.
Donc, nous avons un ensemble de problèmes d'une part, il y a des connaissances, des pratiques et des outils DevOps d'autre part. Pourquoi ne pas partager l'expérience avec tout le monde?
Créer 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
certains tentent de déterminer le degré de maturité des entreprises sur la base d'une évaluation de leurs modes de développement et de fonctionnement.
Heureusement, la célèbre entreprise Gartner a
collecté et analysé en 2014 les principales pratiques DevOps et les relations entre elles. Sur cette base, j'ai publié l'infographie:
Nous l'avons pris comme base de notre
constructeur . Dans chacun des quatre domaines, il existe un ensemble d'outils - nous les avons collectés dans la base de données, identifié les points d'intégration les plus populaires et identifiés et les mécanismes d'optimisation appropriés. Au total,
36 pratiques et 115 outils se sont révélés, dont un quart sont des logiciels libres ou ouverts. Ensuite, nous parlerons de ce que nous avons fait dans chaque domaine et, par exemple, de la façon dont il a été mis en œuvre dans le projet pour créer un flux de travail technique à partir duquel nous avons commencé la publication.
Les processus
Dans le fameux projet EDMS, le système de gestion de la documentation technique a été déployé selon le même schéma dans chacune des 10 installations. L'installation comprend 4 serveurs: un serveur de base de données, un serveur d'applications, l'indexation de texte intégral et la gestion de contenu. Dans l'installation, ils fonctionnent au sein d'un seul nœud, sont situés dans le centre de données des installations. Tous les objets varient légèrement dans l'infrastructure, mais cela n'interfère pas avec l'interaction globale.
Premièrement, selon les pratiques DevOps, nous avons automatisé les infrastructures localement, puis nous avons apporté la livraison au circuit de test, puis à la productivité du client. Chaque processus s'est déroulé étape par étape. Les paramètres d'environnement sont fixés dans le système de code source, en tenant compte du fait que la distribution est collectée pour les mises à jour automatiques. Dans le cas de modifications de la configuration, les ingénieurs doivent simplement apporter les modifications appropriées au système de contrôle de version - puis la mise à jour automatique se passera sans problème.
Grâce à cette approche, le processus de test a été considérablement simplifié. Auparavant, il y avait des testeurs dans le projet qui ne faisaient que mettre à jour manuellement les stands. Maintenant, ils viennent de voir que tout a fonctionné et sont engagés dans des choses plus utiles. Chaque mise à jour est testée automatiquement - du niveau de la surface à l'automatisation du scénario d'entreprise. Les résultats sont présentés sous forme de rapports distincts dans TestRail.
La culture
L'expérimentation continue s'explique mieux par 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, quelles branches passer. Et aussi trouver un équilibre entre le temps et le budget afin de déterminer le nombre optimal de contrôles. Il est important de choisir exactement les tests nécessaires, de considérer comment l'utilisateur va interagir avec le système, de prendre en compte l'environnement et les éventuels facteurs externes. Vous ne pouvez pas vous passer d’expérimentation continue.
Maintenant sur la culture de l'interaction. Il y avait autrefois deux parties belligérantes - ingénieurs et développeurs. Les développeurs ont déclaré:
«Peu importe comment cela commence. Vous êtes des ingénieurs, vous êtes intelligent, faites-le fonctionner sans interruption .
» Les ingénieurs ont répondu:
«Vous, les développeurs, êtes trop téméraires. Soyons plus prudents et nous mettrons vos sorties moins souvent. Parce que chaque fois que vous nous mettez un code troublé, et comment nous interagissons n'est pas clair .
" Il s'agit d'un problème d'interaction culturelle qui, du point de vue de DevOps, est structuré différemment. Ici, vous avez à la fois des ingénieurs et des développeurs qui font partie d'une seule équipe qui vise à changer constamment, mais en même temps un logiciel fiable.
À l'échelle d'une équipe, les spécialistes sont prêts à s'entraider. Comment c'était avant? Par exemple, une sorte de manuel de déploiement épais était en cours de préparation, pages à 50. L'ingénieur l'a lu, n'a pas compris quelque chose, a juré et a demandé au développeur de commenter à trois heures du matin. Le développeur a également commenté et juré - à la fin, personne n'était heureux. De plus, naturellement, il y a eu quelques erreurs, car vous ne vous souviendrez pas de tout dans les instructions. Et maintenant, l'ingénieur et le développeur rédigent un script pour le déploiement automatisé de l'infrastructure logicielle de l'application. Et ils se parlent dans presque la même langue.
Les gens
La taille de l'équipe est déterminée par l'étendue de la mise à jour. L'équipe est recrutée lors de la formation de l'offre, elle comprend ceux qui le souhaitent de l'équipe générale du projet. Ensuite, un plan de mise à jour est rédigé avec la responsabilité de chaque étape, au fur et à mesure de l'exécution de l'équipe, rapporte-t-il. Tous les membres de l'équipe sont interchangeables. En tant que membre de l'équipe, nous avons également un développeur de sécurité, mais il n'a presque jamais à se connecter.
La technologie
Dans le schéma de la technologie, quelques points sont mis en évidence, mais sous eux se trouve un tas de technologies - avec leurs descriptions, vous pouvez publier un livre entier. Nous allons donc mettre en évidence les plus intéressants.
L'infrastructure comme code
Maintenant, probablement, vous ne surprendrez personne avec ce concept, mais avant la description des infrastructures laissait beaucoup à désirer.
Les ingénieurs ont regardé avec horreur les instructions , les environnements de test étaient uniques, ils étaient soignés et chéris, des particules de poussière leur étaient soufflées.
Maintenant, personne n'a peur d'expérimenter. Il existe des images de base de machines virtuelles, il existe des scénarios prêts à l'emploi pour le déploiement d'environnements. Tous les modèles et scripts sont stockés dans le système de contrôle de version et sont mis à jour rapidement. Auparavant, lorsqu'il était nécessaire de livrer un package sur un stand, une lacune de configuration apparaissait. Il ne vous reste plus qu'à ajouter une ligne dans le code source.
Outre les scénarios d'infrastructure et les pipelines, 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 introduire dans le système par les fonctions décrites, par exemple, dans le plan de test, et également de réutiliser des cas de test.
Livraison et surveillance continues
Dans notre dernier article sur DevOps, nous avons expliqué comment nous avons choisi des outils pour implémenter 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écédemment é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 démarrés avec un seul bouton ou programme.
Il existe différents concepts en anglais, la livraison continue et le déploiement continu. Les deux peuvent être traduits par «livraison continue», mais en fait il y a une légère différence entre eux. Dans notre projet de gestion des documents techniques d'une entreprise d'énergie distribuée, la livraison est plutôt utilisée lorsque l'installation pour la vente est effectuée sur commande. Dans le déploiement, l'installation est automatique. La livraison continue dans ce projet est généralement devenue un
élément central de DevOps .
En général, en collectant certains paramètres, vous pouvez clairement comprendre pourquoi les pratiques DevOps sont utiles. Et à transmettre à la direction, qui aime beaucoup les chiffres. Le nombre total de lancements, le temps d'exécution des étapes du script, la part des lancements réussis - tout cela affecte directement le délai de mise sur le marché préféré de tous, c'est-à-dire le temps entre la validation du système de contrôle de version et la sortie de la version sur un environnement productif. Avec l'introduction des outils nécessaires, les ingénieurs reçoivent par courrier des indicateurs précieux et le chef de projet les voit sur un tableau de bord. Ainsi, vous pouvez immédiatement apprécier les avantages des nouveaux outils. Et vous pouvez les essayer sur votre infrastructure à l'aide du constructeur DevOps.
Nous ne tricherons pas: pour commencer, il nous est devenu utile. Comme nous l'avons déjà dit, le client doit parler le même langage, et avec l'aide du constructeur DevOps, nous pouvons rapidement définir les bases d'une telle conversation. Les professionnels pourront évaluer eux-mêmes ce dont ils ont besoin et ainsi se développer plus rapidement. Nous avons essayé de rendre le constructeur aussi détaillé que possible, avons ajouté un tas de descriptions pour que tout utilisateur comprenne ce qu'il choisit.
Le format du concepteur vous permet de prendre en compte l'expérience existante de l'entreprise dans les processus de construction et l'automatisation. Vous n'avez pas à tout décomposer et reconstruire si vous ne pouvez choisir que des solutions qui s'intègrent normalement dans les 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 le
lien vers le constructeur - vous obtenez le circuit immédiatement après avoir entré les données source. Nous serons reconnaissants pour les commentaires et ajouts.