Gestion du chaos: nettoyer avec le routage

Image: Unsplash

Bonjour à tous! Nous sommes des ingénieurs en automatisation de Positive Technologies et nous soutenons le développement des produits de l'entreprise: nous prenons en charge toute la chaîne d'assemblage, des développeurs engageant une ligne de code à la publication des produits finis et des licences sur des serveurs de mise à jour. De manière informelle, nous sommes appelés ingénieurs DevOps. Dans cet article, nous voulons 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 apprendrez la complexité de la coordination du développement multi-produits, ce qu'est un flux de travail et comment il aide à organiser et à reproduire des solutions, quelles sont les principales étapes et étapes du processus de développement, comment les responsabilités sont réparties entre DevOps et les équipes de notre entreprise.

À propos du chaos et du DevOps

Notez brièvement que le concept de DevOps comprend des outils et des services de développement, ainsi que des méthodologies et des meilleures pratiques pour leur utilisation. Nous distinguerons l' objectif global de l'introduction 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 total de développement au niveau de l'entreprise est de minimiser le coût de l'exécution de tâches série typiques à toutes les étapes de la production. Mais quelles sont ces étapes, comment les distinguer du processus général, en quoi consistent-elles?

Lorsqu'une entreprise développe un seul 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'élargit et qu'il y a plus de produits? À première vue, ils ont des processus et des chaînes de montage similaires et le jeu "trouve les différences X" dans les journaux et les scripts commence. Et s'il y a déjà plus de 5 projets en développement actif et que vous avez besoin d'un support pour plusieurs versions développées sur plusieurs années? Voulons-nous réutiliser le plus grand nombre possible de solutions dans les convoyeurs de produits ou sommes-nous prêts à dépenser de l'argent pour un développement unique pour chacune?

Comment trouver un équilibre entre l'unicité et la sérialité des solutions?

Ces problèmes ont commencé à se poser devant nous plus souvent depuis 2015. Le nombre de produits a augmenté et nous avons essayé de minimiser l'expansion de notre département d'automatisation (DevOps), qui a soutenu les chaînes de montage de ces produits. En même temps, je souhaitais reproduire le plus de solutions 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 en quelque sorte évaluer ce que DevOps fait pour les produits?»

Nous : "Nous ne savons pas, nous ne nous sommes pas posé une telle question, mais quels indicateurs faut-il considérer?"

Directeur du développement : «Et qui sait! Pensez ... "

Comme dans le célèbre film: "À mon hôtel! .." - "Euh ... Voulez-vous montrer le chemin?" En pensant, nous sommes arrivés à la conclusion que vous devez d'abord décider des états finaux des produits; c'était notre premier objectif.

Alors, comment analysez-vous une douzaine de produits avec des équipes suffisamment grandes de 10 à 200 personnes et déterminez-vous des métriques mesurables lors de la réplication des solutions?

1: 0 en faveur du Chaos, ou DevOps sur les omoplates

Nous avons commencé par essayer d'appliquer des diagrammes IDEF0 et divers diagrammes de processus métier de la série BPwin. La confusion a commencé après la cinquième case de la prochaine étape du prochain projet, et ces carrés pour chaque projet peuvent être dessinés dans la queue d'un long python sous 50+ étapes. J'étais triste et je voulais hurler vers la lune - cela ne convenait pas en général.

Tâches de production typiques

La modélisation des processus de production est un travail très complexe et laborieux: vous devez collecter, traiter et analyser un grand nombre de données sur différents départements et chaînes de production. Vous pouvez en savoir plus à ce sujet dans l'article " Modélisation des processus de production dans les entreprises informatiques ".

Lorsque nous avons commencé à modéliser notre processus de production, nous avons poursuivi un objectif spécifique - 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 d'une ligne de code commit, parviennent au client sous forme d'installateurs et de mises à jour,
• quelles ressources sont prévues pour chaque étape de la production des produits,
• quels services sont impliqués à chaque étape,
• comment les domaines de responsabilité sont-ils différenciés pour chaque étape,
• quels contrats existent à l'entrée et à la sortie de chaque étape.

En cliquant sur l'image s'ouvrira en taille réelle

