Foto:
Hallo allemaal! Wij zijn automatiseringsingenieurs van het bedrijf en we ondersteunen de ontwikkeling van de producten van het bedrijf: we ondersteunen de volledige assemblagelijn, van het vastleggen van een regel code door ontwikkelaars tot de publicatie van voltooide producten en licenties op updateservers. Informeel worden we DevOps-engineers genoemd. In dit artikel willen we het hebben over de technologische fasen van het softwareproductieproces, hoe we deze zien en hoe we ze classificeren.
Aan de hand van dit materiaal leert u over de complexiteit van het coördineren van de ontwikkeling van meerdere producten, wat een proceskaart is en hoe deze helpt bij het organiseren en repliceren van oplossingen, wat de belangrijkste fasen en stappen van het ontwikkelingsproces zijn en hoe verantwoordelijkheidsgebieden worden afgebakend tussen DevOps en teams binnen ons bedrijf.
Over Chaos en DevOps
Laten we kort opmerken dat het concept DevOps ontwikkeltools en -services omvat, evenals methodologieën en best practices voor het gebruik ervan. Laten we de wereldwijde doel van de implementatie van DevOps-ideeën in ons bedrijf: dit is een consistente verlaging van de productie- en ondersteuningskosten 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 bedrijfsniveau te verlagen is het minimaliseren van de kosten van het uitvoeren van typische serietaken in alle productiefasen. Maar wat zijn deze fasen, hoe onderscheiden ze zich van het algemene proces, uit welke stappen bestaan ze?
Wanneer een bedrijf één product ontwikkelt, is alles min of meer duidelijk: meestal is er een gemeenschappelijke roadmap en ontwikkelschema. 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 van "zoek X verschillen" in logs en scripts. Maar wat als er al meer dan 5 projecten actief in ontwikkeling zijn en ondersteuning voor meerdere versies over meerdere jaren nodig is? Willen we zoveel mogelijk oplossingen hergebruiken in productpijplijnen of zijn we bereid om geld te investeren in unieke ontwikkeling voor elk?
Hoe vinden we een balans tussen uniciteit en serialiteit van oplossingen?
Deze vragen kwamen vanaf 2015 steeds vaker bij ons op. Het aantal producten groeide en we probeerden onze automatiseringsafdeling (DevOps), die de assemblagelijnen van deze producten ondersteunde, zo min mogelijk uit te breiden. Tegelijkertijd wilden we zoveel mogelijk oplossingen tussen producten repliceren. Want waarom zou je hetzelfde in tien producten op verschillende manieren doen?
Directeur Ontwikkeling: "Jongens, is er een manier waarop we kunnen evalueren wat DevOps voor producten doet?"
Wij: “We weten het niet, we hebben onszelf deze vraag niet gesteld, maar welke indicatoren moeten we in aanmerking nemen?”
Directeur Ontwikkeling: "Wie weet! Denk er eens over na..."
Zoals in die beroemde film: "Ik ga naar het hotel!..." - "Eh... Kun je me de weg wijzen?" Na erover nagedacht te hebben, kwamen we tot de conclusie dat we eerst de eindtoestand van de producten moesten bepalen; dit werd ons eerste doel.
Hoe analyseer je dan een dozijn producten met redelijk grote teams van 10 tot 200 mensen en bepaal je meetbare parameters bij het repliceren van oplossingen?
1:0 voor Chaos, of DevOps op de schouderbladen
We 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 worden getekend in de staart van een zeer lange Python met meer dan 50 stappen. Ik voelde me verdrietig en wilde huilen - het werkte over het algemeen niet.
Typische productietaken
Het modelleren van productieprocessen is een zeer complexe en tijdrovende klus: je moet een grote hoeveelheid data uit verschillende afdelingen en productieketens verzamelen, verwerken en analyseren. Je leest hier meer over in het artikel «.
Toen we aan de slag gingen met het modelleren van ons productieproces, hadden we een specifiek doel voor ogen: alle medewerkers die betrokken waren bij de productontwikkeling van ons bedrijf en projectmanagers wilden informeren over:
- hoe producten en hun componenten, vanaf het vastleggen van een regel code, de klant bereiken in de vorm van installatieprogramma's en updates,
- welke middelen beschikbaar zijn voor elke fase van de productproductie,
- welke diensten bij elke fase betrokken zijn,
- hoe worden de verantwoordelijkheidsgebieden voor elke fase afgebakend,
- welke contracten er bestaan bij de input en output van elke fase.
Klik op de afbeelding om deze in volledig formaat te openen
Onze werkzaamheden binnen het bedrijf zijn onderverdeeld in verschillende functionele gebieden. Het infrastructuurgebied houdt zich bezig met de optimalisatie van de werking van alle hardwarebronnen van de afdeling, evenals de automatisering van de implementatie van virtuele machines en de omgeving daarop. Het monitoringgebied zorgt voor 24/7 controle over de prestaties van services; we bieden ook monitoring als een service voor ontwikkelaars. Het workflowgebied biedt teams tools voor het beheren van ontwikkel- en testprocessen, het analyseren van de status van de code en het verkrijgen van analyses van projecten. En tot slot zorgt het webdev-gebied voor de publicatie van releases op de GUS- en FLUS-updateservers, evenals voor de licentieverlening van producten met behulp van de LicenseLab-service. Ter ondersteuning van de productiepijplijn hebben we diverse ondersteunende services voor ontwikkelaars opgezet en onderhouden (u kunt verhalen over enkele hiervan beluisteren tijdens oude meetups: и). We ontwikkelen ook interne automatiseringstools, waaronder .
De afgelopen vijf jaar heeft ons werk veel soortgelijke en routinematige handelingen opgeleverd, en van onze ontwikkelaars in andere afdelingen ontvangen we voornamelijk zogenaamde typische taken, waarvan de oplossing geheel of gedeeltelijk geautomatiseerd is, geen problemen oplevert voor uitvoerders en geen aanzienlijke hoeveelheid werk vereist. Samen met de leidende gebieden hebben we dergelijke taken geanalyseerd en konden we afzonderlijke werkcategorieën identificeren, of productiefasende fasen werden verdeeld in ondeelbare stappen, en er zijn verschillende fasen samengesteld productieprocesketen.
Het eenvoudigste voorbeeld van een technologische keten zijn de fasen van assemblage, implementatie en testen van elk van onze producten binnen het bedrijf. De assemblagefase bestaat bijvoorbeeld uit vele afzonderlijke, typische stappen: het downloaden van bronnen van GitLab, het voorbereiden van afhankelijkheden en bibliotheken van derden, unittesten en statische codeanalyse, het uitvoeren van een buildscript op GitLab CI, het publiceren van artefacten naar de repository op Artifactory en het genereren van release notes via onze interne tool ChangelogBuilder.
U kunt meer lezen over typische DevOps-taken in onze andere artikelen op Habr: «"En".
Er wordt een veelheid aan typische productieketens gevormd productieprocesDe standaardbenadering voor het beschrijven van processen is het gebruik van functionele IDEF0-modellen.
Een voorbeeld van het modelleren van een productie-CI-proces
We hebben speciale aandacht besteed aan de ontwikkeling van standaardprojecten voor het continue integratiesysteem. Dit stelde ons in staat om projecten te unificeren, met de nadruk op de zogenaamde vrijgaveschema van assemblages met promoties.
Zo werkt het. Alle projecten zien er typisch uit: ze bevatten een configuratie van builds die in een snapshot-repository op Artifactory worden geplaatst, vervolgens worden geïmplementeerd en getest op testbeds, en vervolgens worden gepromoveerd naar een release-repository. De Artifactory-service is een centraal distributiepunt voor alle build-artefacten tussen teams en andere services.
Als we ons releaseschema sterk vereenvoudigen en generaliseren, omvat het de volgende fasen:
- platformonafhankelijke productassemblage,
- inzetten op testbanken,
- het uitvoeren van functionele en andere tests,
- het promoten van geteste builds naar release repositories op Artifactory,
- het publiceren van release-builds om servers te updaten,
- levering van assemblages en updates voor de productie,
- Start de installatie en productupdate.
Laten we bijvoorbeeld het technologische model van dit typische releaseschema (hierna eenvoudigweg het Model genoemd) eens bekijken 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 bronnen in elke fase worden gebruikt, welke regels en vereisten het werk beheersen, wat de output is en welke mechanismen, diensten of mensen een bepaalde fase implementeren.
Klik op de afbeelding om deze in volledig formaat te openen
In functionele modellen is het doorgaans gemakkelijker om de beschrijving van processen te ontleden en te detailleren. Maar naarmate het aantal elementen toeneemt, wordt het steeds moeilijker om er iets in te begrijpen. Maar in de echte ontwikkeling zijn er ook ondersteunende fasen: monitoring, productcertificering, automatisering van werkprocessen, enzovoort. Juist vanwege het schaalprobleem zijn we van een dergelijke beschrijving afgestapt.
Geboorte van hoop
In een boek kwamen we oude Sovjetkaarten tegen die technologische processen beschreven (die overigens nog steeds in veel staatsbedrijven en universiteiten worden gebruikt). Wacht, wacht, wij hebben ook een technologisch proces! Er zijn fasen, resultaten, meetgegevens, eisen, indicatoren, enzovoort... Waarom zouden we technologische kaarten niet eens toepassen op onze producttransportbanden? Ik voelde: "Daar is ie! We hebben de juiste draad gevonden, het is tijd om hem goed door te trekken!"
In een eenvoudige tabel hebben we besloten om producten per kolom vast te leggen, en technologische fasen en stappen van de producttransportband per rij. Fasen zijn iets groots, bijvoorbeeld de fase van productassemblage. Stappen zijn iets kleiners en gedetailleerder, bijvoorbeeld de stap van het downloaden van de broncode naar de assemblageserver of de stap van het compileren van de code.
Op de snijpunten van de rijen en kolommen van de kaart stellen we de statussen in voor een specifieke fase en product. Voor de statussen hebben we een reeks statussen gedefinieerd:
- Geen informatie — of het is niet praktisch. Het is noodzakelijk om een analyse uit te voeren van de vraag naar de productfase. Of de analyse is al uitgevoerd, maar de fase is momenteel niet nodig of economisch niet verantwoord.
- Uitgesteld — of is op dit moment niet relevant. De fase in de transportband is nodig, maar er is geen kracht voor implementatie dit jaar.
- GeplandDe uitvoering hiervan staat gepland voor dit jaar.
- Geïmplementeerd. Het stadium in de transportband wordt in het gewenste volume uitgevoerd.
We begonnen de tabel project voor project in te vullen. Eerst classificeerden we de fasen en stappen van één project en registreerden we hun status. Vervolgens namen we het volgende project, registreerden de statussen daarvan en voegden de ontbrekende fasen en stappen in de vorige projecten toe. Zo kregen we de fasen en stappen van onze volledige productietransportband en hun statussen binnen een specifiek project. We kregen zoiets als een matrix van producttransportbandcompetenties. Zo'n matrix noemden we een proceskaart.
Met behulp van de proceskaart onderbouwen we metrologisch de werkplannen voor het jaar met de teams en de streefindicatoren die we samen willen bereiken: welke fasen we dit jaar aan het project toevoegen en welke we bewaren voor later. Tijdens het werkproces kunnen we ook verbeteringen hebben in de fasen die we slechts voor één product hebben afgerond. Vervolgens breiden we onze kaart uit en introduceren we deze verbetering als een fase of een nieuwe stap. Vervolgens voeren we een analyse uit voor elk product en onderzoeken we de haalbaarheid van replicatie van de verbetering.
We kunnen tegenwerpen: "Dit is natuurlijk allemaal goed en wel, maar na verloop van tijd zal het aantal stappen en etappes onbetaalbaar groot worden. Wat moeten we doen?"
We hebben standaard en vrij complete beschrijvingen van de vereisten voor elke fase en stap geïntroduceerd, zodat iedereen binnen het bedrijf ze op dezelfde manier begrijpt. Na verloop van tijd, wanneer er verbeteringen worden doorgevoerd, kan een stap worden opgenomen in een andere fase of stap - en dan "verdwijnen" ze. In dat geval passen alle vereisten en technologische nuances binnen de vereisten van de algemene fase of stap.
Hoe evalueren we het effect van het repliceren van oplossingen? We gebruiken een heel eenvoudige aanpak: we rekenen de initiële kapitaalkosten voor de implementatie van een nieuwe fase toe aan de jaarlijkse algemene productkosten en verdelen deze vervolgens over iedereen tijdens de replicatie.
De onderdelen van de ontwikkeling worden al weergegeven als fasen en stappen op de kaart. We kunnen de verlaging van de productkosten beïnvloeden door automatisering in te voeren voor typische fasen. Vervolgens berekenen we de veranderingen in kwaliteitskenmerken, kwantitatieve parameters en de winst die de teams behalen (in bespaarde manuren of machine-uren).
Technologische kaart van het productieproces
Als we al onze fasen en stappen nemen, ze coderen met tags en ze ontvouwen tot één keten, zal het resultaat erg lang en onbegrijpelijk zijn (precies dezelfde “pythonstaart” waar we het aan het begin van dit 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 samenstellen van producten [Build], het implementeren ervan op testservers [Deploy], het testen [Test], het promoten van assemblages naar release-repositories op basis van de testresultaten [Promote], het genereren en publiceren van licenties [License], het publiceren [Publish] op de GUS-updateserver en het leveren aan FLUS-updateservers, het installeren en bijwerken van productcomponenten op de infrastructuur van de klant met behulp van Product Configuration Management [Install] en het verzamelen van telemetrie [Telemetry] van geïnstalleerde producten.
Daarnaast kunnen we nog de volgende afzonderlijke fasen onderscheiden: het monitoren van de infrastructuurstatus [InfMonitoring], versiebeheer van de broncode [SourceCodeControl], het voorbereiden van de buildomgeving [Prepare], projectmanagement [Workflow], het voorzien van teams van communicatietools [Communication], productcertificering [Certification] en het waarborgen van de zelfredzaamheid van CI-processen [CISelfSufficiency] (bijvoorbeeld onafhankelijkheid van builds van internet). We zullen tientallen stappen in onze processen niet eens in overweging nemen, omdat ze zeer specifiek zijn.
Het zal veel gemakkelijker zijn om het hele productieproces te begrijpen en te beoordelen als je het je voorstelt als proceskaart; dit is een tabel waarin individuele productiefasen en uitgesplitste stappen van het model in rijen en kolommen worden vastgelegd - een beschrijving van wat er in elke fase of stap wordt gedaan. De nadruk ligt vooral op de middelen die elke fase levert en de afbakening van verantwoordelijkheidsgebieden.
De kaart is voor ons een soort classificatiesysteem. Het weerspiegelt grote technologische aspecten van de productproductie. Dankzij de kaart is het voor ons automatiseringsteam gemakkelijker geworden om met ontwikkelaars te communiceren en gezamenlijk de implementatie van automatiseringsfasen te plannen, en inzicht te krijgen in de arbeidskosten en resources (menselijk en hardwarematig) die hiervoor nodig zijn.
Binnen ons bedrijf wordt de kaart automatisch gegenereerd vanuit een jinja-sjabloon als een regulier HTML-bestand en vervolgens geüpload naar de GitLab Pages-server. Een screenshot met een voorbeeld van een volledig gegenereerde kaart is te bekijken. .
Klik op de afbeelding om deze in volledig formaat te openen
Kort gezegd is een proceskaart een algemeen beeld van het productieproces, dat duidelijk geclassificeerde blokken met typische functionaliteit weergeeft.
De structuur van onze proceskaart
De kaart bestaat uit verschillende delen:
- Koptekstgebied - Hier vindt u de algemene beschrijving van de kaart, worden basisconcepten geïntroduceerd en worden de belangrijkste bronnen en resultaten van het productieproces gedefinieerd.
- Dashboard - hier kunt u de weergave van gegevens over individuele producten beheren. Voor alle producten wordt een algemeen overzicht gegeven van de geïmplementeerde fasen en stappen.
- Een procesdiagram is een tabelvormige beschrijving van een proces. Op het diagram:
- alle fasen, stappen en hun codes zijn gegeven;
- Er worden korte en volledige beschrijvingen van de fasen gegeven;
- de invoerbronnen en diensten die in elke fase worden gebruikt, worden aangegeven;
- de resultaten van elke fase en individuele stap worden aangegeven;
- voor elke fase en stap wordt het verantwoordelijkheidsgebied aangegeven;
- technische middelen, zoals HDD (SSD), RAM, vCPU en manuren die nodig zijn om het werk in deze fase te ondersteunen, zowel op het huidige moment (feit) als in de toekomst (plan), worden bepaald;
- Per product wordt aangegeven welke technologische stappen of fases zijn geïmplementeerd, welke voor implementatie gepland zijn, welke niet relevant zijn of welke niet zijn geïmplementeerd.
Beslissingen nemen op basis van een proceskaart
Nadat u de kaart hebt bekeken, kunt u afhankelijk van de rol van de medewerker binnen het bedrijf (ontwikkelingsmanager, productmanager, ontwikkelaar of tester) een aantal acties ondernemen:
- begrijpen welke fasen ontbreken in een echt product of project en de noodzaak van de implementatie ervan beoordelen;
- verantwoordelijkheidsgebieden tussen verschillende afdelingen afbakenen als deze in verschillende stadia werken;
- afspraken maken over de input en output van de verschillende fases;
- integreer uw werkfase in het algehele ontwikkelingsproces;
- de behoefte aan middelen ter ondersteuning van elke fase nauwkeuriger kunnen inschatten.
Om al het bovenstaande samen te vatten
De procesgrafiek is universeel, uitbreidbaar en eenvoudig te ondersteunen. Het is veel gemakkelijker om een procesbeschrijving in deze vorm te ontwikkelen en te onderhouden dan in een strikt academisch IDEF0-model. Bovendien is een tabelbeschrijving eenvoudiger, vertrouwder en beter gestructureerd dan een functioneel model.
Voor de technische implementatie van de stappen hebben we een speciale interne tool genaamd CrossBuilder – een tool voor lagen tussen CI-systemen, services en infrastructuur. De ontwikkelaar hoeft niet zelf te zagen: in ons CI-systeem is het voldoende om een van de scripts (de zogenaamde taak) van de CrossBuilder-tool uit te voeren, die de taak correct uitvoert, rekening houdend met de kenmerken van onze infrastructuur.
Resultaten van
Het artikel is behoorlijk lang geworden, maar dat is onvermijdelijk bij het beschrijven van de modellering van complexe processen. Tot slot wil ik graag onze belangrijkste ideeën kort samenvatten:
- Het doel van het implementeren van DevOps-ideeën in ons bedrijf is om de kosten voor productie en ondersteuning van bedrijfsproducten consequent te verlagen in kwantitatieve termen (manuren of machine-uren, vCPU, RAM, schijf).
- Een manier om de totale ontwikkelingskosten te verlagen is het minimaliseren van de kosten voor het uitvoeren van typische seriële taken: fasen en stappen in het technologische proces.
- Een typische taak is een taak waarvan de oplossing geheel of gedeeltelijk geautomatiseerd is, geen problemen oplevert voor de uitvoerders en geen aanzienlijke arbeidskosten met zich meebrengt.
- Het productieproces bestaat uit fasen. De fasen zijn verdeeld in ondeelbare stappen, die typische taken van verschillende omvang en volume vertegenwoordigen.
- Vanuit geïsoleerde typische taken zijn we gekomen tot complexe technologische ketens en meervoudige modellen van het productieproces, die beschreven kunnen worden door een functioneel IDEF0-model of een eenvoudiger procesdiagram.
- Een procesdiagram is een tabel met de fasen en stappen van een productieproces. Het belangrijkste is dat je met het diagram het hele proces in grote delen kunt bekijken, met de mogelijkheid om in detail te treden.
- Op basis van de proceskaart kunt u beoordelen of er stappen moeten worden uitgevoerd in een bepaald product, verantwoordelijkheidsgebieden afbakenen, contracten sluiten voor de input en output van stappen en de behoefte aan middelen nauwkeuriger inschatten.
In de volgende artikelen gaan we dieper in op de technische hulpmiddelen die we gebruiken om bepaalde technologische fasen op onze kaart te implementeren.
Auteurs van het artikel:
- — Hoofd van de afdeling Automatisering (DevOps) bij Positive Technologies
- — Adjunct-hoofd van de afdeling Automatisering (DevOps) bij Positive Technologies
Bron: www.habr.com
