Stærð:
Hæ allir! Við erum sjálfvirkniverkfræðingar frá fyrirtækinu og við styðjum þróun á vörum fyrirtækisins: við styðjum alla samsetningarleiðslan frá því að forritarar hafa framkvæmt kóðalínu til útgáfu fullunnar vörur og leyfi á uppfærsluþjónum. Óformlega erum við kölluð DevOps verkfræðingar. Í þessari grein viljum við tala um tæknileg stig hugbúnaðarframleiðsluferlisins, hvernig við sjáum þau og hvernig við flokkum þau.
Af efninu lærir þú um hversu flókið er að samræma fjölvöruþróun, um hvað tæknikort er og hvernig það hjálpar til við að hagræða og endurtaka lausnir, hver eru helstu stig og skref þróunarferlisins, hvernig eru ábyrgðarsviðin. milli DevOps og teyma í fyrirtækinu okkar.
Um Chaos og DevOps
Í stuttu máli, hugmyndin um DevOps felur í sér þróunarverkfæri og þjónustu, svo og aðferðafræði og bestu starfsvenjur fyrir notkun þeirra. Við skulum taka út hið alþjóðlega markið frá innleiðingu DevOps hugmynda í fyrirtækinu okkar: þetta er stöðug lækkun á kostnaði við framleiðslu og viðhald á vörum miðað við magn (vinnustundir eða vélartímar, örgjörvi, vinnsluminni, diskur osfrv.). Auðveldasta og augljósasta leiðin til að draga úr heildarkostnaði við þróun á stigi alls fyrirtækisins er lágmarka kostnað við að framkvæma dæmigerð raðverkefni á öllum stigum framleiðslunnar. En hver eru þessi stig, hvernig á að aðgreina þau frá hinu almenna ferli, í hvaða skrefum eru þau?
Þegar fyrirtæki þróar eina vöru er allt meira og minna ljóst: það er venjulega sameiginlegt vegakort og þróunarkerfi. En hvað á að gera þegar vörulínan stækkar og vörurnar eru fleiri? Við fyrstu sýn eru þeir með svipaða ferla og samsetningarlínur og „finna X munur“ leikurinn í annálum og skriftum hefst. En hvað ef það eru nú þegar 5+ verkefni í virkri þróun og þörf er á stuðningi við nokkrar útgáfur sem þróaðar hafa verið á nokkrum árum? Viljum við endurnýta sem mestan fjölda lausna í vöruleiðslum eða erum við tilbúin að eyða peningum í einstaka þróun fyrir hverja?
Hvernig á að finna jafnvægi á milli sérstöðu og raðlausna?
Þessar spurningar fóru að vakna fyrir okkur æ oftar síðan 2015. Fjöldi vara jókst og við reyndum að stækka sjálfvirknideild okkar (DevOps), sem styður færiband þessara vara, í lágmarki. Á sama tíma vildum við endurtaka sem flestar lausnir á milli vara. Eftir allt saman, hvers vegna gera það sama í tíu vörum á mismunandi hátt?
Þróunarstjóri: "Strákar, getum við einhvern veginn metið hvað DevOps gerir fyrir vörur?"
Við: "Við vitum það ekki, við spurðum ekki slíkrar spurningar, en hvaða vísbendingar ætti að hafa í huga?"
Þróunarstjóri: "Hver veit! Hugsaðu…”
Eins og í þeirri frægu mynd: "Ég er á hóteli! .." - "Uh ... Geturðu vísað mér leiðina?" Við umhugsun komumst við að þeirri niðurstöðu að við þurfum fyrst að taka ákvörðun um lokaástand vörunnar; þetta varð fyrsta markið okkar.
Svo, hvernig greinir þú tugi vara með nokkuð stórum teymum frá 10 til 200 manns og ákvarðar mælanlegar mælingar þegar þú endurgerir lausnir?
1:0 í vil Chaos, eða DevOps á herðablöðunum
Við byrjuðum á því að reyna að beita IDEF0 skýringarmyndum og ýmsum viðskiptaferlamyndum úr BPwin röðinni. Ruglið hófst eftir fimmta reit næsta áfanga næsta verkefnis og hægt er að teikna þessa reiti fyrir hvert verkefni í skottið á löngum python undir 50+ þrepum. Mér fannst leiðinlegt og langaði að grenja að tunglinu - það passaði almennt ekki.
Dæmigert framleiðsluverkefni
Líkanagerð framleiðsluferla er mjög flókið og vandað starf: þú þarft að safna, vinna úr og greina mikið af gögnum frá ýmsum deildum og framleiðslukeðjum. Þú getur lesið meira um þetta í greininni "'.
Þegar við byrjuðum að móta framleiðsluferli okkar höfðum við ákveðið markmið - að koma á framfæri við alla starfsmenn sem taka þátt í þróun á vörum fyrirtækisins okkar og til verkefnastjóranna:
- hvernig vörur og íhlutir þeirra, frá framsetningu kóðalínu, ná til viðskiptavinarins í formi uppsetningar og uppfærslu,
- hvaða fjármagn er veitt fyrir hvert framleiðslustig afurða,
- hvaða þjónustu er um að ræða á hverju stigi,
- hvernig ábyrgðarsvið hvers stigs eru afmörkuð,
- hvaða samningar eru fyrir hendi við inngang og útgang hvers stigs.
Með því að smella á myndina opnast hún í fullri stærð.
Starf okkar í fyrirtækinu er skipt í nokkur starfssvið. Stefna innviða er þátt í hagræðingu á rekstri allra "járn" auðlinda deildarinnar, svo og sjálfvirkni á dreifingu sýndarvéla og umhverfið á þeim. Stefna eftirlits veitir 24/7 þjónustuframmistöðustjórnun; Við bjóðum einnig upp á eftirlit sem þjónustu fyrir þróunaraðila. Verkflæðisstefnan veitir teymum verkfæri til að stjórna þróunar- og prófunarferlum, greina stöðu kóðans og fá greiningar á verkefnum. Og að lokum veitir webdev stefnan útgáfu útgáfur á GUS og FLUS uppfærsluþjónum, sem og leyfisveitingu á vörum sem nota LicenseLab þjónustuna. Til að styðja við framleiðslupípuna setjum við upp og viðhaldum mörgum mismunandi stuðningsþjónustu fyrir þróunaraðila (þú getur hlustað á sögur um sumar þeirra á gömlum fundum: и). Við þróum einnig innri sjálfvirkniverkfæri, þar á meðal .
Undanfarin fimm ár hefur í starfi okkar safnast upp mikið af sömu tegund og venjubundnum rekstri og koma þróunaraðilar okkar úr öðrum deildum aðallega úr s.k. dæmigerð verkefni, þar sem lausnin er að fullu eða að hluta sjálfvirk, veldur ekki erfiðleikum fyrir flytjendur og krefst ekki umtalsverðrar vinnu. Ásamt fremstu sviðum greindum við slík verkefni og gátum greint einstaka starfsflokka, eða framleiðsluþrep, þrepunum var skipt í óskiptanleg þrep, og nokkur stig leggjast saman framleiðsluferliskeðju.
Einfaldasta dæmið um tæknikeðju eru stig samsetningar, dreifingar og prófunar á hverri vöru okkar innan fyrirtækisins. Aftur á móti samanstendur byggingarstigið til dæmis af mörgum aðskildum dæmigerðum skrefum: að hlaða niður heimildum frá GitLab, undirbúa ósjálfstæði og þriðja aðila bókasöfn, einingaprófun og kyrrstöðukóðagreiningu, framkvæma byggingarhandrit á GitLab CI, birta gripi í geymslunni á Artifactory og gerð útgáfuskýringa í gegnum innra ChangelogBuilder tólið okkar.
Þú getur lesið um dæmigerð DevOps verkefni í öðrum greinum okkar um Habré: ""Og"'.
Margar dæmigerðar framleiðslukeðjur myndast framleiðsluferli. Hefðbundin nálgun við að lýsa ferlum er að nota hagnýt IDEF0 líkön.
Dæmi um líkan af CI framleiðsluferli
Við lögðum sérstaka áherslu á þróun staðlaðra verkefna fyrir samfellt samþættingarkerfi. Þetta gerði það mögulegt að ná sameiningu verkefna, undirstrika svokallaða slepptu byggingarkerfi með kynningum.
Svona virkar það. Öll verkefni líta dæmigerð út: þau fela í sér uppsetningu samsetninga sem falla inn í skyndimyndageymsluna hjá Artifactory, eftir það eru þær settar á markað og prófaðar á prófunarbekkjum og síðan færðar í útgáfugeymsluna. Artifactory þjónustan er einn dreifingarstaður fyrir alla smíðisgripi milli teyma og annarra þjónustu.
Ef við einföldum og alhæfum útgáfukerfi okkar til muna, þá inniheldur það eftirfarandi skref:
- vörusamsetning á vettvangi,
- dreifing til að prófa bekki,
- keyra virkni og önnur próf,
- að kynna prófaðar byggingar til að gefa út geymslur hjá Artifactory,
- birting útgáfubygginga á uppfærsluþjónum,
- afhendingu samsetningar og uppfærslur á framleiðslu,
- hefja uppsetningu og uppfærslu vörunnar.
Við skulum skoða, sem dæmi, tæknilega líkanið af þessu dæmigerða útgáfukerfi (hér á eftir einfaldlega nefnt líkanið) í formi hagnýts IDEF0 líkans. Það endurspeglar helstu stig CI ferli okkar. IDEF0 módel nota svokallaða ICOM merking (Input-Control-Output-Mechanism) til að lýsa hvaða auðlindir eru notaðar á hverju stigi, byggt á því hvaða reglur og kröfur vinna er framkvæmt, hver er framleiðsla og hvaða kerfi, þjónusta eða fólk útfærir tiltekið stig.
Með því að smella á myndina opnast hún í fullri stærð.
Að jafnaði er auðveldara að sundra og ítarlega lýsingu á ferlum í hagnýtum líkönum. En eftir því sem þáttunum fjölgar verður erfiðara og erfiðara að skilja eitthvað í þeim. En í raunverulegri þróun eru líka aukaþrep: eftirlit, vottun vöru, sjálfvirkni vinnuferla og fleira. Það er vegna stærðarvandans sem við hættum við þessa lýsingu.
Fæðing vonar
Í einni bók rákumst við á gömul sovésk kort sem lýsa tæknilegum ferlum (sem, við the vegur, eru enn notuð í dag í mörgum ríkisfyrirtækjum og háskólum). Bíddu, bíddu, því við erum líka með verkflæði!.. Það eru stig, niðurstöður, mælikvarðar, kröfur, vísbendingar, og svo framvegis og svo framvegis... Af hverju ekki að reyna að nota flæðiseðla líka á vöruleiðslur okkar? Það var tilfinning: „Þetta er það! Við höfum fundið rétta þráðinn, það er kominn tími til að draga hann vel!
Í einfaldri töflu ákváðum við að skrá vörur eftir dálkum og tæknistigum og vöruleiðslum skrefum eftir röðum. Áfangar eru eitthvað stórt, eins og vörubyggingarskref. Og skref eru eitthvað minni og ítarlegri, eins og skrefið að hlaða niður frumkóðann á byggingarþjóninn eða skrefið að setja saman kóðann.
Á mótum raða og dálka á kortinu setjum við stöður fyrir ákveðið stig og vöru. Fyrir stöður var sett af ríkjum skilgreint:
- Engar upplýsingar - eða óviðeigandi. Nauðsynlegt er að greina eftirspurn eftir stigi í vörunni. Annaðhvort hefur greiningin þegar farið fram, en stigið er ekki þörf eins og er eða er ekki efnahagslega réttlætanlegt.
- Frestað - eða ekki viðeigandi í augnablikinu. Það þarf áfanga í pípunum en ekki eru kraftar til framkvæmda á þessu ári.
- Planað. Stefnt er að framkvæmdum á þessu ári.
- Framkvæmt. Stigið í leiðslunni er útfært í tilskildu magni.
Að fylla út töfluna hófst verkefni fyrir verkefni. Fyrst voru stig og skref eins verkefnis flokkuð og staða þeirra skráð. Síðan tóku þeir næsta verkefni, lagfærðu stöðurnar í því og bættu við þeim áföngum og skrefum sem vantaði í fyrri verkefni. Fyrir vikið fengum við stig og þrep allrar framleiðsluleiðslu okkar og stöðu þeirra í tilteknu verkefni. Það reyndist eitthvað svipað og vöruleiðsla hæfni fylki. Við kölluðum slíkt fylki tæknikort.
Með hjálp tæknikortsins erum við efnislega sammála teymunum um starfsáætlanir ársins og markmiðin sem við viljum ná saman: hvaða áföngum við bætum við verkefnið á þessu ári og hverjum við skilum eftir til síðar. Eins og við vinnum gætum við séð endurbætur á skrefum sem við höfum lokið fyrir aðeins eina vöru. Síðan stækkum við kortið okkar og kynnum þessa endurbót sem áfanga eða nýtt skref, síðan gerum við greiningu fyrir hverja vöru og komumst að raunhæfni þess að endurtaka umbæturnar.
Þeir kunna að mótmæla okkur: „Þetta er auðvitað allt gott, aðeins með tímanum verður fjöldi skrefa og stiga óhóflega stór. Hvernig á að vera?
Við höfum tekið upp staðlaðar og nokkuð fullkomnar lýsingar á kröfum fyrir hvert þrep og þrep þannig að allir innan fyrirtækisins skilji þær á sama hátt. Með tímanum, eftir því sem endurbætur eru kynntar, getur skref fallið inn í annað stig eða skref og þá munu þau "hrynja". Á sama tíma passa allar kröfur og tæknileg blæbrigði inn í kröfur alhæfingarstigsins eða þrepsins.
Hvernig á að meta áhrif þess að endurtaka lausnir? Við notum ákaflega einfalda nálgun: við kennum stofnkostnaði við innleiðingu nýs áfanga til árlegs almenns vörukostnaðar og deilum síðan með öllum við endurgerð.
Hlutar þróunarinnar eru þegar sýndir sem áfangar og skref á kortinu. Við getum haft áhrif á lækkun kostnaðar við vöruna með því að innleiða sjálfvirkni fyrir dæmigerð stig. Eftir það skoðum við breytingar á eigindlegum eiginleikum, megindlegum mælingum og hagnaðinum sem teymin fá (í vinnustundum eða vinnustundum sparnaðar).
Tæknikort af framleiðsluferlinu
Ef við tökum öll stigin okkar og skref, kóðum þau með merkjum og stækkum þau í eina keðju, þá mun það reynast mjög langt og óskiljanlegt (bara „python skottið“ sem við ræddum um í upphafi greinarinnar) :
[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]Þetta eru stigin við að byggja vörur [Build], setja þær inn til að prófa netþjóna [Dreifa], prófa [Prófa], kynna smíði til að gefa út geymslur byggðar á niðurstöðum prófunar [Promote], búa til og birta leyfi [License], birta [ Birta] á GUS uppfærsluþjóninum og afhending á FLUS uppfærsluþjóna, uppsetning og uppfærsla vöruíhluta á innviðum viðskiptavinarins með því að nota vörustillingarstjórnun [Install], sem og söfnun fjarmælinga [Telemetry] frá uppsettum vörum.
Auk þeirra er hægt að greina aðskilin stig: eftirlit með ástandi innviða [InfMonitoring], útgáfu frumkóða [SourceCodeControl], undirbúningur byggingarumhverfis [Undirbúa], verkefnastjórnun [Verkflæði], útvega teymum samskiptaverkfæri [Samskipti], vöruvottun [ vottun] og tryggja sjálfsbjargarviðleitni CI ferla [CISelfSufficiency] (til dæmis sjálfstæði samsetninga frá internetinu). Tugir skrefa í ferlum okkar verða ekki einu sinni teknir til greina, vegna þess að þau eru mjög sértæk.
Það verður miklu auðveldara að skilja og skoða allt framleiðsluferlið ef það er sett fram í formi tæknikort; þetta er tafla þar sem einstök framleiðsluþrep og sundurliðuð skref líkansins eru skrifuð í raðir og í dálkum er lýsing á því sem er gert á hverju stigi eða skrefi. Lögð er megináhersla á þau úrræði sem veita hverjum áfanga og afmörkun ábyrgðarsviða.
Kortið fyrir okkur er eins konar flokkari. Það endurspeglar stóra tæknilega hluta framleiðslu á vörum. Þökk sé því varð það auðveldara fyrir sjálfvirkniteymi okkar að hafa samskipti við þróunaraðila og skipuleggja sameiginlega innleiðingu sjálfvirknistiga, auk þess að skilja hvaða launakostnaður og fjármagn (manna og vélbúnaðar) þarf til þess.
Inni í fyrirtækinu okkar er kortið sjálfkrafa búið til úr jinja sniðmátinu sem venjulegri HTML skrá og síðan hlaðið upp á GitLab Pages netþjóninn. Hægt er að skoða skjáskot með dæmi um fullbúið kort .
Með því að smella á myndina opnast hún í fullri stærð.
Í stuttu máli er tæknikortið almenn mynd af framleiðsluferlinu, sem endurspeglar greinilega flokkaðar blokkir með dæmigerðri virkni.
Uppbygging vegakortsins okkar
Kortið samanstendur af nokkrum hlutum:
- Titilsvæði - hér er almenn lýsing á kortinu, grunnhugtök kynnt, helstu úrræði og niðurstöður framleiðsluferlisins skilgreindar.
- Mælaborð - hér getur þú stjórnað birtingu gagna fyrir einstakar vörur, samantekt á útfærðum stigum og skrefum almennt fyrir allar vörur er veitt.
- Tæknikort - töflulýsing á tækniferlinu. Á kortinu:
- öll stig, skref og kóðar þeirra eru gefin upp;
- stuttar og tæmandi lýsingar á stigunum eru gefnar;
- inntaksauðlindir og þjónusta sem notuð er á hverju stigi eru tilgreind;
- niðurstöður hvers stigs og sérstakts þreps eru sýndar;
- tilgreint er ábyrgðarsvið fyrir hvert stig og skref;
- tæknileg úrræði hafa verið ákvörðuð, til dæmis HDD (SSD), vinnsluminni, vCPU og vinnustundir sem nauðsynlegar eru til að styðja við vinnu á þessu stigi, bæði í augnablikinu - staðreynd og í framtíðinni - áætlun;
- fyrir hverja vöru er tilgreint hvaða tækniþrep eða skref fyrir hana hafa verið innleidd, fyrirhuguð til innleiðingar, óviðkomandi eða ekki innleidd.
Ákvarðanataka byggð á tæknikortinu
Eftir að hafa kynnt þér kortið geturðu gripið til nokkurra aðgerða, allt eftir hlutverki starfsmannsins í fyrirtækinu (þróunarstjóri, vörustjóri, þróunaraðili eða prófari):
- skilja hvaða stig vantar í raunverulega vöru eða verkefni og meta þörfina fyrir framkvæmd þeirra;
- afmarka ábyrgðarsvið milli nokkurra deilda ef þær vinna á mismunandi stigum;
- koma sér saman um samninga við inn- og útgönguleiðir stiganna;
- samþætta vinnustig þitt í heildarþróunarferlinu;
- meta nákvæmara þörfina fyrir úrræði sem veita hvert stig.
Dregið saman allt ofangreint
Leiðin er fjölhæf, stækkanleg og auðvelt að viðhalda henni. Það er miklu auðveldara að þróa og viðhalda lýsingu á ferlum á þessu formi en í ströngu fræðilegu IDEF0 líkani. Að auki er töflulýsing einfaldari, kunnuglegri og betur uppbyggð en hagnýtt líkan.
Fyrir tæknilega útfærslu skrefanna höfum við sérstakt innra tól CrossBuilder - lagverkfæri milli CI kerfa, þjónustu og innviða. Framkvæmdaraðilinn þarf ekki að skera hjólið sitt: í CI kerfinu okkar er nóg að keyra eitt af forskriftunum (svokallað verkefni) CrossBuilder tólsins, sem mun framkvæma það rétt, að teknu tilliti til eiginleika innviða okkar .
Niðurstöður
Greinin reyndist nokkuð löng en það er óhjákvæmilegt þegar lýst er líkanagerð flókinna ferla. Í lokin langar mig að laga helstu hugmyndir okkar í stuttu máli:
- Markmiðið með því að innleiða DevOps hugmyndir í fyrirtækinu okkar er að draga stöðugt úr kostnaði við framleiðslu og viðhald á vörum fyrirtækisins miðað við magn (vinnustundir eða vélartímar, vCPU, vinnsluminni, diskur).
- Leiðin til að draga úr heildarkostnaði við þróun er að lágmarka kostnað við að framkvæma dæmigerð raðverkefni: stig og skref í tækniferlinu.
- Dæmigert verkefni er verkefni þar sem lausnin er að fullu eða að hluta sjálfvirk, veldur ekki erfiðleikum fyrir flytjendur og krefst ekki verulegs launakostnaðar.
- Framleiðsluferlið samanstendur af þrepum, þrepunum er skipt í óskiptanleg skref sem eru dæmigerð verkefni af mismunandi stærðargráðu og umfangi.
- Frá ólíkum dæmigerðum verkefnum höfum við komið að flóknum tæknikeðjum og fjölþrepa líkönum af framleiðsluferlinu, sem hægt er að lýsa með hagnýtu IDEF0 líkani eða einfaldara tæknikorti.
- Tæknikortið er framsetning í töfluformi á stigum og þrepum framleiðsluferlisins. Það mikilvægasta: Kortið gerir þér kleift að sjá allt ferlið í heild sinni, í stórum hlutum með möguleika á að útlista þau.
- Út frá tæknikortinu er hægt að leggja mat á þörfina fyrir að kynna þrep í tiltekinni vöru, afmarka ábyrgðarsvið, semja um samninga við inntak og úttak þrepa og meta nákvæmari þörf fyrir fjármagn.
Í eftirfarandi greinum munum við lýsa nánar hvaða tækniverkfæri eru notuð til að innleiða ákveðin tæknistig á kortinu okkar.
Greinarhöfundar:
- — Yfirmaður sjálfvirkni (DevOps) hjá Positive Technologies
- - Staðgengill Forstöðumaður sjálfvirknideildar (DevOps) hjá Positive Technologies
Heimild: www.habr.com