Notre travail dans l'entreprise est divisé en plusieurs domaines fonctionnels. La direction des infrastructures est engagée dans l'optimisation du fonctionnement de toutes les ressources "fer" du département, ainsi que l'automatisation du déploiement des machines virtuelles et de leur environnement. La direction de surveillance fournit une surveillance de l'intégrité du service 24/7; Nous proposons é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 de projet. Enfin, webdev fournit des versions de publication sur les serveurs de mise à jour GUS et FLUS, ainsi que des licences de produits à l'aide du 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 les anciens mitaps: Op! DevOps! 2016 et Op! DevOps! 2017 ). Nous développons également des outils d'automatisation internes, notamment des solutions open source .

Au cours des cinq dernières années, de nombreuses opérations de même type et de routine se sont accumulées dans notre travail, et de nos développeurs d'autres départements viennent principalement les tâches dites standard , dont la solution est automatisée en tout ou en partie, ne cause pas de difficultés aux interprètes et ne nécessite pas de quantités de travail importantes. Avec les directions principales, nous avons analysé ces tâches et avons pu distinguer certaines catégories d' étapes de travail ou de production , divisé les étapes en étapes indivisibles et la chaîne technologique de production se compose de plusieurs étapes.



L'exemple le plus simple d'une chaîne technologique est 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 comprend de nombreuses étapes typiques distinctes: téléchargement de la source à partir de 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 magasin sur Artifactory et générer des notes de version via notre outil interne ChangelogBuilder.

Vous pouvez lire sur les tâches DevOps typiques dans nos autres articles sur Habré: « Expérience personnelle: à quoi ressemble notre système d'intégration continue » et « Automatisation des processus de développement: comment nous avons implémenté les idées DevOps dans les technologies positives ».

De nombreuses chaînes de production typiques forment le processus de production . Une approche standard pour décrire les processus consiste à utiliser des modèles fonctionnels IDEF0.

Un exemple de modélisation d'un processus CI de production

Nous avons accordé une attention particulière au développement de projets modèles pour un système d'intégration continue. Cela nous a permis de réaliser l'unification des projets, en mettant en évidence le soi-disant schéma d'assemblage de version avec des avancées .



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 sur Artifactory, après quoi ils sont déployés et testés sur des bancs de test, puis promus dans le référentiel de publication. Le service Artifactory est le point de distribution unique de tous les artefacts de build entre les équipes et d'autres services.

Si nous simplifions et généralisons considérablement notre schéma de publication, il comprend les étapes suivantes:

• assemblage de produits multiplateforme,
• déploiement sur bancs d'essai,
• exécution de tests fonctionnels et autres,
• promotion de builds testés pour libérer des référentiels sur Artifactory,
• Publier des versions pour mettre à jour les serveurs,
• livraison de montages et mises à jour de production,
• Lancez l'installation et les mises à jour du produit.

