Image:
Salut tout le monde! Nous sommes des ingénieurs en automatisation de l'entreprise et nous accompagnons le développement des produits de l'entreprise : nous accompagnons l'ensemble du pipeline d'assemblage depuis la validation d'une ligne de code par les développeurs jusqu'à la publication des produits finis et des licences sur les serveurs de mise à jour. De manière informelle, nous sommes appelés ingénieurs DevOps. Dans cet article, nous souhaitons parler des étapes technologiques du processus de production de logiciels, de la façon dont nous les voyons et comment nous les classons.
À partir du matériel, vous découvrirez la complexité de la coordination du développement multi-produits, ce qu'est une carte technologique et comment elle aide à rationaliser et à reproduire les solutions, quelles sont les principales étapes et étapes du processus de développement, comment sont les domaines de responsabilité. entre DevOps et les équipes de notre entreprise.
À propos du chaos et du DevOps
En bref, le concept DevOps comprend des outils et services de développement, ainsi que des méthodologies et des bonnes pratiques pour leur utilisation. Distinguons le monde objectif de la mise en œuvre des idées DevOps dans notre entreprise : il s'agit d'une réduction constante du coût de production et de maintenance des produits en termes quantitatifs (heures-homme ou heures machine, CPU, RAM, Disque, etc.). Le moyen le plus simple et le plus évident de réduire le coût global de développement au niveau de l'ensemble de l'entreprise est minimiser le coût d'exécution des tâches en série typiques à toutes les étapes de la production. Mais quelles sont ces étapes, comment les séparer du processus général, en quoi consistent-elles ?
Lorsqu'une entreprise développe un produit, tout est plus ou moins clair : il existe généralement une feuille de route et un schéma de développement communs. Mais que faire lorsque la gamme de produits s’agrandit et qu’il y a plus de produits ? À première vue, ils ont des processus et des chaînes d'assemblage similaires, et le jeu « trouver X différences » dans les journaux et les scripts commence. Mais que se passe-t-il s'il y a déjà plus de 5 projets en développement actif et que la prise en charge de plusieurs versions développées sur plusieurs années est requise ? Voulons-nous réutiliser le maximum de solutions possibles dans les pipelines de produits ou sommes-nous prêts à dépenser de l'argent pour un développement unique pour chacune ?
Comment trouver un équilibre entre unicité et solutions sérielles ?
Ces questions ont commencé à se poser de plus en plus souvent depuis 2015. Le nombre de produits a augmenté et nous avons essayé d'étendre au minimum notre service d'automatisation (DevOps), qui soutenait les lignes d'assemblage de ces produits. En même temps, nous souhaitions reproduire autant de solutions que possible entre les produits. Après tout, pourquoi faire la même chose dans dix produits de différentes manières ?
Directeur du développement: « Les gars, pouvons-nous évaluer d'une manière ou d'une autre ce que DevOps fait pour les produits ?
Nous: "On ne sait pas, on ne s'est pas posé une telle question, mais quels indicateurs faut-il considérer ?"
Directeur du développement: "Qui sait! Pense…"
Comme dans ce fameux film : "Je suis dans un hôtel !.." - "Euh... Tu peux me montrer le chemin ?" Après réflexion, nous sommes arrivés à la conclusion qu'il fallait d'abord décider de l'état final des produits ; c'est devenu notre premier objectif.
Alors, comment analyser une douzaine de produits avec des équipes assez importantes de 10 à 200 personnes et déterminer des métriques mesurables lors de la réplication des solutions ?
1:0 en faveur du Chaos, ou du DevOps sur les omoplates
Nous avons commencé par tenter d'appliquer les diagrammes IDEF0 et divers diagrammes de processus métier de la série BPwin. La confusion a commencé après le cinquième carré de l'étape suivante du projet suivant, et ces carrés pour chaque projet peuvent être dessinés dans la queue d'un long python en plus de 50 étapes. Je me sentais triste et j'avais envie de hurler à la lune - ça ne me convenait pas du tout.
Tâches de production typiques
La modélisation des processus de production est un travail très complexe et minutieux : vous devez collecter, traiter et analyser de nombreuses données provenant de différents départements et chaînes de production. Vous pouvez en savoir plus à ce sujet dans l'article "».
Lorsque nous avons commencé à modéliser notre processus de production, nous avions un objectif précis : transmettre à chaque employé impliqué dans le développement des produits de notre entreprise et aux chefs de projet :
- comment les produits et leurs composants, à partir de la validation d'une ligne de code, parviennent au client sous forme d'installateurs et de mises à jour,
- quelles ressources sont fournies pour chaque étape de production des produits,
- quels services sont impliqués à chaque étape,
- comment sont délimités les domaines de responsabilité de chaque étape,
- quels contrats existent à l'entrée et à la sortie de chaque étape.
En cliquant sur l'image, vous l'ouvrirez en taille réelle.
Notre travail dans l'entreprise est divisé en plusieurs domaines fonctionnels. La direction de l'infrastructure s'occupe de l'optimisation du fonctionnement de toutes les ressources « fer » du département, ainsi que de l'automatisation du déploiement des machines virtuelles et de l'environnement sur celles-ci. La direction de surveillance assure un contrôle des performances du service 24h/7 et XNUMXj/XNUMX ; nous fournissons également une surveillance en tant que service aux développeurs. La direction du flux de travail fournit aux équipes des outils pour gérer les processus de développement et de test, analyser l'état du code et obtenir des analyses sur les projets. Et enfin, la direction webdev assure la publication des releases sur les serveurs de mise à jour GUS et FLUS, ainsi que la licence des produits utilisant le service LicenseLab. Pour soutenir le pipeline de production, nous avons mis en place et maintenons de nombreux services de support différents pour les développeurs (vous pouvez écouter des histoires sur certains d'entre eux sur d'anciennes rencontres : и). Nous développons également des outils d'automatisation internes, notamment .
Au cours des cinq dernières années, notre travail a accumulé de nombreuses opérations du même type et de routine, et nos développeurs d'autres départements viennent principalement de ce qu'on appelle tâches typiques, dont la solution est entièrement ou partiellement automatisée, ne pose pas de difficultés aux artistes et ne nécessite pas de travail important. En collaboration avec les principaux domaines, nous avons analysé ces tâches et avons pu identifier des catégories de travail individuelles, ou étapes de production, les étapes ont été divisées en étapes indivisibles, et plusieurs étapes s'additionnent chaîne de processus de production.
L'exemple le plus simple de chaîne technologique sont les étapes d'assemblage, de déploiement et de test de chacun de nos produits au sein de l'entreprise. À son tour, par exemple, la phase de construction se compose de nombreuses étapes typiques distinctes : téléchargement de sources depuis GitLab, préparation des dépendances et des bibliothèques tierces, tests unitaires et analyse de code statique, exécution d'un script de construction sur GitLab CI, publication d'artefacts dans le référentiel sur Artifactory et génération de notes de version via notre outil interne ChangelogBuilder.
Vous pouvez en savoir plus sur les tâches DevOps typiques dans nos autres articles sur Habré : ""Et"».
De nombreuses chaînes de production typiques se forment processus de fabrication. L'approche standard pour décrire les processus consiste à utiliser des modèles fonctionnels IDEF0.
Un exemple de modélisation d'un processus CI de fabrication
Nous avons accordé une attention particulière au développement de projets standards pour un système d'intégration continue. Cela a permis de parvenir à l'unification des projets, en mettant en évidence ce que l'on appelle schéma de build de version avec promotions.
Voici comment cela fonctionne. Tous les projets semblent typiques : ils incluent la configuration des assemblys qui tombent dans le référentiel d'instantanés d'Artifactory, après quoi ils sont déployés et testés sur des bancs de test, puis promus vers le référentiel de versions. Le service Artifactory est un point de distribution unique pour tous les artefacts de build entre les équipes et les autres services.
Si nous simplifions et généralisons considérablement notre schéma de publication, il comprend alors les étapes suivantes :
- assemblage de produits multiplateformes,
- déployer sur des bancs de tests,
- exécuter des tests fonctionnels et autres,
- promouvoir les versions testées pour publier des référentiels sur Artifactory,
- publication des release builds sur les serveurs de mise à jour,
- livraison des assemblages et mises à jour en production,
- lancer l'installation et la mise à jour du produit.
Par exemple, considérons le modèle technologique de ce schéma de version typique (ci-après simplement Modèle) sous la forme d'un modèle IDEF0 fonctionnel. Il reflète les principales étapes de notre processus CI. Les modèles IDEF0 utilisent ce qu'on appelle Notation ICOM (Input-Control-Output-Mechanism) pour décrire quelles ressources sont utilisées à chaque étape, en fonction des règles et exigences du travail effectué, quel est le résultat et quels mécanismes, services ou personnes mettent en œuvre une étape particulière.
En cliquant sur l'image, vous l'ouvrirez en taille réelle.
En règle générale, il est plus facile de décomposer et de détailler la description des processus dans des modèles fonctionnels. Mais à mesure que le nombre d'éléments augmente, il devient de plus en plus difficile d'y comprendre quelque chose. Mais dans le développement réel, il y a aussi des étapes auxiliaires : surveillance, certification des produits, automatisation des processus de travail, etc. C'est à cause du problème d'échelle que nous avons abandonné cette description.
Naissance de l'espoir
Dans un livre, nous sommes tombés sur d’anciennes cartes soviétiques décrivant des processus technologiques (qui sont d’ailleurs encore utilisés aujourd’hui dans de nombreuses entreprises publiques et universités). Attendez, attendez, car nous avons aussi un workflow !.. Il y a des étapes, des résultats, des mesures, des exigences, des indicateurs, etc.… Pourquoi ne pas essayer d'appliquer également des schémas de flux à nos pipelines de produits ? Il y avait un sentiment : « Ça y est ! Nous avons trouvé le bon fil, il est temps de bien le tirer !
Dans un tableau simple, nous avons décidé d'enregistrer les produits par colonnes, et les étapes technologiques et les étapes du pipeline de produits par lignes. Les jalons sont quelque chose de grand, comme une étape de création de produit. Et les étapes sont quelque chose de plus petit et de plus détaillé, comme l'étape de téléchargement du code source sur le serveur de build ou l'étape de compilation du code.
Aux intersections des lignes et des colonnes de la carte, nous inscrivons les statuts d'une étape et d'un produit spécifiques. Pour les statuts, un ensemble d'états a été défini :
- Aucune information - ou inapproprié. Il est nécessaire d'analyser la demande pour une étape du produit. Soit l’analyse a déjà été réalisée, mais cette étape n’est actuellement pas nécessaire, soit elle n’est pas économiquement justifiée.
- Reporté - ou pas pertinent pour le moment. Une étape est nécessaire, mais il n’y a aucune force pour la mise en œuvre cette année.
- Programmé. La mise en œuvre de l'étape est prévue cette année.
- Mis en œuvre. L'étape du pipeline est réalisée dans le volume requis.
Le remplissage du tableau a commencé projet par projet. Tout d'abord, les étapes et étapes d'un projet ont été classées et leurs statuts ont été enregistrés. Ensuite, ils ont pris le projet suivant, y ont corrigé les statuts et ont ajouté les étapes et les étapes qui manquaient dans les projets précédents. En conséquence, nous avons obtenu les étapes et les étapes de l'ensemble de notre pipeline de production et leurs statuts dans un projet spécifique. Il s'est avéré quelque chose de similaire à la matrice de compétences du pipeline de produits. Nous avons appelé une telle matrice une carte technologique.
A l'aide de la carte technologique, nous coordonnons métrologiquement raisonnablement avec les équipes les plans de travail de l'année et les objectifs que nous souhaitons atteindre ensemble : quelles étapes nous ajoutons au projet cette année, et lesquelles nous laissons pour plus tard. Aussi, au cours des travaux, nous pouvons avoir des améliorations dans les étapes que nous avons complétées pour un seul produit. Ensuite, nous élargissons notre carte et introduisons cette amélioration comme une étape ou une nouvelle étape, puis nous analysons pour chaque produit et découvrons la faisabilité de reproduire l'amélioration.
Ils peuvent nous objecter : « Tout cela est bien sûr bien, mais avec le temps, le nombre d'étapes et d'étapes deviendra prohibitif. Comment être?
Nous avons mis en place des descriptions standards et assez complètes des exigences pour chaque étape et étape, afin qu'elles soient comprises de la même manière par tous au sein de l'entreprise. Au fil du temps, à mesure que des améliorations sont introduites, une étape peut être absorbée dans une autre étape ou étape, puis elles « s'effondreront ». Dans le même temps, toutes les exigences et nuances technologiques s'intègrent dans les exigences de l'étape ou de l'étape de généralisation.
Comment évaluer l’effet des solutions de réplication ? Nous utilisons une approche extrêmement simple : nous attribuons les coûts d'investissement initiaux pour la mise en œuvre d'une nouvelle étape aux coûts généraux annuels du produit, puis nous divisons par le tout lors de la réplication.
Certaines parties du développement sont déjà indiquées sous forme de jalons et d'étapes sur la carte. Nous pouvons influencer la réduction du coût du produit grâce à l’introduction de l’automatisation des étapes typiques. Après cela, nous considérons l'évolution des caractéristiques qualitatives, des mesures quantitatives et le profit perçu par les équipes (en heures-homme ou heures-machine d'économies).
Carte technologique du processus de production
Si nous prenons toutes nos étapes et étapes, les encodons avec des balises et les développons en une seule chaîne, cela s'avérera très long et incompréhensible (juste la même « queue de python » dont nous avons parlé au début de l'article) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Il s'agit des étapes de création de produits [Build], de leur déploiement sur des serveurs de test [Deploy], de test [Test], de promotion des builds pour publier des référentiels basés sur les résultats des tests [Promote], de génération et de publication de licences [License], de publication [ Publier] sur le serveur de mise à jour GUS et livraison aux serveurs de mise à jour FLUS, installation et mise à jour des composants du produit sur l'infrastructure du client à l'aide de Product Configuration Management [Installer], ainsi que collecte de télémétrie [Télémétrie] des produits installés.
En plus d'eux, on peut distinguer des étapes distinctes : surveillance de l'état de l'infrastructure [InfMonitoring], versionnage du code source [SourceCodeControl], préparation de l'environnement de build [Prepare], gestion de projet [Workflow], mise à disposition des équipes d'outils de communication [Communication], certification des produits [ Certification] et assurer l'autosuffisance des processus CI [CISelfSufficiency] (par exemple, indépendance des assemblées par rapport à Internet). Des dizaines d’étapes de nos processus ne seront même pas prises en compte, car elles sont très spécifiques.
Il sera beaucoup plus facile de comprendre et de visualiser l'ensemble du processus de production s'il est présenté sous la forme carte technologique; il s'agit d'un tableau dans lequel les étapes de production individuelles et les étapes décomposées du modèle sont écrites en lignes et en colonnes une description de ce qui est fait à chaque étape ou étape. L'accent principal est mis sur les ressources qu'apporte chaque étape, et sur la délimitation des domaines de responsabilité.
La carte est pour nous une sorte de classificateur. Il reflète les larges pans technologiques de la production des produits. Grâce à cela, il est devenu plus facile pour notre équipe d'automatisation d'interagir avec les développeurs et de planifier conjointement la mise en œuvre des étapes d'automatisation, ainsi que de comprendre quels coûts de main-d'œuvre et quelles ressources (humaines et matérielles) seront nécessaires pour cela.
Au sein de notre entreprise, la carte est automatiquement générée à partir du modèle jinja sous forme de fichier HTML standard, puis téléchargée sur le serveur GitLab Pages. Une capture d'écran avec un exemple de carte entièrement générée peut être visualisée .
En cliquant sur l'image, vous l'ouvrirez en taille réelle.
En bref, la carte technologique est une image généralisée du processus de production, qui reflète des blocs clairement classés dotés de fonctionnalités typiques.
Structure de notre feuille de route
La carte se compose de plusieurs parties :
- Zone de titre - voici une description générale de la carte, les concepts de base sont introduits, les principales ressources et résultats du processus de production sont définis.
- Tableau de bord - ici, vous pouvez contrôler l'affichage des données pour des produits individuels, un résumé des étapes mises en œuvre et des étapes en général pour tous les produits est fourni.
- Carte technologique - une description tabulaire du processus technologique. Sur la carte:
- toutes les étapes, étapes et leurs codes sont donnés ;
- des descriptions courtes et complètes des étapes sont données ;
- les ressources d'entrée et les services utilisés à chaque étape sont indiqués ;
- les résultats de chaque étape et d'une étape distincte sont indiqués ;
- le domaine de responsabilité pour chaque étape et étape est indiqué ;
- les ressources techniques, telles que le disque dur (SSD), la RAM, le vCPU et les heures de travail nécessaires pour soutenir le travail à ce stade, tant au moment présent - un fait, qu'à l'avenir - un plan, ont été déterminées ;
- pour chaque produit, il est indiqué quelles étapes ou étapes technologiques ont été mises en œuvre, prévues pour la mise en œuvre, non pertinentes ou non mises en œuvre.
Prise de décision basée sur la carte technologique
Après avoir examiné la carte, il est possible d'entreprendre certaines actions - en fonction du rôle du salarié dans l'entreprise (responsable de développement, chef de produit, développeur ou testeur) :
- comprendre quelles étapes manquent dans un produit ou un projet réel et évaluer la nécessité de leur mise en œuvre ;
- délimiter les domaines de responsabilité entre plusieurs services s'ils travaillent sur des étapes différentes ;
- convenir des contrats aux entrées et sorties des scènes ;
- intégrer votre étape de travail dans le processus de développement global ;
- évaluer plus précisément le besoin de ressources qui assurent chacune des étapes.
Résumant tout ce qui précède
Le routage est polyvalent, extensible et facile à entretenir. Il est beaucoup plus facile de développer et de maintenir une description des processus sous cette forme que dans un modèle académique IDEF0 strict. De plus, une description tabulaire est plus simple, plus familière et mieux structurée qu’un modèle fonctionnel.
Pour la mise en œuvre technique des étapes, nous disposons d'un outil interne spécial CrossBuilder - un outil de couche entre les systèmes, services et infrastructures CI. Le développeur n'a pas besoin de couper son vélo : dans notre système CI, il suffit d'exécuter l'un des scripts (la soi-disant tâche) de l'outil CrossBuilder, qui l'exécutera correctement, en tenant compte des fonctionnalités de notre infrastructure. .
Les résultats de
L'article s'est avéré assez long, mais cela est inévitable lorsqu'on décrit la modélisation de processus complexes. En fin de compte, je voudrais résumer brièvement nos idées principales :
- L'objectif de la mise en œuvre des idées DevOps dans notre entreprise est de réduire systématiquement les coûts de production et de maintenance des produits de l'entreprise en termes quantitatifs (heures-homme ou heures machine, vCPU, RAM, disque).
- Le moyen de réduire le coût global de développement est de minimiser le coût d'exécution des tâches en série typiques : étapes et étapes du processus technologique.
- Une tâche typique est une tâche dont la solution est entièrement ou partiellement automatisée, ne pose pas de difficultés aux artistes interprètes et ne nécessite pas de coûts de main-d'œuvre importants.
- Le processus de production se compose d'étapes, les étapes sont divisées en étapes indivisibles, qui sont des tâches typiques d'échelle et de portée différentes.
- De tâches typiques disparates, nous sommes arrivés à des chaînes technologiques complexes et à des modèles multi-niveaux du processus de production, qui peuvent être décrits par un modèle fonctionnel IDEF0 ou une carte technologique plus simple.
- La carte technologique est une représentation tabulaire des étapes et des étapes du processus de production. Le plus important : la carte permet de voir tout le processus dans son intégralité, en gros morceaux avec la possibilité de les détailler.
- Sur la base de la carte technologique, il est possible d'évaluer la nécessité d'introduire des étapes dans un produit particulier, de délimiter les domaines de responsabilité, de convenir de contrats aux entrées et sorties des étapes et d'évaluer plus précisément les besoins en ressources.
Dans les articles suivants, nous décrirons plus en détail quels outils techniques sont utilisés pour mettre en œuvre certaines étapes technologiques sur notre carte.
Auteurs des articles :
- — Responsable de l'automatisation (DevOps) chez Positive Technologies
- - Adjoint Chef du département d'automatisation (DevOps) chez Positive Technologies
Source: habr.com