Ofbylding:
Hoi allegearre! Wy binne automatisearring yngenieurs fan it bedriuw en wy stypje de ûntwikkeling fan 'e produkten fan it bedriuw: wy stypje de heule assemblagepipeline fan it ynsetten fan in rigel fan koade troch ûntwikkelders oant de publikaasje fan klear produkten en lisinsjes op updateservers. Ynformeel wurde wy DevOps-yngenieurs neamd. Yn dit artikel wolle wy prate oer de technologyske stadia fan it softwareproduksjeproses, hoe't wy se sjogge en hoe't wy se klassifisearje.
Fan it materiaal sille jo leare oer de kompleksiteit fan it koördinearjen fan ûntwikkeling fan multyprodukten, oer wat in technologyske kaart is en hoe't it helpt om oplossingen te streamlynjen en te replikearjen, wat binne de wichtichste stadia en stappen fan it ûntwikkelingsproses, hoe binne de gebieten fan ferantwurdlikens tusken DevOps en teams yn ús bedriuw.
Oer Chaos en DevOps
Koartsein omfettet it konsept fan DevOps ûntwikkelingsark en tsjinsten, lykas metoaden en bêste praktiken foar har gebrûk. Litte wy de globale útsûnderje it doel fan 'e ymplemintaasje fan DevOps-ideeën yn ús bedriuw: dit is in konsekwint fermindering fan' e kosten fan produksje en ûnderhâld fan produkten yn kwantitative termen (manoeren as masine-oeren, CPU, RAM, Skiif, ensfh.). De maklikste en meast foar de hân lizzende manier om de totale kosten fan ûntwikkeling op it nivo fan it heule bedriuw te ferminderjen is minimalisearje de kosten fan it útfieren fan typyske seriële taken yn alle stadia fan produksje. Mar wat binne dizze stadia, hoe se te skieden fan it algemiene proses, hokker stappen besteane se út?
As in bedriuw ien produkt ûntwikkelt, is alles min of mear dúdlik: der is meastal in mienskiplike roadmap en ûntwikkelingskema. Mar wat te dwaan as de produktline útwreidet en d'r mear produkten binne? Op it earste each hawwe se ferlykbere prosessen en assemblagelinen, en it spultsje "Fyn X ferskillen" yn logs en skripts begjint. Mar wat as d'r al 5+ projekten binne yn aktive ûntwikkeling en stipe foar ferskate ferzjes ûntwikkele oer ferskate jierren is fereaske? Wolle wy it maksimaal mooglike oantal oplossingen opnij brûke yn produktpipelines of binne wy ree om jild te besteegjen oan in unike ûntwikkeling foar elk?
Hoe kinne jo in lykwicht fine tusken unykens en seriële oplossingen?
Dizze fragen begûnen sûnt 2015 hieltyd faker foar ús op te kommen. It oantal produkten groeide, en wy besochten ús automatisearringsôfdieling (DevOps), dy't de assemblagelinen fan dizze produkten stipe, útwreidzje oant in minimum. Tagelyk woenen wy safolle mooglik oplossingen replisearje tusken produkten. Ommers, wêrom dogge itselde ding yn tsien produkten op ferskate manieren?
Untwikkelingsdirekteur: "Jongens, kinne wy op ien of oare manier evaluearje wat DevOps docht foar produkten?"
Мы: "Wy witte it net, wy hawwe sa'n fraach net steld, mar hokker yndikatoaren moatte wurde beskôge?"
Untwikkelingsdirekteur: "Wa wit! Tinke…"
Lykas yn dy ferneamde film: "Ik bin yn in hotel! .." - "Uh ... Kinsto my de wei wize?" By besinning kamen wy ta de konklúzje dat wy earst beslute moatte oer de einstân fan de produkten; dit waard ús earste doelpunt.
Dus, hoe analysearje jo in tsiental produkten mei frij grutte teams fan 10 oant 200 minsken en bepale mjitbere metriken by it replikearjen fan oplossingen?
1:0 yn it foardiel fan Chaos, as DevOps op 'e skouderblêden
Wy begûnen mei in besykjen om IDEF0-diagrammen en ferskate bedriuwsprosesdiagrammen út 'e BPwin-searje oan te passen. De betizing begon nei it fyfde plein fan 'e folgjende poadium fan it folgjende projekt, en dizze fjilden foar elk projekt kinne wurde tekene yn' e sturt fan in lange python ûnder 50+ stappen. Ik fielde my fertrietlik en woe op 'e moanne gûle - it paste yn 't algemien net.
Typyske produksjetaken
Modellearjen fan produksjeprosessen is in heul komplekse en pynlike taak: jo moatte in protte gegevens sammelje, ferwurkje en analysearje fan ferskate ôfdielingen en produksjeketens. Jo kinne hjir mear oer lêze yn it artikel "".
Doe't wy ús produksjeproses begûnen te modellearjen, hienen wy in spesifyk doel - om oan elke meiwurker dy't belutsen is by de ûntwikkeling fan 'e produkten fan ús bedriuw en oan projektmanagers oer te bringen:
- hoe produkten en har komponinten, begjinnend fan 'e commit fan in rigel koade, de klant berikke yn' e foarm fan ynstallearders en updates,
- hokker middels wurde levere foar elke faze fan produksje fan produkten,
- hokker tsjinsten binne belutsen by elke faze,
- hoe't de gebieten fan ferantwurdlikens foar elke etappe wurde ôfstimd,
- hokker kontrakten besteane by de yn- en útgong fan elke poadium.
Troch op de ôfbylding te klikken sil it yn folsleine grutte iepenje
Us wurk yn it bedriuw is ferdield yn ferskate funksjonele gebieten. De rjochting fan 'e ynfrastruktuer is dwaande mei it optimalisearjen fan' e wurking fan alle "izeren" middels fan 'e ôfdieling, en ek de automatisearring fan' e ynset fan firtuele masines en it miljeu op har. De rjochting fan tafersjoch leveret 24/7 tsjinstprestaasjeskontrôle; wy jouwe ek tafersjoch as in tsjinst foar ûntwikkelders. De workflow-rjochting jout teams ark om ûntwikkelings- en testprosessen te behearjen, de steat fan 'e koade te analysearjen en analyse te krijen oer projekten. En úteinlik leveret de webdev-rjochting de publikaasje fan releases op 'e GUS- en FLUS-fernijingsservers, lykas ek de lisinsje fan produkten mei de LicenseLab-tsjinst. Om de produksjepipeline te stypjen, sette en ûnderhâlde wy in protte ferskillende stipetsjinsten foar ûntwikkelders (jo kinne harkje nei ferhalen oer guon fan har op âlde meetups: и). Wy ûntwikkelje ek ynterne automatisearring ark, ynklusyf .
Yn 'e ôfrûne fiif jier hat ús wurk in protte fan itselde type en routine operaasjes sammele, en ús ûntwikkelders fan oare ôfdielingen komme benammen út' e saneamde typyske taken, wêrfan de oplossing folslein of foar in part automatisearre is, feroarsake gjin swierrichheden foar artysten en fereasket gjin signifikante hoemannichten wurk. Tegearre mei de liedende gebieten, wy analysearre sokke taken en wienen by steat om te identifisearjen yndividuele kategoryen fan wurk, of produksje stappen, de stadia waarden ferdield yn ûndielbere stappen, en ferskate stadia add up produksje proses keten.
It ienfâldichste foarbyld fan in technologyske keten is de stadia fan gearstalling, ynset en testen fan elk fan ús produkten binnen it bedriuw. Op syn beurt bestiet bygelyks it boustadium út in protte aparte typyske stappen: boarnen downloade fan GitLab, ôfhinklikens en biblioteken fan tredden tariede, ienheidstesten en statyske koade-analyze, in buildskript útfiere op GitLab CI, artefakten publisearje yn it repository op Artifactory en generaasje fan release-notysjes fia ús ynterne ChangelogBuilder-ark.
Jo kinne lêze oer typyske DevOps-taken yn ús oare artikels oer Habré: ""En"".
In protte typyske produksjeketen foarmje fabrikaazje proses. De standert oanpak foar it beskriuwen fan prosessen is om funksjonele IDEF0-modellen te brûken.
In foarbyld fan it modellearjen fan in CI-produksjeproses
Wy hawwe spesjaal omtinken jûn oan de ûntwikkeling fan standertprojekten foar in trochgeande yntegraasjesysteem. Dit makke it mooglik om te berikken de ienwurding fan projekten, markearje de saneamde release build skema mei promoasjes.
Hjir is hoe't it wurket. Alle projekten sjogge typysk: se omfetsje de konfiguraasje fan gearkomsten dy't falle yn 'e snapshot-repository by Artifactory, wêrnei't se wurde ynset en testen op testbanken, en dan promovearje nei it release-repository. De Artifactory-tsjinst is in ienich distribúsjepunt foar alle build-artefakten tusken teams en oare tsjinsten.
As wy ús releaseskema sterk ferienfâldigje en generalisearje, dan omfettet it de folgjende stappen:
- cross-platform produkt gearstalling,
- ynset foar testbanken,
- funksjonele en oare tests útfiere,
- it befoarderjen fan testte builds om repositories by Artifactory frij te litten,
- publikaasje fan release builds op update-tsjinners,
- levering fan gearkomsten en updates foar produksje,
- it lansearjen fan de ynstallaasje en it bywurkjen fan it produkt.
Bygelyks, beskôgje it technologyske model fan dizze typyske release skema (hjirnei gewoan Model) yn 'e foarm fan in funksjoneel IDEF0 model. It wjerspegelet de wichtichste stadia fan ús CI-proses. IDEF0 modellen brûke de saneamde ICOM notaasje (Input-Control-Output-Mechanism) om te beskriuwen hokker middels wurde brûkt yn elke faze, basearre op hokker regels en easken wurk wurdt útfierd, wat is de útfier, en hokker meganismen, tsjinsten of minsken útfiere in bepaald stadium.
Troch op de ôfbylding te klikken sil it yn folsleine grutte iepenje
As regel is it makliker om de beskriuwing fan prosessen yn funksjonele modellen te ûntbinen en te detaillearjen. Mar as it oantal eleminten groeit, wurdt it hieltyd dreger om der wat yn te begripen. Mar yn echte ûntwikkeling binne d'r ek auxiliary stadia: tafersjoch, sertifisearring fan produkten, automatisearring fan wurk prosessen, en oaren. It is fanwege it skaalfergruttingsprobleem dat wy dizze beskriuwing ferlitten hawwe.
Geboorte fan hope
Yn ien boek kamen wy âlde Sovjetkaarten tsjin dy't technologyske prosessen beskriuwe (dy't, trouwens, hjoed noch brûkt wurde by in protte steatsbedriuwen en universiteiten). Wachtsje, wachtsje, want wy hawwe ek in workflow!.. D'r binne stadia, resultaten, metriken, easken, yndikatoaren, ensfh. Der wie in gefoel: "Dit is it! Wy hawwe de juste tried fûn, it is tiid om it goed te lûken!
Yn in ienfâldige tabel hawwe wy besletten produkten op te nimmen troch kolommen, en technologyske stadia en produktpipeline stappen foar rigen. Mylpalen binne wat grut, lykas in produktboustap. En stappen binne wat lytser en mear detaillearre, lykas de stap fan it downloaden fan de boarnekoade nei de build-tsjinner of de stap fan it kompilearjen fan de koade.
Op 'e krusingen fan' e rigen en kolommen fan 'e kaart sette wy de statussen foar in spesifyk poadium en produkt del. Foar statusen waard in set fan steaten definiearre:
- Gjin ynformaasje - of net geskikt. It is needsaaklik om de fraach nei in poadium yn it produkt te analysearjen. Of de analyze is al útfierd, mar it poadium is op it stuit net nedich of is net ekonomysk terjochte.
- Utsteld - of net relevant op it stuit. In poadium yn de pipeline is nedich, mar der binne gjin krêften foar útfiering dit jier.
- Plannen. It poadium is pland foar útfiering dit jier.
- Implementearre. It poadium yn 'e pipeline wurdt útfierd yn it fereaske folume.
It ynfoljen fan 'e tabel begon projekt foar projekt. Earst waarden de stadia en stappen fan ien projekt klassifisearre en har statusen waarden opnommen. Doe namen se it folgjende projekt, fêstigen de statusen deryn en foegen de stadia en stappen ta dy't yn eardere projekten ûntbrekke. As resultaat krigen wy de stadia en stappen fan ús heule produksjepipeline en har statusen yn in spesifyk projekt. It die bliken wat te fergelykjen mei de kompetinsjematrix foar produktpipeline. Wy neamden sa'n matrix in technologyske kaart.
Mei help fan de technologyske kaart koördinearje wy metrologysk ferstannich mei de teams de wurkplannen foar it jier en de doelen dy't wy mei-inoar realisearje wolle: hokker stadia wy dit jier oan it projekt tafoegje, en hokker litte wy foar letter. Ek yn 'e rin fan it wurk kinne wy ferbetterings hawwe yn' e stadia dy't wy hawwe foltôge foar mar ien produkt. Dan wreidzje wy ús kaart út en yntrodusearje dizze ferbettering as in poadium as in nije stap, dan analysearje wy foar elk produkt en fine wy de helberens fan it replikearjen fan de ferbettering.
Se kinne tsjin ús beswier meitsje: “Dit is fansels allegear goed, allinnich mei de tiid wurdt it oantal stappen en etappes ûnferbidlik grut. Hoe te wêzen?
Wy hawwe standert en frij folsleine beskriuwingen yntrodusearre fan 'e easken foar elke etappe en stap, sadat se troch elkenien binnen it bedriuw op deselde manier wurde begrepen. Nei ferrin fan tiid, as ferbetteringen wurde yntrodusearre, kin in stap wurde opnomd yn in oare poadium of stap, en dan sille se "ynstoarte". Tagelyk passe alle easken en technologyske nuânses yn 'e easken fan' e generalisearjende poadium of stap.
Hoe kinne jo it effekt fan replikearjende oplossingen evaluearje? Wy brûke in ekstreem ienfâldige oanpak: wy jouwe de earste kapitaalkosten foar de ymplemintaasje fan in nije poadium ta oan jierlikse algemiene produktkosten, en diele dan troch alles by it replikearjen.
Dielen fan de ûntwikkeling binne al werjûn as mylpalen en stappen op de kaart. Wy kinne ynfloed op de fermindering fan 'e kosten fan it produkt troch de ynfiering fan automatisearring foar typyske stadia. Dêrnei beskôgje wy de feroaringen yn kwalitative skaaimerken, kwantitative metriken en de winst ûntfongen troch de teams (yn man-oeren of masine-oeren fan besparring).
Technologyske kaart fan it produksjeproses
As wy al ús stadia en stappen nimme, kodearje se mei tags en útwreidzje se yn ien keatling, dan sil it heul lang en ûnbegryplik blike te wêzen (gewoan de "python-sturt" dêr't wy oer praat hawwe oan it begjin fan it artikel) :
[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 binne de stadia fan it bouwen fan produkten [Build], ynsette se om tsjinners te testen [Deploy], testen [Test], it befoarderjen fan builds om repositories frij te meitsjen basearre op de resultaten fan testen [Promovearje], generearje en publisearje lisinsjes [License], publisearjen [ Publisearje] op de GUS update tsjinner en levering oan FLUS update tsjinners, ynstallaasje en bywurkjen fan produkt ûnderdielen op de klant syn ynfrastruktuer mei help fan Product Configuration Management [Ynstallearje], likegoed as kolleksje fan telemetry [Telemetry] út ynstallearre produkten.
Njonken har kinne aparte stadia ûnderskieden wurde: tafersjoch op ynfrastruktuer [InfMonitoring], ferzje fan boarnekoade [SourceCodeControl], tarieding op bouwe omjouwing [Prepare], projektbehear [Workflow], teams mei kommunikaasjemiddels [Kommunikaasje], produktsertifikaasje [ Sertifikaasje] en it garandearjen fan selsfoldwaan fan CI-prosessen [CISelfSufficiency] (bygelyks ûnôfhinklikens fan gearkomsten fan it ynternet). Tsientallen stappen yn ús prosessen sille net iens wurde beskôge, om't se heul spesifyk binne.
It sil folle makliker wêze om it heule produksjeproses te begripen en te sjen as it yn 'e foarm wurdt presintearre technologyske map; dit is in tabel dêr't de yndividuele produksje stadia en decomposed stappen fan it Model binne skreaun yn rigen, en yn kolommen in beskriuwing fan wat wurdt dien op elke poadium of stap. De wichtichste klam wurdt lein op 'e middels dy't elke poadium leverje, en de ôfskieding fan ferantwurdlikensgebieten.
De kaart foar ús is in soarte fan klassifikaasje. It wjerspegelet de grutte technologyske dielen fan 'e produksje fan produkten. Mei tank oan it waard it makliker foar ús automatisearringsteam om te ynteraksje mei ûntwikkelders en tegearre de ymplemintaasje fan automatisearringsstadia te plannen, en ek te begripen hokker arbeidskosten en middels (minsklik en hardware) dêrfoar nedich binne.
Binnen ús bedriuw wurdt de kaart automatysk oanmakke út 'e jinja-sjabloan as in gewoane HTML-bestân, en dan upload nei de GitLab Pages-tsjinner. In skermôfbylding mei in foarbyld fan in folslein oanmakke kaart kin wurde besjoen .
Troch op de ôfbylding te klikken sil it yn folsleine grutte iepenje
Koartsein is de technologyske kaart in generalisearre byld fan it produksjeproses, dat dúdlik klassifisearre blokken mei typyske funksjonaliteit reflektearret.
Struktuer fan ús road map
De kaart bestiet út ferskate dielen:
- Titelgebiet - hjir is in algemiene beskriuwing fan 'e kaart, basisbegripen wurde yntrodusearre, de wichtichste boarnen en resultaten fan it produksjeproses wurde definieare.
- Dashboard - hjir kinne jo de werjefte fan gegevens foar yndividuele produkten kontrolearje, in gearfetting fan 'e ymplementearre stadia en stappen yn it algemien foar alle produkten wurdt levere.
- Technyske kaart - in tabelfoarmige beskriuwing fan it technologyske proses. Op de kaart:
- alle stadia, stappen en harren koades wurde jûn;
- koarte en folsleine beskriuwingen fan 'e stadia wurde jûn;
- de ynputmiddels en tsjinsten dy't yn elke faze brûkt wurde wurde oanjûn;
- de resultaten fan elke etappe en in aparte stap wurde oanjûn;
- it gebiet fan ferantwurdlikens foar elke poadium en stap wurdt oanjûn;
- de technyske middels, lykas HDD (SSD), RAM, vCPU, en de man-oeren dy't nedich binne om it wurk op dit poadium te stypjen, sawol op it hjoeddeiske momint - in feit, en yn 'e takomst - in plan, binne bepaald;
- foar elk produkt wurdt oanjûn hokker technologyske stadia as stappen dêrfoar binne ymplementearre, pland foar ymplemintaasje, irrelevant of net ymplementearre.
Beslútfoarming basearre op de technologyske kaart
Nei it ûndersiikjen fan 'e kaart is it mooglik om guon aksjes te nimmen - ôfhinklik fan' e rol fan 'e meiwurker yn it bedriuw (ûntwikkelingsmanager, produktmanager, ûntwikkelder of tester):
- begripe hokker stadia ûntbrekke yn in echt produkt of projekt, en beoardielje de needsaak foar har ymplemintaasje;
- bepale de gebieten fan ferantwurdlikens tusken ferskate ôfdielings as se wurkje op ferskate stadia;
- oerienkomst oer kontrakten by de yn- en útgongen fan 'e poadia;
- yntegrearje jo wurkfaze yn it algemiene ûntwikkelingsproses;
- mear sekuer beoardielje de needsaak foar middels dy't jouwe elk fan 'e stadia.
Gearfetting fan al it boppesteande
De routing is alsidich, útwreidber en maklik te ûnderhâlden. It is folle makliker om in beskriuwing fan prosessen yn dizze foarm te ûntwikkeljen en te ûnderhâlden as yn in strang akademysk IDEF0-model. Derneist is in tabelbeskriuwing ienfâldiger, fertrouder en better strukturearre as in funksjoneel model.
Foar de technyske ymplemintaasje fan 'e stappen hawwe wy in spesjaal ynterne ark CrossBuilder - in laach ark tusken CI-systemen, tsjinsten en ynfrastruktuer. De ûntwikkelder hoecht syn fyts net te snijen: yn ús CI-systeem is it genôch om ien fan 'e skripts (de saneamde taak) fan' e CrossBuilder-ark út te fieren, dy't it korrekt sil útfiere, rekken hâldend mei de funksjes fan ús ynfrastruktuer .
Resultaten
It artikel blykte frij lang te wêzen, mar dit is ûnûntkomber by it beskriuwen fan it modeljen fan komplekse prosessen. Oan 'e ein wol ik ús haadideeën koart reparearje:
- It doel fan it ymplementearjen fan DevOps-ideeën yn ús bedriuw is om de kosten fan produksje en ûnderhâld fan 'e produkten fan it bedriuw konsekwint te ferminderjen yn kwantitative termen (manoeren as masine-oeren, vCPU, RAM, Disk).
- De manier om de totale kosten fan ûntwikkeling te ferminderjen is om de kosten fan it útfieren fan typyske seriële taken te minimalisearjen: stadia en stappen fan it technologyske proses.
- In typyske taak is in taak wêrfan de oplossing folslein of foar in part automatisearre is, gjin swierrichheden feroarsaket foar artysten en gjin signifikante arbeidskosten fereasket.
- It produksjeproses bestiet út stadia, de stadia binne ferdield yn ûndielbere stappen, dy't typyske taken binne fan ferskate skaal en omfang.
- Fan disparate typyske taken binne wy kommen ta komplekse technologyske keatlingen en modellen op meardere nivo's fan it produksjeproses, dy't kinne wurde beskreaun troch in funksjoneel IDEF0-model of in ienfâldiger technologyske kaart.
- De technologyske kaart is in tabelfoarmige werjefte fan 'e stadia en stappen fan it produksjeproses. It wichtichste ding: de kaart lit jo it hiele proses yn syn gehiel sjen, yn grutte stikken mei de mooglikheid om se te detaillearjen.
- Op grûn fan 'e technologyske kaart is it mooglik om de needsaak te beoardieljen om stadia yn in bepaald produkt yn te fieren, gebieten fan ferantwurdlikens te definiearjen, kontrakten iens te meitsjen by de yn- en útgongen fan stadia, en de needsaak foar middels krekter te beoardieljen.
Yn 'e folgjende artikels sille wy yn mear detail beskriuwe hokker technyske ark wurde brûkt om bepaalde technologyske stadia op ús kaart út te fieren.
Artikel skriuwers:
- - Head of Automation (DevOps) by Positive Technologies
- - Deputearre Head of Automation Department (DevOps) by Positive Technologies
Boarne: www.habr.com