Foto:
Dag Allemaal! Wij zijn automatiseringsingenieurs van het bedrijf en we ondersteunen de ontwikkeling van de producten van het bedrijf: we ondersteunen de gehele assemblagepijplijn, vanaf het vastleggen van een regel code door ontwikkelaars tot de publicatie van eindproducten en licenties op updateservers. Informeel worden we DevOps-ingenieurs genoemd. In dit artikel willen we het hebben over de technologische stadia van het softwareproductieproces, hoe we ze zien en hoe we ze classificeren.
Uit het materiaal leer je over de complexiteit van het coördineren van de ontwikkeling van meerdere producten, over wat een technologische kaart is en hoe deze helpt oplossingen te stroomlijnen en te repliceren, wat de belangrijkste fasen en stappen van het ontwikkelingsproces zijn, hoe de verantwoordelijkheidsgebieden zijn tussen DevOps en teams in ons bedrijf.
Over Chaos en DevOps
Kort gezegd omvat het concept van DevOps ontwikkelingstools en -diensten, evenals methodologieën en best practices voor het gebruik ervan. Laten we het mondiale eruit pikken doel uit de implementatie van DevOps-ideeën in ons bedrijf: dit is een consistente verlaging van de productie- en onderhoudskosten van producten in kwantitatieve termen (manuren of machine-uren, CPU, RAM, schijf, enz.). De eenvoudigste en meest voor de hand liggende manier om de totale ontwikkelingskosten op het niveau van het hele bedrijf te verlagen is het minimaliseren van de kosten voor het uitvoeren van typische seriële taken in alle stadia van de productie. Maar wat zijn deze fasen, hoe kunnen ze worden gescheiden van het algemene proces, uit welke stappen bestaan ze?
Wanneer een bedrijf één product ontwikkelt, is alles min of meer duidelijk: er is meestal een gemeenschappelijk stappenplan en ontwikkelingsschema. Maar wat te doen als de productlijn zich uitbreidt en er meer producten zijn? Op het eerste gezicht hebben ze vergelijkbare processen en assemblagelijnen, en begint het spel 'zoek X verschillen' in logs en scripts. Maar wat als er al meer dan 5 projecten in actieve ontwikkeling zijn en er ondersteuning nodig is voor verschillende versies die over meerdere jaren zijn ontwikkeld? Willen we het maximaal mogelijke aantal oplossingen in productpijplijnen hergebruiken of zijn we bereid geld uit te geven aan een unieke ontwikkeling voor elk?
Hoe vind je een balans tussen uniciteit en seriële oplossingen?
Deze vragen zijn sinds 2015 steeds vaker voor ons opgekomen. Het aantal producten groeide en we probeerden onze automatiseringsafdeling (DevOps), die de assemblagelijnen van deze producten ondersteunde, tot een minimum uit te breiden. Tegelijkertijd wilden we zoveel mogelijk oplossingen tussen producten repliceren. Waarom zou je tenslotte hetzelfde in tien producten op verschillende manieren doen?
Ontwikkelingsdirecteur: "Jongens, kunnen we op de een of andere manier evalueren wat DevOps voor producten doet?"
Wij: “We weten het niet, we hebben zo’n vraag niet gesteld, maar met welke indicatoren moet rekening worden gehouden?”
Ontwikkelingsdirecteur: "Wie weet! Denken…"
Zoals in die beroemde film: "Ik zit in een hotel! .." - "Eh... Kun je me de weg wijzen?" Bij nader inzien kwamen we tot de conclusie dat we eerst moeten beslissen over de eindtoestand van de producten; dit werd ons eerste doel.
Dus, hoe analyseer je een tiental producten met redelijk grote teams van 10 tot 200 mensen en bepaal je meetbare statistieken bij het repliceren van oplossingen?
1:0 ten gunste van Chaos, of DevOps op de schouderbladen
We zijn begonnen met een poging om IDEF0-diagrammen en verschillende bedrijfsprocesdiagrammen uit de BPwin-serie toe te passen. De verwarring begon na het vijfde vierkant van de volgende fase van het volgende project, en deze vierkanten voor elk project kunnen in de staart van een lange python worden getekend onder meer dan 50 stappen. Ik voelde me verdrietig en wilde naar de maan huilen - het paste over het algemeen niet.
Typische productietaken
Het modelleren van productieprocessen is een zeer complexe en nauwgezette klus: je moet veel data van verschillende afdelingen en productieketens verzamelen, verwerken en analyseren. Meer hierover lees je in het artikel ".
Toen we begonnen met het modelleren van ons productieproces, hadden we een specifiek doel: aan elke medewerker die betrokken was bij de ontwikkeling van de producten van ons bedrijf en aan projectmanagers het volgende overbrengen:
- hoe producten en hun componenten, beginnend bij het vastleggen van een regel code, de klant bereiken in de vorm van installatieprogramma's en updates,
- welke middelen worden verstrekt voor elke fase van de productie van producten,
- welke diensten er in elke fase betrokken zijn,
- hoe de verantwoordelijkheidsgebieden voor elke fase worden afgebakend,
- welke contracten bestaan er bij de ingang en uitgang van elke fase.
Als u op de afbeelding klikt, wordt deze op volledige grootte geopend.
Ons werk in het bedrijf is verdeeld in verschillende functionele gebieden. De leiding van de infrastructuur houdt zich bezig met de optimalisatie van de werking van alle "ijzeren" middelen van de afdeling, evenals de automatisering van de inzet van virtuele machines en de omgeving daarop. De richting van monitoring zorgt voor 24/7 controle van de serviceprestaties; wij bieden ook monitoring aan als service voor ontwikkelaars. De workflowrichting biedt teams tools om ontwikkelings- en testprocessen te beheren, de status van de code te analyseren en analyses van projecten te verkrijgen. En ten slotte verzorgt de webdev-directie de publicatie van releases op de GUS- en FLUS-updateservers, evenals de licentieverlening voor producten die de LicenseLab-service gebruiken. Om de productiepijplijn te ondersteunen, hebben we veel verschillende ondersteuningsdiensten voor ontwikkelaars opgezet en onderhouden (je kunt naar verhalen over sommige daarvan luisteren op oude meetups: и). We ontwikkelen ook interne automatiseringstools, waaronder .
De afgelopen vijf jaar heeft ons werk veel van hetzelfde type en routinematige handelingen opgeleverd, en onze ontwikkelaars van andere afdelingen komen voornamelijk uit de zogenaamde typische taken, waarvan de oplossing geheel of gedeeltelijk geautomatiseerd is, geen problemen oplevert voor artiesten en geen aanzienlijke hoeveelheden werk vereist. Samen met de leidende gebieden hebben we dergelijke taken geanalyseerd en individuele werkcategorieën kunnen identificeren, of productie stappen, de fasen waren verdeeld in ondeelbare stappen, en er zijn verschillende fasen bij elkaar opgeteld productie procesketen.
Het eenvoudigste voorbeeld van een technologische keten zijn de fasen van assemblage, implementatie en testen van elk van onze producten binnen het bedrijf. De bouwfase bestaat op zijn beurt bijvoorbeeld uit veel afzonderlijke, typische stappen: het downloaden van bronnen uit GitLab, het voorbereiden van afhankelijkheden en bibliotheken van derden, het testen van eenheden en het analyseren van statische code, het uitvoeren van een bouwscript op GitLab CI, het publiceren van artefacten in de repository op Artifactory en genereren van release-opmerkingen via onze interne ChangelogBuilder-tool.
Typische DevOps-taken lees je in onze andere artikelen op Habré: ""En".
Er ontstaan veel typische productieketens productieproces. De standaardaanpak voor het beschrijven van processen is het gebruik van functionele IDEF0-modellen.
Een voorbeeld van het modelleren van een CI-productieproces
We hebben bijzondere aandacht besteed aan de ontwikkeling van standaardprojecten voor een continu integratiesysteem. Dit maakte het mogelijk om de eenwording van projecten te bereiken, met de nadruk op de zogenaamde release build-schema met promoties.
Dit is hoe het werkt. Alle projecten zien er typisch uit: ze omvatten de configuratie van assemblages die in de snapshot-repository van Artifactory vallen, waarna ze worden ingezet en getest op testbanken, en vervolgens gepromoveerd naar de release-repository. De Artifactory-service is één distributiepunt voor alle build-artefacten tussen teams en andere services.
Als we ons vrijgaveschema sterk vereenvoudigen en generaliseren, omvat het de volgende stappen:
- platformonafhankelijke productassemblage,
- inzet op testbanken,
- uitvoeren van functionele en andere tests,
- het promoten van geteste builds om repositories bij Artifactory vrij te geven,
- publicatie van release-builds op updateservers,
- levering van assemblages en updates voor de productie,
- het starten van de installatie en het updaten van het product.
Beschouw bijvoorbeeld het technologische model van dit typische releaseschema (hierna eenvoudigweg Model) in de vorm van een functioneel IDEF0-model. Het weerspiegelt de belangrijkste fasen van ons CI-proces. IDEF0-modellen gebruiken de zogenaamde ICOM-notatie (Input-Control-Output-Mechanism) om te beschrijven welke middelen in elke fase worden gebruikt, op basis van welke regels en vereisten er wordt gewerkt, wat de output is en welke mechanismen, diensten of mensen een bepaalde fase implementeren.
Als u op de afbeelding klikt, wordt deze op volledige grootte geopend.
In de regel is het gemakkelijker om de beschrijving van processen in functionele modellen te ontleden en te detailleren. Maar naarmate het aantal elementen groeit, wordt het steeds moeilijker om iets erin te begrijpen. Maar in de echte ontwikkeling zijn er ook hulpfasen: monitoring, productcertificering, workflowautomatisering en andere. Vanwege het schaalprobleem hebben we deze beschrijving verlaten.
Geboorte van hoop
In één boek kwamen we oude Sovjetkaarten tegen die technologische processen beschrijven (die trouwens nog steeds worden gebruikt bij veel staatsbedrijven en universiteiten). Wacht, wacht, want we hebben ook een workflow! Er zijn fasen, resultaten, statistieken, vereisten, indicatoren, enzovoort. Waarom proberen we niet ook stroomschema's toe te passen op onze productpijplijnen? Er was een gevoel: “Dit is het! We hebben de juiste draad gevonden, het is tijd om er goed aan te trekken!
In een eenvoudige tabel hebben we besloten om producten per kolom, en technologische stadia en productpijplijnstappen per rij, vast te leggen. Mijlpalen zijn iets groots, zoals een productbouwstap. En stappen zijn iets kleiner en gedetailleerder, zoals de stap van het downloaden van de broncode naar de buildserver of de stap van het compileren van de code.
Op de kruispunten van de rijen en kolommen van de kaart zetten we de statussen voor een specifieke fase en product neer. Voor statussen is een reeks toestanden gedefinieerd:
- Geen informatie - of ongepast. Het is noodzakelijk om de vraag naar een fase in het product te analyseren. Ofwel is de analyse al uitgevoerd, maar is de fase momenteel niet nodig of economisch niet verantwoord.
- Uitgesteld - of op dit moment niet relevant. Er is een fase in de pijplijn nodig, maar dit jaar zijn er geen krachten voor implementatie.
- Gepland. De uitvoering van de fase staat dit jaar gepland.
- Geïmplementeerd. De fase in de pijplijn wordt in het vereiste volume geïmplementeerd.
Het invullen van de tabel begon project voor project. Eerst werden de fasen en stappen van één project geclassificeerd en hun status vastgelegd. Vervolgens namen ze het volgende project, herstelden de statussen daarin en voegden de fasen en stappen toe die in eerdere projecten ontbraken. Als gevolg hiervan kregen we de fasen en stappen van onze gehele productiepijplijn en hun status in een specifiek project. Het bleek iets dat leek op de competentiematrix van de productpijplijn. We noemden zo’n matrix een technologische kaart.
Met behulp van de technologische kaart stemmen we metrologisch redelijk met de teams de werkplannen voor het jaar af en de doelstellingen die we samen willen bereiken: welke fasen we dit jaar aan het project toevoegen en welke we later verlaten. Ook kunnen we in de loop van de werkzaamheden verbeteringen aanbrengen in de fasen die we voor slechts één product hebben voltooid. Vervolgens breiden we onze kaart uit en introduceren we deze verbetering als een fase of een nieuwe stap. Vervolgens analyseren we voor elk product en ontdekken we de haalbaarheid van het repliceren van de verbetering.
Ze kunnen tegen ons bezwaar maken: “Dit is natuurlijk allemaal goed, alleen zal het aantal stappen en fasen na verloop van tijd onbetaalbaar groot worden. Hoe te zijn?
Per fase en stap hebben we standaard en redelijk volledige beschrijvingen van de eisen ingevoerd, zodat deze door iedereen binnen het bedrijf op dezelfde manier worden begrepen. Na verloop van tijd, als er verbeteringen worden doorgevoerd, kan een stap worden opgenomen in een andere fase of stap, en dan zullen ze "ineenstorten". Tegelijkertijd passen alle vereisten en technologische nuances in de vereisten van de generaliserende fase of stap.
Hoe evalueer je het effect van het repliceren van oplossingen? We gebruiken een uiterst eenvoudige aanpak: we schrijven de initiële kapitaalkosten voor de implementatie van een nieuwe fase toe aan de jaarlijkse algemene productkosten en delen deze vervolgens door alles bij het repliceren.
Delen van de ontwikkeling worden al als mijlpalen en stappen op de kaart weergegeven. We kunnen de verlaging van de productkosten beïnvloeden door de introductie van automatisering voor typische fasen. Daarna bekijken we de veranderingen in kwalitatieve kenmerken, kwantitatieve maatstaven en de winst die de teams ontvangen (in manuren of machine-uren aan besparingen).
Technologische kaart van het productieproces
Als we al onze fasen en stappen nemen, ze coderen met tags en ze uitbreiden tot één keten, dan zal het erg lang en onbegrijpelijk blijken te zijn (precies dezelfde "pythonstaart" waar we het aan het begin van het artikel over hadden) :
[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]Dit zijn de fasen van het bouwen van producten [Build], het implementeren ervan op testservers [Deploy], het testen [Test], het promoten van builds om repositories vrij te geven op basis van de testresultaten [Promote], het genereren en publiceren van licenties [License], het publiceren [ Publiceren] op de GUS-updateserver en levering aan FLUS-updateservers, installatie en updaten van productcomponenten op de infrastructuur van de klant met behulp van Product Configuration Management [Installeren], evenals het verzamelen van telemetrie [Telemetrie] van geïnstalleerde producten.
Daarnaast kunnen afzonderlijke fasen worden onderscheiden: monitoring van de infrastructuurstatus [InfMonitoring], versiebeheer van de broncode [SourceCodeControl], voorbereiding van de bouwomgeving [Prepare], projectmanagement [Workflow], teams voorzien van communicatiemiddelen [Communicatie], productcertificering [ Certificering] en het garanderen van de zelfvoorziening van CI-processen [CISelfSufficiency] (bijvoorbeeld de onafhankelijkheid van assemblages van internet). Tientallen stappen in onze processen zullen niet eens in beschouwing worden genomen, omdat ze heel specifiek zijn.
Het zal veel gemakkelijker zijn om het hele productieproces te begrijpen en te bekijken als het in de vorm wordt gepresenteerd technologische kaart; dit is een tabel waarin de individuele productiefasen en ontlede stappen van het model in rijen zijn geschreven, en in kolommen een beschrijving van wat er in elke fase of stap wordt gedaan. De nadruk wordt vooral gelegd op de middelen die in elke fase beschikbaar zijn, en op de afbakening van de verantwoordelijkheidsgebieden.
De kaart is voor ons een soort classificator. Het weerspiegelt de grote technologische delen van de productie van producten. Dankzij dit werd het voor ons automatiseringsteam gemakkelijker om met ontwikkelaars te communiceren en gezamenlijk de implementatie van automatiseringsfasen te plannen, en om te begrijpen welke arbeidskosten en middelen (personeel en hardware) hiervoor nodig zijn.
Binnen ons bedrijf wordt de kaart automatisch gegenereerd op basis van de jinja-sjabloon als een gewoon HTML-bestand en vervolgens geüpload naar de GitLab Pages-server. Er kan een screenshot met een voorbeeld van een volledig gegenereerde kaart worden bekeken .
Als u op de afbeelding klikt, wordt deze op volledige grootte geopend.
Kortom, de technologische kaart is een algemeen beeld van het productieproces, dat duidelijk geclassificeerde blokken met typische functionaliteit weerspiegelt.
Structuur van onze routekaart
De kaart bestaat uit verschillende delen:
- Titelgebied - hier is een algemene beschrijving van de kaart, basisconcepten worden geïntroduceerd, de belangrijkste hulpbronnen en resultaten van het productieproces worden gedefinieerd.
- Dashboard - hier kunt u de weergave van gegevens voor individuele producten regelen. Er wordt een samenvatting gegeven van de geïmplementeerde fasen en stappen in het algemeen voor alle producten.
- Technologische kaart - een beschrijving in tabelvorm van het technologische proces. Op de kaart:
- alle fasen, stappen en hun codes worden gegeven;
- er worden korte en volledige beschrijvingen van de fasen gegeven;
- de inputbronnen en diensten die in elke fase worden gebruikt, worden aangegeven;
- de resultaten van elke fase en een afzonderlijke stap worden aangegeven;
- per fase en stap wordt het verantwoordelijkheidsgebied aangegeven;
- de technische middelen, zoals HDD (SSD), RAM, vCPU, en de manuren die nodig zijn om de werkzaamheden in deze fase te ondersteunen, zowel op dit moment – een feit, als in de toekomst – een plan, zijn vastgesteld;
- voor elk product wordt aangegeven welke technologische stadia of stappen ervoor zijn geïmplementeerd, gepland voor implementatie, niet relevant of niet geïmplementeerd.
Besluitvorming op basis van de technologische kaart
Na het bestuderen van de kaart is het mogelijk om enkele acties te ondernemen - afhankelijk van de rol van de medewerker in het bedrijf (ontwikkelingsmanager, productmanager, ontwikkelaar of tester):
- begrijpen welke fasen ontbreken in een echt product of project, en de noodzaak van de implementatie ervan beoordelen;
- de verantwoordelijkheidsgebieden tussen verschillende afdelingen afbakenen als ze in verschillende fasen werken;
- contracten afspreken bij de in- en uitgangen van de podia;
- uw werkfase integreren in het algehele ontwikkelingsproces;
- nauwkeuriger inschatten van de behoefte aan middelen die in elk van de fasen voorzien.
Samenvattend al het bovenstaande
De routing is veelzijdig, uitbreidbaar en gemakkelijk te onderhouden. Het is veel gemakkelijker om in deze vorm een beschrijving van processen te ontwikkelen en bij te houden dan in een strikt academisch IDEF0-model. Bovendien is een beschrijving in tabelvorm eenvoudiger, vertrouwder en beter gestructureerd dan een functioneel model.
Voor de technische implementatie van de stappen hebben we een speciale interne tool CrossBuilder - een laagtool tussen CI-systemen, services en infrastructuur. De ontwikkelaar hoeft zijn fiets niet in te korten: in ons CI-systeem is het voldoende om een van de scripts (de zogenaamde taak) van de CrossBuilder-tool uit te voeren, die deze correct zal uitvoeren, rekening houdend met de kenmerken van onze infrastructuur .
Resultaten van
Het artikel bleek behoorlijk lang, maar dit is onvermijdelijk bij het beschrijven van het modelleren van complexe processen. Tot slot wil ik onze belangrijkste ideeën kort samenvatten:
- Het doel van het implementeren van DevOps-ideeën in ons bedrijf is om de productie- en onderhoudskosten van de producten van het bedrijf consistent te verlagen in kwantitatieve termen (manuren of machine-uren, vCPU, RAM, schijf).
- De manier om de totale ontwikkelingskosten te verlagen is door de kosten van het uitvoeren van typische seriële taken: fasen en stappen van het technologische proces, te minimaliseren.
- Een typische taak is een taak waarvan de oplossing volledig of gedeeltelijk geautomatiseerd is, geen problemen veroorzaakt voor uitvoerende kunstenaars en geen aanzienlijke arbeidskosten vereist.
- Het productieproces bestaat uit fasen, de fasen zijn onderverdeeld in ondeelbare stappen, dit zijn typische taken van verschillende schaal en reikwijdte.
- Vanuit uiteenlopende typische taken zijn we gekomen tot complexe technologische ketens en modellen op meerdere niveaus van het productieproces, die kunnen worden beschreven door een functioneel IDEF0-model of een eenvoudigere technologische kaart.
- De technologische kaart is een tabelvormige weergave van de fasen en stappen van het productieproces. Het allerbelangrijkste: met de kaart kun je het hele proces in zijn geheel zien, in grote stukken met de mogelijkheid om ze in detail te beschrijven.
- Op basis van de technologische kaart is het mogelijk om de noodzaak te beoordelen om fasen in een bepaald product te introduceren, verantwoordelijkheidsgebieden af te bakenen, contracten overeen te komen voor de input en output van fasen, en de behoefte aan middelen nauwkeuriger te beoordelen.
In de volgende artikelen zullen we in meer detail beschrijven welke technische hulpmiddelen worden gebruikt om bepaalde technologische fasen op onze kaart te implementeren.
Auteurs van artikelen:
- — Hoofd Automatisering (DevOps) bij Positive Technologies
- - Plaatsvervanger Hoofd van de afdeling Automatisering (DevOps) bij Positive Technologies
Bron: www.habr.com