ProHoster > Blogs > Administrācija > Haosa vadīŔana: lietu sakārtoŔana ar tehnoloģiskās kartes palīdzību

Haosa vadīŔana: lietu sakārtoŔana ar tehnoloģiskās kartes palīdzību

Haosa vadīŔana: lietu sakārtoŔana ar tehnoloģiskās kartes palīdzību

Bilde: Unsplash

Sveiki visiem! Mēs esam uzņēmuma automatizācijas inženieri PozitÄ«vās tehnoloÄ£ijas un mēs atbalstām uzņēmuma produktu izstrādi: mēs atbalstām visu montāžas konveijeru, sākot no izstrādātāju veiktās koda rindas izveides lÄ«dz gatavo produktu un licenču publicÄ“Å”anai atjauninājumu serveros. Neoficiāli mÅ«s sauc par DevOps inženieriem. Å ajā rakstā mēs vēlamies runāt par programmatÅ«ras ražoÅ”anas procesa tehnoloÄ£iskajiem posmiem, kā mēs tos redzam un kā tos klasificējam.

No materiāla uzzināsiet par vairāku produktu izstrādes koordinÄ“Å”anas sarežģītÄ«bu, par to, kas ir tehnoloÄ£iskā karte un kā tā palÄ«dz racionalizēt un atkārtot risinājumus, kādi ir galvenie izstrādes procesa posmi un soļi, kā ir atbildÄ«bas jomas. starp DevOps un mÅ«su uzņēmuma komandām.

Par haosu un DevOps

ÄŖsumā DevOps koncepcija ietver izstrādes rÄ«kus un pakalpojumus, kā arÄ« metodoloÄ£ijas un labāko praksi to izmantoÅ”anai. Izcelsim globālo mērÄ·is no DevOps ideju ievieÅ”anas mÅ«su uzņēmumā: tas ir konsekvents produktu ražoÅ”anas un uzturÄ“Å”anas izmaksu samazinājums kvantitatÄ«vā izteiksmē (cilvēkstundas vai maŔīnu stundas, CPU, RAM, disks utt.). VienkārŔākais un acÄ«mredzamākais veids, kā samazināt kopējās attÄ«stÄ«bas izmaksas visa uzņēmuma lÄ«menÄ«, ir lÄ«dz minimumam samazinot tipisku sērijveida uzdevumu veikÅ”anas izmaksas visos ražoÅ”anas posmos. Bet kādi ir Å”ie posmi, kā tos noŔķirt no vispārējā procesa, no kādiem soļiem tie sastāv?

Kad uzņēmums izstrādā vienu produktu, viss ir vairāk vai mazāk skaidrs: parasti ir kopÄ«gs ceļvedis un attÄ«stÄ«bas shēma. Bet ko darÄ«t, kad preču lÄ«nija paplaÅ”inās un preču ir vairāk? No pirmā acu uzmetiena tiem ir lÄ«dzÄ«gi procesi un montāžas lÄ«nijas, un sākas spēle ā€œAtrast X atŔķirÄ«basā€ žurnālos un skriptos. Bet ko darÄ«t, ja aktÄ«vā attÄ«stÄ«bā jau ir 5+ projekti un nepiecieÅ”ams atbalsts vairākām vairāku gadu laikā izstrādātām versijām? Vai mēs vēlamies atkārtoti izmantot maksimāli iespējamo risinājumu skaitu produktu konveijerā vai esam gatavi tērēt naudu, lai katram izstrādātu unikālu izstrādi?

Kā atrast līdzsvaru starp unikalitāti un sērijveida risinājumiem?

Å ie jautājumi mums sāka rasties arvien biežāk kopÅ” 2015. gada. Produktu skaits pieauga, un mēs centāmies lÄ«dz minimumam paplaÅ”ināt mÅ«su automatizācijas nodaļu (DevOps), kas atbalstÄ«ja Å”o produktu montāžas lÄ«nijas. Tajā paŔā laikā mēs vēlējāmies atkārtot pēc iespējas vairāk risinājumu starp produktiem. Galu galā, kāpēc darÄ«t vienu un to paÅ”u desmit produktos dažādos veidos?

