Larawan:
Kamusta kayong lahat! Kami ay mga inhinyero ng automation mula sa kumpanya at nagbibigay kami ng suporta para sa pagbuo ng mga produkto ng kumpanya: sinusuportahan namin ang buong pipeline ng pagpupulong mula sa commit ng isang linya ng code ng mga developer hanggang sa paglalathala ng mga natapos na produkto at lisensya sa mga update server. Sa di-pormal, tinatawag kaming mga inhinyero ng DevOps. Sa artikulong ito gusto naming pag-usapan ang mga teknolohikal na yugto ng proseso ng paggawa ng software, kung paano namin nakikita ang mga ito at kung paano namin inuuri ang mga ito.
Mula sa materyal matututunan mo ang tungkol sa pagiging kumplikado ng pag-uugnay ng multi-product development, kung ano ang isang teknolohikal na mapa at kung paano ito nakakatulong sa pag-aayos at pagkopya ng mga solusyon, kung ano ang mga pangunahing yugto at hakbang na binubuo ng proseso ng pag-unlad, kung paano natukoy ang mga lugar ng responsibilidad sa pagitan ng DevOps at mga team sa aming kumpanya.
Tungkol sa Chaos at DevOps
Sa madaling sabi, tandaan natin na ang konsepto ng DevOps ay kinabibilangan ng mga tool at serbisyo sa pag-unlad, pati na rin ang mga pamamaraan at pinakamahuhusay na kagawian para sa kanilang paggamit. I-highlight natin ang global layunin mula sa pagpapatupad ng mga ideya ng DevOps sa aming kumpanya: ito ay isang pare-parehong pagbawas sa gastos ng produksyon at pagpapanatili ng mga produkto sa dami ng mga termino (man-hours o machine-hours, CPU, RAM, Disk atbp.). Ang pinakasimpleng at pinaka-halatang paraan upang bawasan ang kabuuang halaga ng pagpapaunlad sa antas ng buong kumpanya ay ang pagliit ng gastos sa pagsasagawa ng mga tipikal na serial na gawain sa lahat ng yugto ng produksyon. Ngunit ano ang mga yugtong ito, paano sila makikilala mula sa pangkalahatang proseso, anong mga hakbang ang binubuo ng mga ito?
Kapag ang isang kumpanya ay gumagawa ng isang produkto, ang lahat ay higit pa o hindi gaanong malinaw: karaniwang mayroong pangkalahatang roadmap at development scheme. Ngunit ano ang gagawin kapag lumawak ang linya ng produkto at mas maraming produkto? Sa unang tingin, mayroon silang magkatulad na proseso at mga linya ng pagpupulong at magsisimula ang laro ng "hanapin ang mga pagkakaiba ng X" sa mga log at script. Paano kung mayroon nang 5+ na proyekto sa aktibong pag-develop at kailangan ang suporta para sa ilang bersyon na binuo sa loob ng ilang taon? Gusto ba nating muling gumamit ng maraming solusyon hangga't maaari sa mga pipeline ng produkto o handa ba tayong gumastos ng pera sa natatanging pag-unlad para sa bawat isa?
Paano makahanap ng balanse sa pagitan ng pagiging natatangi at serye ng mga solusyon?
Ang mga tanong na ito ay nagsimulang lumitaw sa ating harapan nang mas madalas simula noong 2015. Lumaki ang bilang ng mga produkto, at sinubukan naming palawakin ang aming departamento ng automation (DevOps), na sumuporta sa mga linya ng pagpupulong ng mga produktong ito, sa pinakamababa. Kasabay nito, gusto kong kopyahin ang pinakamaraming solusyon hangga't maaari sa pagitan ng mga produkto. Pagkatapos ng lahat, bakit ginagawa ang parehong bagay sa sampung produkto sa iba't ibang paraan?
Direktor ng Pag-unlad: "Guys, maaari ba nating suriin kung ano ang ginagawa ng DevOps para sa mga produkto?"
Kami: "Hindi namin alam, hindi namin naitanong ang tanong na ito, ngunit anong mga tagapagpahiwatig ang dapat kalkulahin?"
Direktor ng Pag-unlad: "Sino ang nakakaalam! Isipin mo..."
Gaya sa sikat na pelikulang iyon: "Pupunta ako sa hotel!.." - "Uh... Maaari mo bang ituro sa akin ang daan?" Pagkatapos ng pag-iisip, dumating kami sa konklusyon na kailangan muna naming magpasya sa mga huling estado ng mga produkto; ito ang naging unang layunin namin.
Kaya, paano mo masusuri ang isang dosenang produkto na may medyo malalaking team na 10 hanggang 200 tao at matutukoy ang mga nasusukat na sukatan kapag kinokopya ang mga solusyon?
1:0 pabor sa Chaos, o DevOps on the blades
Nagsimula kami sa pamamagitan ng pagsubok na maglapat ng mga diagram ng IDEF0 at iba't ibang diagram ng proseso ng negosyo mula sa serye ng BPwin. Nagsimula ang pagkalito pagkatapos ng ikalimang parisukat ng susunod na yugto ng susunod na proyekto, at ang mga parisukat na ito para sa bawat proyekto ay maaaring iguhit sa buntot ng isang mahabang python sa 50+ na hakbang. Nalungkot ako at gusto kong umangal sa buwan - hindi ito magkasya.
Mga karaniwang gawain sa produksyon
Ang pagmomodelo ng mga proseso ng produksyon ay isang napaka-kumplikado at maingat na gawain: kailangan mong mangolekta, magproseso at magsuri ng maraming data mula sa iba't ibang mga departamento at mga chain ng produksyon. Maaari mong basahin ang higit pa tungkol dito sa artikulong "'.
Noong sinimulan namin ang pagmomodelo ng aming proseso ng produksyon, nagkaroon kami ng isang tiyak na layunin - upang ihatid sa bawat empleyado na kasangkot sa pagbuo ng mga produkto ng aming kumpanya at sa mga tagapamahala ng proyekto:
- kung paano naaabot ng mga produkto at mga bahagi ng mga ito, simula sa commit ng isang linya ng code, ang customer sa anyo ng mga installer at update,
- anong mga mapagkukunan ang ibinibigay sa bawat yugto ng paggawa ng produkto,
- anong mga serbisyo ang nasasangkot sa bawat yugto,
- kung paano itinatakda ang mga lugar ng responsibilidad para sa bawat yugto,
- anong mga kontrata ang umiiral sa input at output ng bawat yugto.
Mag-click sa larawan upang buksan sa buong laki
Ang aming trabaho sa kumpanya ay nahahati sa ilang mga functional na lugar. Ang departamento ng imprastraktura ay nakikibahagi sa pag-optimize ng operasyon ng lahat ng mga mapagkukunan ng hardware ng departamento, pati na rin ang pag-automate ng pag-deploy ng mga virtual machine at ang kapaligiran sa kanila. Ang direksyon ng pagsubaybay ay nagbibigay ng kontrol sa pagganap ng mga serbisyo 24/7; Nagbibigay din kami ng pagsubaybay bilang isang serbisyo para sa mga developer. Ang direksyon ng daloy ng trabaho ay nagbibigay sa mga koponan ng mga tool para sa pamamahala ng mga proseso ng pag-develop at pagsubok, pagsusuri sa status ng code, at pagkuha ng analytics sa mga proyekto. At sa wakas, tinitiyak ng direksyon ng webdev ang paglalathala ng mga release sa mga server ng pag-update ng GUS at FLUS, pati na rin ang paglilisensya ng mga produkto gamit ang serbisyo ng LicenseLab. Upang suportahan ang pipeline ng produksyon, nagse-set up at nagpapanatili kami ng maraming iba't ibang serbisyo ng suporta para sa mga developer (maaari kang makinig sa mga kuwento tungkol sa ilan sa kanila sa mga lumang pagkikita: и). Bumubuo din kami ng mga panloob na tool sa automation, kabilang ang .
Sa nakalipas na limang taon, ang aming trabaho ay nakaipon ng maraming katulad at nakagawiang mga operasyon, at ang tinatawag na karaniwang mga gawain, ang solusyon na kung saan ay ganap o bahagyang awtomatiko, ay hindi nagdudulot ng mga paghihirap para sa mga gumaganap at hindi nangangailangan ng malaking halaga ng trabaho. Kasama ang mga nangungunang lugar, sinuri namin ang mga naturang gawain at natukoy namin ang mga indibidwal na kategorya ng trabaho, o mga yugto ng produksyon, ang mga yugto ay nahahati sa hindi mahahati na mga hakbang, at ilang yugto ang nagdaragdag chain ng proseso ng produksyon.
Ang pinakasimpleng halimbawa ng isang teknolohikal na chain ay ang mga yugto ng pagpupulong, pag-deploy at pagsubok ng bawat isa sa aming mga produkto sa loob ng kumpanya. Bilang karagdagan, halimbawa, ang yugto ng pagbuo ay binubuo ng maraming magkakahiwalay na karaniwang hakbang: pag-download ng mga mapagkukunan mula sa GitLab, paghahanda ng mga dependency at 3rd-party na aklatan, pagsubok sa unit at pagsusuri ng static na code, pagsasagawa ng build script sa GitLab CI, pag-publish ng mga artifact sa isang repository sa Artifactory at pagbuo ng mga tala sa paglabas sa pamamagitan ng aming panloob na tool sa ChangelogBuilder.
Mababasa mo ang tungkol sa mga karaniwang gawain ng DevOps sa aming iba pang mga artikulo sa Habré: “"At"'.
Maraming karaniwang mga kadena ng produksyon ang nabubuo proseso ng pagmamanupaktura. Ang karaniwang diskarte sa paglalarawan ng mga proseso ay ang paggamit ng mga functional na modelo ng IDEF0.
Isang halimbawa ng pagmomodelo ng proseso ng production CI
Binigyan namin ng espesyal na pansin ang pagbuo ng mga karaniwang proyekto para sa tuluy-tuloy na sistema ng pagsasama. Ito ay naging posible upang makamit ang pag-iisa ng mga proyekto, na itinatampok ang tinatawag na release diagram ng mga build na may mga promosyon.
Narito kung paano ito gumagana. Ang lahat ng mga proyekto ay mukhang tipikal: kasama nila ang configuration ng mga assemblies na pumupunta sa snapshot repository sa Artifactory, pagkatapos nito ay i-deploy at sinubukan ang mga ito sa mga test bench, at pagkatapos ay i-promote sa release repository. Ang Artifactory service ay isang punto para sa pamamahagi ng lahat ng build artifact sa pagitan ng mga team at iba pang serbisyo.
Kung lubos naming pasimplehin at i-generalize ang aming scheme ng paglabas, kabilang dito ang mga sumusunod na yugto:
- cross-platform na pagbuo ng produkto,
- deployment sa mga test bench,
- paglulunsad ng functional at iba pang mga pagsubok,
- pag-promote ng mga nasubok na asembliya upang maglabas ng mga repositoryo sa Artifactory,
- publishing release builds para i-update ang mga server,
- paghahatid ng mga build at update sa produksyon,
- paglulunsad ng pag-install at pag-update ng produkto.
Isaalang-alang natin, bilang isang halimbawa, ang teknolohikal na modelo ng tipikal na pamamaraan ng pagpapalabas na ito (mula rito ay tinutukoy lamang bilang Modelo) sa anyo ng isang functional na modelo ng IDEF0. Sinasalamin nito ang mga pangunahing yugto ng aming proseso ng CI. Ginagamit ng mga modelong IDEF0 ang tinatawag na ICOM notation (Input-Control-Output-Mechanism) upang ilarawan kung anong mga mapagkukunan ang ginagamit sa bawat yugto, batay sa kung anong mga tuntunin at mga kinakailangan ang gawain ay isinasagawa, ano ang output at kung anong mga mekanismo, serbisyo o mga tao ang nagpapatupad ng isang partikular na yugto.
Mag-click sa larawan upang buksan sa buong laki
Bilang isang patakaran, sa mga functional na modelo ay mas madaling mabulok at detalyado ang paglalarawan ng mga proseso. Ngunit habang lumalaki ang bilang ng mga elemento, nagiging mas mahirap na maunawaan ang isang bagay tungkol sa kanila. Ngunit sa totoong pag-unlad mayroon ding mga pantulong na yugto: pagsubaybay, sertipikasyon ng produkto, automation ng mga proseso ng trabaho at iba pa. Dahil mismo sa problema sa pag-scale kaya tinalikuran namin ang paglalarawang ito.
Kapanganakan ng Pag-asa
Sa isang libro ay nakita namin ang mga lumang mapa ng Sobyet na naglalarawan ng mga teknolohikal na proseso (na, sa pamamagitan ng paraan, ay ginagamit pa rin ngayon sa maraming mga negosyo at unibersidad na pag-aari ng estado). Teka, teka, may technological process din tayo!.. May mga stages, results, metrics, requirements, indicators, etc., etc.... Bakit hindi subukang mag-apply ng mga technological maps sa ating mga product conveyor? Nagkaroon ng pakiramdam: “Ito na! Natagpuan namin ang tamang thread, oras na para bigyan ito ng magandang paghatak!"
Sa isang simpleng talahanayan, nagpasya kaming mag-record ng mga produkto ayon sa mga column, at mga teknolohikal na yugto at hakbang ng conveyor ng produkto ayon sa mga hilera. Ang mga yugto ay isang bagay na malaki, tulad ng yugto ng pagpupulong ng isang produkto. At ang mga hakbang ay isang bagay na mas maliit at mas detalyado, halimbawa, ang hakbang ng pag-download ng source code sa build server o ang hakbang ng pag-compile ng code.
Sa mga intersection ng mga row at column ng mapa, naglalagay kami ng mga status para sa isang partikular na yugto at produkto. Maraming mga estado ang tinukoy para sa mga katayuan:
- Walang data - o hindi praktikal. Kinakailangang pag-aralan ang pangangailangan para sa isang yugto sa produkto. Alinman ang pagsusuri ay naisagawa na, ngunit ang yugto ay kasalukuyang hindi kailangan o hindi makatwiran sa ekonomiya.
- Ipinagpaliban - o hindi nauugnay sa ngayon. Ang yugtong ito sa pipeline ay kailangan, ngunit walang lakas upang ipatupad ito sa taong ito.
- Plano. Ang yugto ay binalak para sa pagpapatupad sa taong ito.
- Ipinatupad. Ang yugto sa pipeline ay ipinatupad sa kinakailangang lawak.
Ang pagpuno sa talahanayan ay nagsimulang proyekto ayon sa proyekto. Una, inuri namin ang mga yugto at hakbang ng isang proyekto at naitala ang kanilang mga katayuan. Pagkatapos ay kinuha nila ang susunod na proyekto, naitala ang mga katayuan sa loob nito at nagdagdag ng mga yugto at hakbang na nawawala sa mga nakaraang proyekto. Bilang resulta, natanggap namin ang mga yugto at hakbang ng aming buong pipeline ng produksyon at ang kanilang mga katayuan sa isang partikular na proyekto. Ang resulta ay isang bagay na katulad ng isang competency matrix para sa isang food conveyor. Tinawag namin ang gayong matrix na isang teknolohikal na mapa.
Sa tulong ng teknolohikal na mapa, substantively kaming sumasang-ayon sa mga koponan sa mga plano sa trabaho para sa taon at ang mga target na gusto naming makamit nang sama-sama: kung aling mga yugto ang idaragdag namin sa proyekto sa taong ito, at kung saan kami umalis para sa ibang pagkakataon. Gayundin, habang nagtatrabaho kami, maaari kaming makakita ng mga pagpapabuti sa mga hakbang na nakumpleto namin para sa isang produkto lamang. Pagkatapos ay pinalawak namin ang aming mapa at ipinakilala ang pagpapabuti na ito bilang isang yugto o isang bagong hakbang, pagkatapos ay nagsasagawa kami ng pagsusuri para sa bawat produkto at alamin ang pagiging posible ng pagkopya ng pagpapabuti.
Maaaring tumutol sila sa atin: “Maganda ang lahat, siyempre, ngunit sa paglipas ng panahon ang bilang ng mga hakbang at yugto ay magiging napakalaki. Anong gagawin ko?
Ipinakilala namin ang mga pamantayan at medyo kumpletong paglalarawan ng mga kinakailangan para sa bawat yugto at hakbang upang sa loob ng kumpanya ay naiintindihan sila ng lahat sa parehong paraan. Sa paglipas ng panahon, habang ipinapatupad ang mga pagpapabuti, ang isang hakbang ay maaaring makuha sa isa pang yugto o hakbang - pagkatapos ay babagsak ang mga ito. Kasabay nito, ang lahat ng mga kinakailangan at teknolohikal na mga nuances ay umaangkop sa mga kinakailangan ng yugto o hakbang sa pangkalahatan.
Paano suriin ang epekto ng pagkopya ng mga solusyon? Gumagamit kami ng napakasimpleng diskarte: iniuugnay namin ang mga paunang gastos sa kapital para sa pagpapatupad ng isang bagong yugto sa taunang pangkalahatang gastos ng produkto, at pagkatapos ay hinahati ang mga ito sa lahat kapag kinokopya.
Ang mga bahagi ng pag-unlad ay makikita na bilang mga yugto at hakbang sa mapa. Maaari naming maimpluwensyahan ang pagbawas ng mga gastos sa produkto sa pamamagitan ng pagpapakilala ng automation para sa mga tipikal na yugto. Pagkatapos nito, kinakalkula namin ang mga pagbabago sa qualitative na katangian, quantitative metrics at ang tubo na natanggap ng mga team (sa man-hours o machine-hours na naka-save).
Teknolohikal na mapa ng proseso ng produksyon
Kung gagawin namin ang lahat ng aming mga yugto at hakbang, i-encode ang mga ito ng mga tag at palawakin ang mga ito sa isang kadena, pagkatapos ay magiging napakahaba at hindi maintindihan (eksaktong kaparehong "buntot ng python" na napag-usapan namin sa simula ng artikulo) :
[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]Ito ang mga yugto ng pag-assemble ng mga produkto [Build], pagde-deploy ng mga ito para subukan ang mga server [Deploy], pagsubok [Test], pag-promote ng mga assemblies na maglabas ng mga repository batay sa mga resulta ng pagsubok [I-promote], pagbuo at pag-publish ng mga lisensya [Lisensya], pag-publish [I-publish] sa server ng pag-update ng GUS at paghahatid ng mga update ng FLUS sa mga server, pag-install at pag-update ng mga bahagi ng produkto sa imprastraktura ng customer gamit ang Product Configuration Management [Install], pati na rin ang koleksyon ng telemetry [Telemetry] mula sa mga naka-install na produkto.
Bilang karagdagan sa mga ito, maaari nating makilala ang magkakahiwalay na mga yugto: pagsubaybay sa estado ng imprastraktura [InfMonitoring], pamamahala ng mga bersyon ng source code [SourceCodeControl], paghahanda ng kapaligiran ng pagpupulong [Maghanda], pamamahala ng proyekto [Workflow], pagbibigay ng mga koponan ng mga tool sa komunikasyon [ Komunikasyon], sertipikasyon ng produkto [Certification] at pagtiyak ng pagiging sapat sa sarili ng mga proseso ng CI [CISelfSufficiency] (halimbawa, kalayaan ng mga asembliya mula sa Internet). Hindi namin isasaalang-alang ang dose-dosenang mga hakbang sa aming mga proseso, dahil napaka-spesipiko ng mga ito.
Magiging mas madaling maunawaan at tingnan ang buong proseso ng produksyon kung maiisip mo ito sa anyo teknolohikal na mapa; Ito ay isang talahanayan kung saan ang mga indibidwal na yugto ng produksyon at mga decomposed na hakbang ng Modelo ay itinatala sa mga hilera, at sa mga column ay isang paglalarawan ng kung ano ang ginagawa sa bawat yugto o hakbang. Ang pangunahing diin ay sa mga mapagkukunan na nagbibigay ng bawat yugto at ang delimitation ng mga lugar ng responsibilidad.
Para sa amin, ang mapa ay isang uri ng classifier. Sinasalamin nito ang malalaking teknolohikal na bahagi ng produksyon ng produkto. Dahil dito, naging mas madali para sa aming koponan ng automation na makipag-ugnayan sa mga developer at magkasamang planuhin ang pagpapatupad ng mga yugto ng automation, pati na rin ang pag-unawa kung anong mga gastos sa paggawa at mapagkukunan (tao at hardware) ang kakailanganin para dito.
Sa loob ng aming kumpanya, ang mapa ay awtomatikong nabuo mula sa isang jinja template bilang isang regular na HTML file, at pagkatapos ay na-upload sa GitLab Pages server. Maaaring matingnan ang isang screenshot na may halimbawa ng isang ganap na nabuong mapa .
Mag-click sa larawan upang buksan sa buong laki
Sa madaling salita, ang isang teknolohikal na mapa ay isang pangkalahatang larawan ng proseso ng produksyon, na nagpapakita ng malinaw na inuri na mga bloke na may karaniwang pag-andar.
Ang istraktura ng aming teknolohikal na mapa
Ang mapa ay binubuo ng ilang bahagi:
- Heading area - narito ang isang pangkalahatang paglalarawan ng mapa, ang mga pangunahing konsepto ay ipinakilala, at ang mga pangunahing mapagkukunan at mga resulta ng proseso ng produksyon ay tinukoy.
- Panel ng impormasyon - dito maaari mong kontrolin ang pagpapakita ng data para sa mga indibidwal na produkto; isang buod ng mga ipinatupad na yugto at hakbang sa pangkalahatan para sa lahat ng mga produkto ay ibinigay.
- Teknolohikal na mapa - isang tabular na paglalarawan ng teknolohikal na proseso. Sa mapa:
- lahat ng mga yugto, mga hakbang at ang kanilang mga code ay ibinigay;
- maikli at kumpletong paglalarawan ng mga yugto ay ibinigay;
- ang mga mapagkukunan ng input at mga serbisyo na ginagamit sa bawat yugto ay ipinahiwatig;
- ang mga resulta ng bawat yugto at indibidwal na hakbang ay ipinahiwatig;
- ang lugar ng responsibilidad para sa bawat yugto at hakbang ay ipinahiwatig;
- ang mga teknikal na mapagkukunan ay natukoy, halimbawa HDD (SSD), RAM, vCPU, at mga oras ng tao na kinakailangan upang suportahan ang trabaho sa yugtong ito, kapwa sa kasalukuyan - katotohanan, at sa hinaharap - plano;
- para sa bawat produkto ito ay ipinahiwatig kung aling mga teknolohikal na yugto o hakbang para dito ang naipatupad, ang binalak para sa pagpapatupad, ay walang kaugnayan o hindi pa naipatupad.
Paggawa ng mga desisyon batay sa teknolohikal na mapa
Pagkatapos pag-aralan ang mapa, maaari kang gumawa ng ilang aksyon, depende sa tungkulin ng empleyado sa kumpanya (development manager, product manager, developer o tester):
- maunawaan kung aling mga yugto ang nawawala sa isang tunay na produkto o proyekto at tasahin ang pangangailangan para sa kanilang pagpapatupad;
- limitahan ang mga lugar ng responsibilidad sa pagitan ng ilang mga departamento kung nagtatrabaho sila sa iba't ibang yugto;
- makipag-ayos ng mga kontrata para sa mga input at output ng mga yugto;
- isama ang iyong yugto ng trabaho sa pangkalahatang proseso ng pag-unlad;
- mas tumpak na tasahin ang pangangailangan para sa mga mapagkukunan upang suportahan ang bawat yugto.
Pagbubuod ng lahat ng nasa itaas
Ang mapa ng teknolohiya ay maraming nalalaman, napapalawak at madaling mapanatili. Mas madaling bumuo at magpanatili ng mga paglalarawan ng proseso sa form na ito kaysa sa mahigpit na modelo ng akademikong IDEF0. Bilang karagdagan, ang isang tabular na paglalarawan ay mas simple, mas pamilyar at mas mahusay kaysa sa isang functional na modelo.
Para sa teknikal na pagpapatupad ng mga hakbang, responsable kami para sa isang espesyal na panloob na tool na tinatawag na CrossBuilder - isang layering tool sa pagitan ng mga CI system, serbisyo at imprastraktura. Hindi kailangang putulin ng developer ang kanyang bike: sa aming CI system ay sapat na upang patakbuhin ang isa sa mga script (ang tinatawag na gawain) ng tool na CrossBuilder, na isasagawa ito nang tama, na isinasaalang-alang ang mga tampok ng aming imprastraktura.
Mga resulta ng
Ang artikulo ay naging medyo mahaba, ngunit ito ay hindi maiiwasan kapag inilalarawan ang pagmomodelo ng mga kumplikadong proseso. Sa huli, nais kong ipahayag nang maikli ang aming mga pangunahing ideya:
- Ang layunin ng pagpapakilala ng mga ideya sa DevOps sa aming kumpanya ay ang patuloy na bawasan ang gastos ng produksyon at pagpapanatili ng mga produkto ng kumpanya sa dami ng termino (man-hours o machine-hours, vCPU, RAM, Disk).
- Ang isang paraan upang bawasan ang kabuuang halaga ng pagpapaunlad ay upang mabawasan ang gastos ng pagsasagawa ng mga karaniwang serial na gawain: mga yugto at hakbang ng proseso ng teknolohiya.
- Ang isang karaniwang gawain ay isang gawain na ang solusyon ay ganap o bahagyang awtomatiko, hindi nagdudulot ng mga paghihirap para sa mga gumaganap at hindi nangangailangan ng malaking gastos sa paggawa.
- Ang proseso ng produksyon ay binubuo ng mga yugto, ang mga yugto ay nahahati sa hindi mahahati na mga hakbang, na kumakatawan sa mga tipikal na gawain ng iba't ibang mga kaliskis at volume.
- Mula sa mga nakahiwalay na karaniwang gawain nakarating kami sa mga kumplikadong teknolohikal na chain at multi-level na mga modelo ng proseso ng produksyon, na maaaring ilarawan ng isang functional na modelo ng IDEF0 o isang mas simpleng teknolohikal na mapa.
- Ang flow chart ay isang tabular na representasyon ng mga yugto at hakbang ng isang proseso ng produksyon. Ang pinakamahalagang bagay: ang mapa ay nagbibigay-daan sa iyo upang makita ang buong proseso sa kabuuan nito, sa malalaking piraso na may posibilidad na i-detalye ang mga ito.
- Batay sa teknolohikal na mapa, maaari mong masuri ang pangangailangan na ipatupad ang mga yugto sa isang partikular na produkto, limitahan ang mga lugar ng responsibilidad, sumang-ayon sa mga kontrata para sa mga input at output ng mga yugto, at mas tumpak na masuri ang pangangailangan para sa mga mapagkukunan.
Sa mga sumusunod na artikulo ay pag-uusapan natin nang mas detalyado kung anong mga teknikal na tool ang ginagamit upang ipatupad ang ilang mga teknolohikal na yugto sa ating mapa.
Mga may-akda ng artikulo:
- — Pinuno ng Automation Department (DevOps) sa Positive Technologies
- - representante Pinuno ng Automation Department (DevOps) sa Positive Technologies
Pinagmulan: www.habr.com