Par exemple, considérons le modèle technologique de ce schéma de version typique (ci-après simplement appelé le 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 la notation dite ICOM (Input-Control-Output-Mechanism) pour décrire les ressources utilisées à chaque étape, en fonction des règles et des exigences, de ce qui est fait, des résultats et des mécanismes, services ou personnes mettre en œuvre une étape spécifique.



En cliquant sur l'image s'ouvrira en taille réelle

En règle générale, dans les modèles fonctionnels, il est plus facile de décomposer et de détailler la description des processus. Mais avec une augmentation du nombre d'éléments, comprendre en eux quelque chose devient de plus en plus difficile. Mais dans le développement réel, il y a aussi des étapes auxiliaires: surveillance, certification des produits, automatisation des processus de travail et autres. C'est à cause du problème de mise à l'échelle que nous avons abandonné une telle description.

La naissance de l'espoir

Dans un livre, ils sont tombés sur de vieilles cartes soviétiques décrivant les processus technologiques (qui, incidemment, sont maintenant utilisés dans de nombreuses entreprises publiques et universités). Attendez, attendez, car nous avons aussi un processus technologique! .. Il y a des étapes, des résultats, des métriques, des exigences, des indicateurs et ainsi de suite ... Pourquoi ne pas essayer d'appliquer des cartes technologiques à nos convoyeurs de produits? Il y avait un sentiment: «Le voici! Nous avons trouvé le bon fil, il est temps de bien le tirer! »

Dans un tableau simple, nous avons décidé de fixer les produits en colonnes, et en rangées les étapes technologiques et les étapes du convoyeur de produits. Étapes - c'est quelque chose de grand, par exemple, l'étape d'assemblage du produit. Et les étapes sont quelque chose de plus petit et plus détaillé, par exemple, l'étape de téléchargement du code source sur le serveur de génération ou l'étape de compilation du code.

Aux intersections des lignes et des colonnes de la carte, nous notons les statuts d'une étape et d'un produit particuliers. Pour les statuts, de nombreux états ont été définis:

1. Aucune donnée - ou impossible. Il est nécessaire de procéder à une analyse de la pertinence de l'étape dans le produit. Soit l'analyse a déjà été effectuée, mais l'étape n'est actuellement pas nécessaire ou n'est pas économiquement justifiée.
2. Reporté - ou hors de propos pour le moment. Une étape dans le convoyeur est nécessaire, mais cette année, il n'y a pas de forces pour la mise en œuvre.
3. Planifié . La mise en œuvre de la scène est prévue pour cette année.
4. Il est mis en œuvre . L'étape dans le convoyeur est réalisée dans le volume requis.

Remplir la table a commencé par projet. Au début, les étapes et les étapes d'un projet étaient classées et des statuts étaient enregistrés pour eux. Ensuite, ils ont pris le projet suivant, y ont enregistré les statuts et ajouté les étapes et les étapes qui étaient absentes dans les projets précédents. En conséquence, nous avons obtenu les étapes et les étapes de l'ensemble de notre convoyeur 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 convoyeur de produits. Nous avons appelé une telle matrice une carte technologique.

En utilisant la carte technologique, nous nous coordonnons métrologiquement de manière raisonnable avec les plans de travail et les objectifs annuels des équipes que nous voulons atteindre conjointement: quelles étapes nous ajoutons cette année au projet et que nous laissons pour plus tard. En outre, dans le processus de travail, nous pouvons recevoir des améliorations dans les étapes que nous avons effectuées pour un seul produit. Ensuite, nous développons notre carte et introduisons cette amélioration comme une étape ou une nouvelle étape, puis nous analysons chaque produit et découvrons l'opportunité de reproduire l'amélioration.

Ils peuvent nous objecter: «Tout cela est bien sûr bon, ce n'est qu'avec le temps que le nombre d'étapes et d'étapes deviendra prohibitif. Comment être? "

Nous avons introduit des descriptions standard et suffisamment complètes des exigences pour chaque étape et étape, afin qu'elles soient comprises également par tous au sein de l'entreprise. Au fil du temps, lors de l'introduction d'améliorations, 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 les nuances technologiques s'inscrivent dans les exigences d'une étape ou d'une étape généralisante.

Comment évaluer l'effet de la réplication des décisions? Nous utilisons une approche extrêmement simple: nous attribuons les coûts d'investissement initiaux pour la mise en œuvre de la nouvelle étape aux coûts alimentaires généraux annuels, puis les divisons en tous lors de la réplication.

Certaines parties du développement sont déjà reflétées comme des étapes et des étapes sur la carte. Nous pouvons influencer la réduction des coûts des produits grâce à l'introduction de l'automatisation pour les étapes typiques. Après cela, nous considérons les changements dans les caractéristiques qualitatives, les métriques quantitatives et le profit perçu par les équipes (en heures-homme ou heures-machine d'économies).

Organigramme du processus

Si nous prenons toutes nos étapes et étapes, encodons avec des balises et développons en une seule chaîne, cela se révélera très long et incompréhensible (juste la très «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] 

Ce sont les étapes de l'assemblage des produits [Build], de leur déploiement sur les serveurs de test [Deploy], du test [Test], de la promotion des assemblys pour libérer des référentiels basés sur les tests [Promote], de la génération et de la publication des licences [License], de la publication [Publish] sur le serveur de mise à jour GUS et la livraison aux serveurs de mise à jour FLUS, l'installation et la mise à jour des composants du produit sur l'infrastructure du client à l'aide de la gestion de la configuration du produit [Installer], ainsi que la collecte de la télémétrie à partir des produits installés.

À cela s'ajoutent des étapes distinctes: surveillance de l'état de l'infrastructure [InfMonitoring], contrôle de version du code source [SourceCodeControl], préparation de l'environnement d'assemblage [Prepare], gestion de projet [Workflow], mise à disposition des équipes d'outils de communication [Communication], certification produit [Certification] et mise à disposition autosuffisance des processus CI [CISelfSufficiency] (par exemple, indépendance des assemblages par rapport à Internet). Nous ne considérerons même pas des dizaines d'étapes dans nos processus, car elles sont très spécifiques.

Il sera beaucoup plus facile de comprendre et d'examiner l'ensemble du processus de production, s'il est présenté sous la forme d'une 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 ligne par ligne, et la description de ce qui est fait à chaque étape ou étape est décrite dans des colonnes. L'accent est mis principalement sur les ressources qui fournissent chaque étape et la délimitation des domaines de responsabilité.

La carte pour nous est une sorte de classificateur. Il reflète les grandes parties technologiques de la production alimentaire. Grâce à cela, il est devenu plus facile pour notre équipe d'automatiseurs d'interagir avec les développeurs et de planifier conjointement la mise en œuvre des étapes d'automatisation, ainsi que de comprendre le travail et les ressources (humaines et "de fer") nécessaires.

Au sein de notre entreprise, une carte est automatiquement générée à partir d'un modèle jinja sous la forme d'un 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 consultée ici .



En cliquant sur l'image s'ouvrira en taille réelle

En bref, l'organigramme est une image généralisée du processus de production, qui reflète clairement les blocs classés avec des fonctionnalités typiques.

La structure de notre routage

La carte se compose de plusieurs parties:

1. Zone d'en-tête - voici une description générale de la carte, les concepts de base sont introduits, les ressources de base et les résultats du processus de production sont déterminés.
2. Panneau d'information - ici, vous pouvez contrôler l'affichage des données pour des produits individuels, fournit un résumé des étapes et des étapes suivies pour tous les produits en général.
3. Carte technologique - une description tabulaire du processus technologique. Sur la carte:
   
   • toutes les étapes, étapes et leurs codes sont donnés;
   • Une description brève et complète des étapes est donnée;
   • Les ressources d'entrée et les services utilisés à chaque étape sont indiqués;
   • les résultats de chaque étape et étape individuelle sont indiqués;
   • Le domaine de responsabilité pour chaque étape et étape est indiqué;
   • identifié 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, à la fois au moment actuel - un fait et à l'avenir - un plan;
   • pour chaque produit, il est indiqué quelles étapes technologiques ou étapes 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 de prendre certaines mesures - selon le rôle de l'employé dans l'entreprise (responsable du développement, chef de produit, développeur ou testeur):

• comprendre quelles étapes manquent dans un produit ou projet réel et évaluer la nécessité de leur mise en œuvre;
• différencier les zones de responsabilité entre plusieurs services s'ils travaillent sur différentes étapes;
• convenir de contrats aux entrées et sorties des étapes;
• intégrer votre étape de travail dans le processus de développement global;
• évaluer plus précisément le besoin de ressources pour chacune des étapes.

Résumant tout ce qui précède

Le routage est universel, extensible et facile à entretenir. Il est beaucoup plus facile d'élaborer et de maintenir une description des processus sous cette forme que dans un modèle académique rigoureux IDEF0. De plus, la description tabulaire est plus simple, plus familière et mieux structurée que le modèle fonctionnel.

Pour la mise en œuvre technique des étapes, nous sommes responsables de l'outil interne spécial CrossBuilder - un outil intercouche entre les systèmes CI, les services et l'infrastructure. Le développeur n'a pas besoin de voir 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 particularités de notre infrastructure.

Résumé

L'article s'est avéré assez long, mais cela est inévitable pour décrire la modélisation de processus complexes. En fin de compte, je veux brièvement résumer nos principales idées:

• L'objectif de l'introduction des idées DevOps dans notre entreprise est une réduction cohérente du coût de production et de maintenance des produits de l'entreprise en termes quantitatifs (heures-homme ou heures-machine, vCPU, RAM, disque).
• Un moyen de réduire le coût total du développement est de minimiser le coût de l'exécution des tâches série typiques: étapes et étapes du processus technologique.
• Une tâche typique est une tâche dont la solution est automatisée en tout ou en partie, ne cause pas de difficultés aux 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 volume différents.
• 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 IDEF0 fonctionnel ou un organigramme plus simple.
• Un routage est une présentation tabulaire des étapes et des étapes d'un processus de fabrication. Plus important encore: la carte vous permet de voir l'ensemble du processus, en gros morceaux avec la possibilité de détailler.
• Sur la base de la carte technologique, il est possible d'évaluer la nécessité de la mise en œuvre des étapes dans un produit particulier, de distinguer les domaines de responsabilité, de convenir de contrats pour les intrants et les extrants des étapes, d'évaluer plus précisément le besoin de ressources.

Dans les articles suivants, nous parlerons plus en détail des outils techniques utilisés pour implémenter certaines étapes technologiques sur notre carte.

Auteurs de l'article:

• Alexander Pazdnikov - Responsable de l'automatisation (DevOps), Positive Technologies
• Timur Gilmullin - député. Responsable Automation (DevOps), Positive Technologies