AttÄ«stÄ«bas direktors: "PuiÅ”i, vai mēs varam kaut kā novērtēt, ko DevOps dara produktiem?"

Mēs: "Mēs nezinām, mēs neuzdevām Ŕādu jautājumu, bet kādi rādÄ«tāji bÅ«tu jāņem vērā?"

AttÄ«stÄ«bas direktors: "Kas zina! Padomāā€¦ā€

Kā tajā slavenajā filmā: "Es esmu viesnÄ«cā! .." - "Ak... Vai jÅ«s varat man parādÄ«t ceļu?" Pārdomājot, mēs nonācām pie secinājuma, ka mums vispirms ir jāizlemj par produktu galÄ«gajiem stāvokļiem; Å”is kļuva par mÅ«su pirmo vārtu guvumu.

Tātad, kā analizēt duci produktu ar diezgan lielām komandām no 10 līdz 200 cilvēkiem un noteikt izmērāmus rādītājus, atkārtojot risinājumus?

1:0 par labu Haosam, jeb DevOps uz lāpstiņām

Mēs sākām ar mēģinājumu pielietot IDEF0 diagrammas un dažādas biznesa procesu diagrammas no BPwin sērijas. Apjukums sākās pēc nākamā projekta nākamā posma piektā kvadrāta, un Å”os kvadrātus katram projektam var ievilkt gara pitona astē zem 50+ pakāpieniem. Es jutos skumji un gribēju gaudot uz mēnesi - kopumā tas nederēja.

Tipiski ražoŔanas uzdevumi

RažoÅ”anas procesu modelÄ“Å”ana ir ļoti sarežģīts un rÅ«pÄ«gs darbs: jums ir jāapkopo, jāapstrādā un jāanalizē daudz datu no dažādām nodaļām un ražoÅ”anas ķēdēm. Vairāk par to varat lasÄ«t rakstā "RažoÅ”anas procesu modelÄ“Å”ana IT uzņēmumā'.

Uzsākot ražoÅ”anas procesa modelÄ“Å”anu, mums bija konkrēts mērÄ·is - nodot ikvienam mÅ«su uzņēmuma produktu izstrādē iesaistÄ«tajam darbiniekam un projektu vadÄ«tājiem:

  • kā produkti un to komponenti, sākot no koda rindas ievieÅ”anas, sasniedz klientu instalētāju un atjauninājumu veidā,
  • kādi resursi ir paredzēti katram produktu ražoÅ”anas posmam,
  • kādi pakalpojumi ir iesaistÄ«ti katrā posmā,
  • kā tiek norobežotas atbildÄ«bas jomas katrā posmā,
  • kādi lÄ«gumi pastāv pie katra posma ieejas un izejas.

Haosa vadīŔana: lietu sakārtoŔana ar tehnoloģiskās kartes palīdzību

NoklikŔķinot uz attēla, tas tiks atvērts pilnā izmērā.

MÅ«su darbs uzņēmumā ir sadalÄ«ts vairākās funkcionālās jomās. InfrastruktÅ«ras virziens nodarbojas ar visu departamenta "dzelzs" resursu darbÄ«bas optimizāciju, kā arÄ« virtuālo maŔīnu un vides izvietoÅ”anas automatizāciju uz tām. Monitoringa virziens nodroÅ”ina 24/7 servisa darbÄ«bas kontroli; mēs nodroÅ”inām arÄ« uzraudzÄ«bu kā pakalpojumu izstrādātājiem. DarbplÅ«smas virziens nodroÅ”ina komandām rÄ«kus, lai pārvaldÄ«tu izstrādes un testÄ“Å”anas procesus, analizētu koda stāvokli un iegÅ«tu projektu analÄ«zi. Visbeidzot, webdev virziens nodroÅ”ina izlaidumu publicÄ“Å”anu GUS un FLUS atjaunināŔanas serveros, kā arÄ« produktu licencÄ“Å”anu, izmantojot pakalpojumu LicenseLab. Lai atbalstÄ«tu ražoÅ”anas procesu, mēs izveidojam un uzturam daudzus dažādus atbalsta pakalpojumus izstrādātājiem (stāstus par dažiem no tiem varat klausÄ«ties vecajās sanāksmēs: Op!DevOps! 2016. gads Šø Op!DevOps! 2017. gads). Izstrādājam arÄ« iekŔējos automatizācijas rÄ«kus, t.sk atvērtā pirmkoda risinājumi.

Pēdējo piecu gadu laikā mÅ«su darbā ir uzkrājies daudz viena veida un rutÄ«nas operāciju, un mÅ«su izstrādātāji no citām nodaļām galvenokārt nāk no t.s. tipiski uzdevumi, kura risinājums ir pilnÄ«bā vai daļēji automatizēts, izpildÄ«tājiem nesagādā grÅ«tÄ«bas un neprasa ievērojamus darba apjomus. Kopā ar vadoÅ”ajām jomām mēs analizējām Ŕādus uzdevumus un varējām identificēt atseviŔķas darba kategorijas vai ražoÅ”anas soļi, posmi tika sadalÄ«ti nedalāmos soļos, un vairāki posmi summējas ražoÅ”anas procesa ķēde.

Haosa vadīŔana: lietu sakārtoŔana ar tehnoloģiskās kartes palīdzību

VienkārŔākais tehnoloÄ£iskās ķēdes piemērs ir katra mÅ«su produkta montāžas, izvietoÅ”anas un testÄ“Å”anas posmi uzņēmumā. Savukārt, piemēram, bÅ«vÄ“Å”anas posms sastāv no daudzām atseviŔķām tipiskām darbÄ«bām: avotu lejupielāde no GitLab, atkarÄ«bu un treÅ”o puÅ”u bibliotēku sagatavoÅ”ana, vienÄ«bu testÄ“Å”ana un statiskā koda analÄ«ze, bÅ«vÄ“Å”anas skripta izpilde GitLab CI, artefaktu publicÄ“Å”ana krātuvē Izlaiduma piezÄ«mju artefaktÅ«ra un Ä£enerÄ“Å”ana, izmantojot mÅ«su iekŔējo ChangelogBuilder rÄ«ku.

Par tipiskiem DevOps uzdevumiem varat lasÄ«t citos mÅ«su rakstos par HabrĆ©: "PersonÄ«gā pieredze: kā izskatās mÅ«su nepārtrauktās integrācijas sistēma"Un"Izstrādes procesu automatizācija: kā mēs Ä«stenojām DevOps idejas uzņēmumā Positive Technologies'.

Veidojas daudzas tipiskas ražoÅ”anas ķēdes ražoÅ”anas process. Standarta pieeja procesu aprakstÄ«Å”anai ir funkcionālu IDEF0 modeļu izmantoÅ”ana.

RažoÅ”anas CI procesa modelÄ“Å”anas piemērs

ÄŖpaÅ”u uzmanÄ«bu pievērsām nepārtrauktas integrācijas sistēmas standarta projektu izstrādei. Tas ļāva panākt projektu apvienoÅ”anu, izceļot t.s izlaiduma veidoÅ”anas shēma ar akcijām.

Haosa vadīŔana: lietu sakārtoŔana ar tehnoloģiskās kartes palīdzību

LÅ«k, kā tas darbojas. Visi projekti izskatās tipiski: tajos ir iekļauta to komplektu konfigurācija, kas ietilpst momentuzņēmumu krātuvē vietnē Artifactory, pēc tam tie tiek izvietoti un testēti testa stendos un pēc tam tiek paaugstināti uz izlaiduma repozitoriju. Artifactory pakalpojums ir viens izplatÄ«Å”anas punkts visiem bÅ«vÄ“Å”anas artefaktiem starp komandām un citiem pakalpojumiem.

Ja mēs ievērojami vienkārÅ”ojam un vispārinām mÅ«su izlaiÅ”anas shēmu, tajā ir iekļautas Ŕādas darbÄ«bas:

  • starpplatformu produktu montāža,
  • izvietoÅ”ana testa stendos,
  • funkcionālo un citu testu veikÅ”ana,
  • pārbaudÄ«tu bÅ«vējumu reklamÄ“Å”ana, lai atbrÄ«votu artefaktÅ«ras krātuves,
  • laidiena publicÄ“Å”ana balstās uz atjaunināŔanas serveriem,
  • montāžas un ražoÅ”anas atjauninājumu piegāde,
  • produkta instalÄ“Å”anas un atjaunināŔanas uzsākÅ”ana.

Piemēram, apsveriet Ŕīs tipiskās izlaiÅ”anas shēmas tehnoloÄ£isko modeli (turpmāk vienkārÅ”i Modelis) funkcionāla IDEF0 modeļa veidā. Tas atspoguļo mÅ«su KI procesa galvenos posmus. IDEF0 modeļi izmanto t.s ICOM apzÄ«mējums (Input-Control-Output-Mechanism), lai aprakstÄ«tu, kādi resursi tiek izmantoti katrā posmā, pamatojoties uz kādiem noteikumiem un prasÄ«bām tiek veikts darbs, kāds ir rezultāts un kādi mehānismi, pakalpojumi vai cilvēki Ä«steno konkrētu posmu.

Haosa vadīŔana: lietu sakārtoŔana ar tehnoloģiskās kartes palīdzību

NoklikŔķinot uz attēla, tas tiks atvērts pilnā izmērā.

Parasti procesu aprakstu funkcionālos modeļos ir vieglāk sadalÄ«t un detalizēt. Bet, pieaugot elementu skaitam, kaut ko tajos saprast kļūst arvien grÅ«tāk. Bet reālajā attÄ«stÄ«bā ir arÄ« palÄ«gposmi: uzraudzÄ«ba, produktu sertifikācija, darba procesu automatizācija un citi. MērogoÅ”anas problēmas dēļ mēs atteicāmies no Ŕī apraksta.

Cerības dzimŔana

Vienā grāmatā mēs uzgājām vecās padomju kartes, kurās aprakstÄ«ti tehnoloÄ£iskie procesi (kuras, starp citu, joprojām tiek izmantotas daudzos valsts uzņēmumos un augstskolās). Pagaidiet, pagaidiet, jo mums ir arÄ« darbplÅ«sma!.. Ir posmi, rezultāti, metrika, prasÄ«bas, rādÄ«tāji un tā tālāk, un tā tālāk... Kāpēc gan nepamēģināt izmantot plÅ«smas lapas arÄ« mÅ«su produktu konveijeriem? Bija sajÅ«ta: ā€œÅ Ä« ir tā! Esam atraduÅ”i Ä«sto pavedienu, laiks to labi pavilkt!

VienkārŔā tabulā mēs nolēmām ierakstÄ«t produktus pa kolonnām, bet tehnoloÄ£iskos posmus un produktu cauruļvada posmus pa rindām. Pagrieziena punkti ir kaut kas liels, piemēram, produkta izveides solis. Un soļi ir kaut kas mazāks un detalizētāks, piemēram, avota koda lejupielāde bÅ«vÄ“Å”anas serverÄ« vai koda kompilÄ“Å”anas darbÄ«ba.

Kartes rindu un kolonnu krustpunktos mēs izliekam statusus konkrētam posmam un produktam. Statusiem tika definēta stāvokļu kopa:

  1. Nav informācijas - vai nepiemērota. Ir nepiecieÅ”ams analizēt pieprasÄ«jumu pēc produkta posma. Vai nu analÄ«ze jau ir veikta, bet posms Å”obrÄ«d nav nepiecieÅ”ams vai nav ekonomiski pamatots.
  2. Atlikts - vai Å”obrÄ«d nav aktuāli. Ir nepiecieÅ”ams posms, kas tiek gatavots, taču Å”ogad nav spēku Ä«stenoÅ”anai.
  3. Plānots. Posmu plānots īstenot Ŕogad.
  4. ÄŖstenots. Posms cauruļvadā tiek realizēts vajadzÄ«gajā apjomā.

Tabulas aizpildÄ«Å”ana sākās projektu pēc projekta. Vispirms tika klasificēti viena projekta posmi un soļi un reÄ£istrēti to statusi. Pēc tam viņi uzņēma nākamo projektu, fiksēja tajā esoÅ”os statusus un pievienoja posmus un soļus, kas trÅ«ka iepriekŔējos projektos. Rezultātā mēs ieguvām visa mÅ«su ražoÅ”anas konveijera posmus un posmus un to statusus konkrētā projektā. IzrādÄ«jās kaut kas lÄ«dzÄ«gs produktu cauruļvada kompetences matricai. Mēs Ŕādu matricu nosaucām par tehnoloÄ£isko karti.

Ar tehnoloÄ£iskās kartes palÄ«dzÄ«bu metroloÄ£iski pamatoti saskaņojam ar komandām gada darba plānus un mērÄ·us, ko vēlamies kopÄ«gi sasniegt: kurus posmus Å”ogad pievienojam projektam, bet kurus atstājam uz vēlāku laiku. Tāpat darba gaitā mums var bÅ«t uzlabojumi tajos posmos, kurus esam pabeiguÅ”i tikai vienam produktam. Pēc tam mēs paplaÅ”inām savu karti un ievieÅ”am Å”o uzlabojumu kā posmu vai jaunu soli, pēc tam analizējam katru produktu un noskaidrojam uzlabojuma atkārtoÅ”anas iespējamÄ«bu.

Viņi var mums iebilst: ā€œTas viss, protams, ir labi, tikai ar laiku soļu un posmu skaits kļūs pārmērÄ«gi liels. Kā bÅ«t?

Esam ieviesuÅ”i standarta un diezgan pilnÄ«gus prasÄ«bu aprakstus katram posmam un solim, lai visi uzņēmumā tos saprastu vienādi. Laika gaitā, kad tiek ieviesti uzlabojumi, solis var tikt absorbēts citā posmā vai solÄ«, un tad tie "sabruks". Tajā paŔā laikā visas prasÄ«bas un tehnoloÄ£iskās nianses iekļaujas vispārināŔanas posma vai soļa prasÄ«bās.

Kā novērtēt risinājumu atkārtoÅ”anas efektu? Mēs izmantojam ārkārtÄ«gi vienkārÅ”u pieeju: sākotnējās kapitāla izmaksas jauna posma ievieÅ”anai attiecinām uz ikgadējām vispārējām produkta izmaksām un pēc tam dalām ar visām, veicot replicÄ“Å”anu.

AttÄ«stÄ«bas daļas kartē jau ir parādÄ«tas kā atskaites punkti un soļi. Mēs varam ietekmēt produkta izmaksu samazināŔanu, ievieÅ”ot automatizāciju tipiskajiem posmiem. Pēc tam ņemam vērā izmaiņas kvalitatÄ«vajos raksturlielumos, kvantitatÄ«vos rādÄ«tājos un komandu saņemtajā peļņā (cilvēkstundās vai ietaupÄ«juma maŔīnstundās).

RažoŔanas procesa tehnoloģiskā karte

Ja mēs veiksim visus savus posmus un soļus, iekodējam tos ar tagiem un izvērsim vienā ķēdē, tad tas izrādÄ«sies ļoti garÅ” un nesaprotams (tikai pati ā€œpitona asteā€, par kuru mēs runājām raksta sākumā) :

[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]

Tie ir produktu izveides posmi [Build], to izvietoÅ”ana testÄ“Å”anas serveros [Izvietot], testÄ“Å”ana [Test], bÅ«vējumu veicināŔana, lai atbrÄ«votu krātuvēs, pamatojoties uz testÄ“Å”anas rezultātiem [Promote], licenču [License] Ä£enerÄ“Å”ana un publicÄ“Å”ana, publicÄ“Å”ana [ PublicÄ“Å”ana] GUS atjaunināŔanas serverÄ« un piegāde FLUS atjaunināŔanas serveriem, produkta komponentu instalÄ“Å”ana un atjaunināŔana klienta infrastruktÅ«rā, izmantojot Produkta konfigurācijas pārvaldÄ«bu [Instalēt], kā arÄ« telemetrijas [Telemetrija] apkopoÅ”ana no instalētajiem produktiem.

Papildus tiem var izdalÄ«t atseviŔķus posmus: infrastruktÅ«ras stāvokļa uzraudzÄ«ba [InfMonitoring], pirmkoda versiju veidoÅ”ana [SourceCodeControl], bÅ«vvides sagatavoÅ”ana [Prepare], projektu vadÄ«ba [Workflow], komandu nodroÅ”ināŔana ar komunikācijas rÄ«kiem [Communication], produktu sertifikācija [ Sertifikācija] un KI procesu paÅ”pietiekamÄ«bas nodroÅ”ināŔana [CISelfSuffficiency] (piemēram, mezglu neatkarÄ«ba no interneta). Vairāki desmiti soļu mÅ«su procesos pat netiks izskatÄ«ti, jo tie ir ļoti specifiski.

Būs daudz vieglāk saprast un apskatīt visu ražoŔanas procesu, ja tas būs uzrādīts formā tehnoloģiskā karte; Ŕī ir tabula, kurā rindās ir ierakstīti atseviŔķi Modeļa ražoŔanas posmi un sadalītie soļi, bet kolonnās aprakstīts, kas tiek darīts katrā posmā vai solī. Galvenais uzsvars tiek likts uz resursiem, kas nodroŔina katru posmu, un atbildības jomu norobežoŔanu.

Karte mums ir sava veida klasifikators. Tas atspoguļo produktu ražoÅ”anas lielās tehnoloÄ£iskās daļas. Pateicoties tam, mÅ«su automatizācijas komandai kļuva vieglāk mijiedarboties ar izstrādātājiem un kopÄ«gi plānot automatizācijas posmu ievieÅ”anu, kā arÄ« saprast, kādas darbaspēka izmaksas un resursi (cilvēks un aparatÅ«ra) tam bÅ«s nepiecieÅ”ami.

MÅ«su uzņēmumā karte tiek automātiski Ä£enerēta no jinja veidnes kā parasts HTML fails un pēc tam augÅ”upielādēta GitLab Pages serverÄ«. Var apskatÄ«t ekrānuzņēmumu ar pilnÄ«bā Ä£enerētas kartes piemēru ŠæŠ¾ ссыŠ»ŠŗŠµ.

Haosa vadīŔana: lietu sakārtoŔana ar tehnoloģiskās kartes palīdzību

NoklikŔķinot uz attēla, tas tiks atvērts pilnā izmērā.

ÄŖsāk sakot, tehnoloÄ£iskā karte ir vispārināts ražoÅ”anas procesa attēls, kas atspoguļo skaidri klasificētus blokus ar tipisku funkcionalitāti.

Mūsu ceļa kartes struktūra

Karte sastāv no vairākām daļām:

  1. Virsraksta apgabals - Å”eit ir vispārÄ«gs kartes apraksts, tiek iepazÄ«stināti ar pamatjēdzieniem, definēti galvenie ražoÅ”anas procesa resursi un rezultāti.
  2. Informācijas panelis - Å”eit var kontrolēt atseviŔķu produktu datu attēloÅ”anu, tiek sniegts visu produktu Ä«stenoto posmu un darbÄ«bu kopsavilkums kopumā.
  3. Tehnoloģiskā karte - tehnoloģiskā procesa tabulas apraksts. Uz kartes:
    • doti visi posmi, soļi un to kodi;
    • sniegti Ä«si un pilni posmu apraksti;
    • norādÄ«ti katrā posmā izmantotie ievades resursi un pakalpojumi;
    • norādÄ«ti katra posma un atseviŔķa posma rezultāti;
    • ir norādÄ«ta atbildÄ«bas joma par katru posmu un soli;
    • ir noteikti tehniskie resursi, piemēram, HDD (SSD), operatÄ«vā atmiņa, vCPU, un darba nodroÅ”ināŔanai nepiecieÅ”amās darba stundas Å”ajā posmā gan Å”obrÄ«d - fakts, gan nākotnē - plāns;
    • katram produktam ir norādÄ«ts, kuri tehnoloÄ£iskie posmi vai soļi tai ir Ä«stenoti, plānoti ievieÅ”anai, neatbilstoÅ”i vai nav ieviesti.

Lēmumu pieņemÅ”ana, pamatojoties uz tehnoloÄ£isko karti

Pēc kartes apskatÄ«Å”anas ir iespējams veikt dažas darbÄ«bas ā€“ atkarÄ«bā no darbinieka lomas uzņēmumā (izstrādes vadÄ«tājs, produktu vadÄ«tājs, izstrādātājs vai testētājs):

  • saprast, kādi posmi trÅ«kst reālā produktā vai projektā, un novērtēt to ievieÅ”anas nepiecieÅ”amÄ«bu;
  • norobežot atbildÄ«bas jomas starp vairākām nodaļām, ja tās strādā dažādos posmos;
  • vienojas par lÄ«gumiem pie estrādes ieejām un izejām;
  • integrēt savu darba posmu kopējā attÄ«stÄ«bas procesā;
  • precÄ«zāk izvērtēt resursu nepiecieÅ”amÄ«bu, kas nodroÅ”ina katru no posmiem.

Apkopojot visu iepriekÅ” minēto

MarÅ”ruts ir daudzpusÄ«gs, paplaÅ”ināms un viegli kopjams. Šādā formā ir daudz vieglāk izstrādāt un uzturēt procesu aprakstu nekā stingrā akadēmiskā IDEF0 modelÄ«. Turklāt tabulas apraksts ir vienkārŔāks, pazÄ«stamāks un labāk strukturēts nekā funkcionāls modelis.

Soļu tehniskajai realizācijai mums ir Ä«paÅ”s iekŔējais rÄ«ks CrossBuilder ā€“ slāņa rÄ«ks starp CI sistēmām, pakalpojumiem un infrastruktÅ«ru. Izstrādātājam nav jāsamazina velosipēds: mÅ«su CI sistēmā pietiek ar vienu no CrossBuilder rÄ«ka skriptiem (tā saukto uzdevumu), kas to pareizi izpildÄ«s, ņemot vērā mÅ«su infrastruktÅ«ras iespējas. .

Rezultāti

Raksts izrādÄ«jās diezgan garÅ”, taču tas ir neizbēgami, aprakstot sarežģītu procesu modelÄ“Å”anu. Nobeigumā es vēlos Ä«si noteikt mÅ«su galvenās idejas:

  • DevOps ideju ievieÅ”anas mērÄ·is mÅ«su uzņēmumā ir konsekventi samazināt uzņēmuma produkcijas ražoÅ”anas un uzturÄ“Å”anas izmaksas kvantitatÄ«vā izteiksmē (cilvēkstundas vai maŔīnas stundas, vCPU, RAM, Disk).
  • Veids, kā samazināt kopējās izstrādes izmaksas, ir minimizēt tipisku sērijveida uzdevumu izpildes izmaksas: tehnoloÄ£iskā procesa posmus un soļus.
  • Tipisks uzdevums ir uzdevums, kura risinājums ir pilnÄ«bā vai daļēji automatizēts, nesagādā grÅ«tÄ«bas izpildÄ«tājiem un neprasa ievērojamas darbaspēka izmaksas.
  • RažoÅ”anas process sastāv no posmiem, posmi ir sadalÄ«ti nedalāmos posmos, kas ir tipiski dažāda mēroga un apjoma uzdevumi.
  • No atŔķirÄ«giem tipiskiem uzdevumiem esam nonākuÅ”i lÄ«dz sarežģītām tehnoloÄ£iskām ķēdēm un daudzlÄ«meņu ražoÅ”anas procesa modeļiem, kurus var raksturot ar funkcionālu IDEF0 modeli vai vienkārŔāku tehnoloÄ£isko karti.
  • TehnoloÄ£iskā karte ir ražoÅ”anas procesa posmu un posmu tabulas attēlojums. Pats galvenais: karte ļauj redzēt visu procesu kopumā, lielos gabalos ar iespēju tos detalizēt.
  • Pamatojoties uz tehnoloÄ£isko karti, var novērtēt nepiecieÅ”amÄ«bu ieviest posmus konkrētajā produktā, norobežot atbildÄ«bas jomas, vienoties par lÄ«gumiem posmu ievados un izvados, precÄ«zāk novērtēt resursu nepiecieÅ”amÄ«bu.

Nākamajos rakstos mēs sÄ«kāk aprakstÄ«sim, kādi tehniskie rÄ«ki tiek izmantoti noteiktu tehnoloÄ£isko posmu ievieÅ”anai mÅ«su kartē.

Raksta autori:

Avots: www.habr.com

Pievieno komentāru