Irudia:
Kaixo guztioi! Enpresako automatizazio ingeniariak gara eta konpainiaren produktuak garatzeko laguntza eskaintzen dugu: muntaketa-bide osoa onartzen dugu garatzaileek kode-lerro bat konprometitzen dutenetik eguneratze-zerbitzarietan amaitutako produktuak eta lizentziak argitaratzen diren arte. Informalki, DevOps ingeniariak deitzen gara. Artikulu honetan softwarearen ekoizpen prozesuaren fase teknologikoei buruz hitz egin nahi dugu, nola ikusten ditugun eta nola sailkatzen ditugun.
Materialetik, produktu anitzeko garapena koordinatzearen konplexutasuna ezagutuko duzu, mapa teknologikoa zer den eta nola laguntzen duen irtenbideak antolatzeko eta errepikatzeko, garapen prozesuaren fase eta urrats nagusiak zeintzuk diren, erantzukizun-eremuak nola zedarritzen diren ezagutuko duzu. DevOps eta gure konpainiako taldeen artean.
Chaos eta DevOps-i buruz
Kontuan izan dezagun laburki DevOps kontzeptuak garapen-tresnak eta zerbitzuak barne hartzen dituela, baita horiek erabiltzeko metodologiak eta praktika onak ere. Nabarmendu dezagun globala helburua Gure enpresan DevOps ideiak ezartzetik: produktuen ekoizpen- eta mantentze-kostuaren murrizketa koherentea da termino kuantitatiboetan (gizon-orduak edo makina-orduak, CPU, RAM, Diskoa, etab.). Enpresa mailan garapenaren kostu orokorra murrizteko modurik errazena eta argiena hau da serieko ohiko zereginak egitearen kostua gutxitzea ekoizpen-fase guztietan. Baina zeintzuk dira etapa hauek, nola bereiz daitezke prozesu orokorretik, zein urratsez osatuta daude?
Enpresa bat produktu bat garatzen ari denean, dena gutxi gorabehera argi dago: bide orri orokorra eta garapen eskema egon ohi da. Baina zer egin produktu-lerroa zabaltzen denean eta produktu gehiago daudenean? Lehen begiratuan, antzeko prozesuak eta muntaketa-lerroak dituzte eta erregistro eta scriptetan "aurkitu X desberdintasunak" jokoa hasten da. Zer gertatzen da dagoeneko 5+ proiektu garapen aktiboan eta hainbat urtetan garatutako hainbat bertsioren laguntza behar bada? Ahalik eta soluzio gehien berrerabili nahi al ditugu produktuen kanalizazioetan edo prest al gaude dirua gastatzeko bakoitzaren garapen bakarrean?
Nola aurkitu soluzioen berezitasunaren eta serietasunaren arteko oreka?
2015etik aurrera gero eta maizago sortzen zitzaizkigun galdera hauek. Produktu kopurua hazi egin zen, eta produktu horien muntaketa-lerroak onartzen zituen gure automatizazio saila (DevOps) gutxienera zabaltzen saiatu ginen. Aldi berean, produktuen artean ahalik eta soluzio gehien errepikatu nahi nuen. Azken finean, zergatik egin gauza bera hamar produktutan modu ezberdinetan?
Garapen zuzendaria: "Mutilak, nolabait ebaluatu al dezakegu DevOps-ek zer egiten duen produktuekin?"
Dugu: "Ez dakigu, ez dugu galdera hau egin, baina zein adierazle kalkulatu behar dira?"
Garapen zuzendaria: "Nork daki! Pentsa..."
Pelikula famatu hartan bezala: "Hotelera noa!..." - "Uh... Erakutsi al didazu bidea?" Hausnartu ondoren, lehenengo produktuen azken egoerak erabaki behar ditugula ondorioztatu dugu; hau izan zen gure lehen helburua.
Beraz, nola analizatu dozena bat produktu 10 eta 200 lagun arteko talde nahiko handiekin eta neurri neurgarriak zehaztu soluzioak errepikatzerakoan?
1:0 Kaosaren alde, edo DevOps-en alde
BPwin serieko IDEF0 diagramak eta negozio prozesuen diagrama ezberdinak aplikatzen saiatzen hasi ginen. Nahasmena hurrengo proiektuaren hurrengo faseko bosgarren karratuaren ondoren hasi zen, eta proiektu bakoitzeko karratu hauek pitoi luze baten buztanean marraz daitezke 50+ urratsetan. Triste sentitu nintzen eta ilargiari ulu egin nahi nion - ez zen batere egokitzen.
Ekoizpen-zeregin tipikoak
Ekoizpen-prozesuak modelatzea oso lan konplexua eta neketsua da: hainbat sail eta ekoizpen-katetako datu asko bildu, prozesatu eta aztertu behar dituzu. Honi buruz gehiago irakur dezakezu artikuluan "'.
Gure ekoizpen-prozesua modelatzen hasi ginenean, helburu zehatz bat genuen: gure enpresaren produktuen garapenean parte hartzen duten langile guztiei eta proiektuen arduradunei helarazteko:
- produktuak eta haien osagaiak, kode-lerro baten konpromisotik hasita, nola iristen diren bezeroari instalatzaile eta eguneratze moduan,
- zer baliabide eskaintzen diren produktuaren ekoizpenaren fase bakoitzean,
- fase bakoitzean zer zerbitzu parte hartzen duten,
- etapa bakoitzerako erantzukizun-eremuak nola zedarritzen diren,
- etapa bakoitzaren sarreran eta irteeran zer kontratu dauden.
Egin klik irudian tamaina osoan irekitzeko
Gure lana enpresan hainbat arlo funtzionaletan banatzen da. Azpiegitura saila saileko hardware-baliabide guztien funtzionamendua optimizatzen dihardu, baita makina birtualen eta horien inguruko ingurunearen hedapena automatizatzen ere. Jarraipenaren zuzendaritzak zerbitzuen errendimenduaren gaineko kontrola ematen du 24/7; Monitorizazioa ere eskaintzen dugu garatzaileentzako zerbitzu gisa. Lan-fluxuaren norabideak garapen eta proba prozesuak kudeatzeko, kodearen egoera aztertzeko eta proiektuen analisiak lortzeko tresnak eskaintzen dizkie taldeei. Eta, azkenik, webdev zuzendaritzak GUS eta FLUS eguneratze zerbitzarietan argitalpenak argitaratzea ziurtatzen du, baita LicenseLab zerbitzua erabiltzen duten produktuen lizentziak ere. Ekoizpen-bideari eusteko, garatzaileentzako laguntza-zerbitzu ezberdin asko konfiguratu eta mantentzen ditugu (hauetako batzuei buruzko istorioak entzun ditzakezu bilera zaharretan: и). Barne automatizazio tresnak ere garatzen ditugu, besteak beste .
Azken bost urteotan, gure lanak antzeko eta ohiko eragiketa asko pilatu ditu, eta deiturikoak ohiko zereginak, zeinaren soluzioa guztiz edo partzialki automatizatuta dagoen, ez die zailtasunik eragiten interpreteei eta ez du lan kopuru handirik behar. Arlo nagusiekin batera, horrelako zereginak aztertu eta lan-kategoria indibidualak identifikatu ahal izan ditugu, edo ekoizpen faseak, etapak urrats zatiezinetan banatzen dira, eta hainbat etapa batu ekoizpen-prozesuaren katea.
Kate teknologiko baten adibiderik errazena enpresa barruan gure produktu bakoitzaren muntaketa, hedapena eta probak egiteko faseak dira. Era berean, adibidez, eraikuntza-faseak urrats estandar ezberdin asko ditu: GitLab-eko iturriak deskargatzea, mendekotasunak eta hirugarrenen liburutegiak prestatzea, unitate-probak eta kode estatikoen azterketa, GitLab CI-n eraikitze-script bat exekutatu, artefaktuak biltegi batean argitaratzea. Artifactory eta bertsio-oharrak sortzea gure barne ChangelogBuilder tresnaren bidez.
DevOps ohiko zereginei buruz irakurri dezakezu Habré-ri buruzko gure beste artikuluetan: ""Eta"'.
Ekoizpen-kate tipiko asko sortzen dira fabrikazio prozesua. Prozesuak deskribatzeko ikuspegi estandarra IDEF0 eredu funtzionalak erabiltzea da.
Produkzio CI prozesu baten modelizazioaren adibide bat
Arreta berezia jarri genion etengabeko integrazio sistema baterako proiektu estandarrak garatzeari. Horri esker, proiektuen bateratzea lortu ahal izan zen, deiturikoa nabarmenduz promozioekin eraikitzen askatzeko diagrama.
Hona hemen nola funtzionatzen duen. Proiektu guztiek itxura tipikoa dute: Artifactory-ko snapshot biltegira doazen muntaien konfigurazioa barne hartzen dute, ondoren proba-bankuetan zabaldu eta probatzen dira, eta kaleratze biltegira igotzen dira. Artifactory zerbitzua taldeen eta beste zerbitzu batzuen artean eraikitako artefaktu guztiak banatzeko puntu bakarra da.
Gure kaleratze-eskema asko sinplifikatzen eta orokortzen badugu, fase hauek barne hartzen ditu:
- plataforma anitzeko produktuen eraikuntza,
- proba-bankuetara zabaltzea,
- proba funtzionalak eta bestelakoak abian jartzea,
- Artifactory-n biltegiak askatzeko probatutako muntaiak sustatzea,
- zerbitzariak eguneratzeko bertsioak argitaratzea,
- ekoizpenerako eraikuntzak eta eguneraketak entregatzea,
- instalazioa eta produktuen eguneraketak martxan jartzea.
Har dezagun, adibide gisa, kaleratze-eskema tipiko honen eredu teknologikoa (aurrerantzean Eredua besterik gabe deitzen dena) IDEF0 eredu funtzional baten moduan. Gure CI prozesuaren fase nagusiak islatzen ditu. IDEF0 ereduak deitutakoa erabiltzen dute ICOM idazkera (Sarrera-Kontrol-Irteera-Mekanismoa) fase bakoitzean zer baliabide erabiltzen diren deskribatzeko, zein arau eta eskakizunetan egiten den lana, zein den irteera eta zein mekanismo, zerbitzu edo pertsonek ezartzen duten etapa jakin bat.
Egin klik irudian tamaina osoan irekitzeko
Oro har, eredu funtzionaletan errazagoa da prozesuen deskribapena deskonposatzea eta zehaztea. Baina elementu kopurua hazi ahala, gero eta zailagoa da haiei buruz zerbait ulertzea. Baina garapen errealean etapa laguntzaileak ere badaude: jarraipena, produktuen ziurtapena, lan-prozesuen automatizazioa eta beste. Hain zuzen, eskalatze arazoa dela eta bertan behera utzi genuen deskribapen hau.
Itxaropenaren jaiotza
Liburu batean prozesu teknologikoak deskribatzen zituzten mapa sobietar zaharrak topatu genituen (bide batez, gaur egun oraindik ere Estatuko enpresa eta unibertsitate askotan erabiltzen direnak). Itxaron, itxaron, prozesu teknologiko bat ere badugu!.. Badaude etapak, emaitzak, neurketak, eskakizunak, adierazleak, etab.... Zergatik ez saiatu mapa teknologikoak gure produktu-garraiatzaileetan aplikatzen? Sentsazio bat zegoen: “Hau da! Hari egokia aurkitu dugu, tira ona emateko garaia da!”.
Taula sinple batean, produktuak zutabeen arabera erregistratzea erabaki dugu, eta produktu-garraiatzailearen etapa eta urrats teknologikoak errenkadaren arabera. Etapak zerbait handia dira, adibidez, produktu baten muntaketa fasea. Eta urratsak zerbait txikiagoa eta zehatzagoa dira, adibidez, iturburu-kodea build zerbitzarira deskargatzeko urratsa edo kodea konpilatzeko urratsa.
Maparen errenkaden eta zutabeen elkarguneetan, etapa eta produktu jakin baterako egoerak jartzen ditugu. Egoera asko definitu dira:
- Ez dago informaziorik - edo ez da praktikoa. Beharrezkoa da produktuaren etapa baten eskaria aztertzea. Edo analisia eginda dago jada, baina etapa ez da beharrezkoa edo ekonomikoki justifikatuta ez dago.
- Atzeratua - edo momentuz ez dago garrantzitsua. Etapa hori beharrezkoa da, baina ez dago aurten gauzatzeko energiarik.
- Aurreikusita. Etapa aurten gauzatzea aurreikusita dago.
- Konturatu. Kanpainaren fasea behar den neurrian ezartzen da.
Taula betez proiektuz proiektu hasi zen. Lehenik eta behin, proiektu baten faseak eta urratsak sailkatu eta haien egoerak erregistratu genituen. Ondoren, hurrengo proiektua hartu, bertan dauden egoerak erregistratu eta aurreko proiektuetan falta ziren etapak eta urratsak gehitu zituzten. Ondorioz, gure ekoizpen kanal osoaren faseak eta urratsak eta haien egoerak proiektu zehatz batean jaso genituen. Emaitza elikagai-garraiatzaile baten gaitasun-matrize baten antzeko zerbait da. Horrelako matrizeari mapa teknologiko deitu genion.
Mapa teknologikoaren laguntzaz, metrologikoki substantiboki adosten ditugu taldeekin urteko lan planak eta elkarrekin lortu nahi ditugun helburuak: zein etapa gehitzen dizkiogun aurten proiektuari, eta zeintzuk gerorako uzten ditugun. Gainera, lan egiten dugun heinean, produktu bakarrerako egin ditugun urratsetan hobekuntzak ikusiko ditugu. Ondoren, gure mapa zabaltzen dugu eta hobekuntza hau etapa edo urrats berri gisa sartzen dugu, ondoren produktu bakoitzaren azterketa bat egiten dugu eta hobekuntza errepikatzeko bideragarritasuna aztertzen dugu.
Oposizioa egin dezakete: «Hau guztia ona da, noski, baina denborarekin pauso eta etapa kopurua izugarri handia izango da. Zer egin beharko nuke?
Etapa eta urrats bakoitzerako eskakizunen deskribapen estandarrak eta nahiko osatuak aurkeztu genituen, enpresa barruan denek modu berean uler zezaten. Denborak aurrera egin ahala, hobekuntzak ezartzen diren heinean, urrats bat beste etapa edo urrats batean xurgatu daiteke; orduan kolapsatu egingo dira. Aldi berean, eskakizun eta ñabardura teknologiko guztiak orokortze etapa edo urratsaren eskakizunetan sartzen dira.
Nola ebaluatu irtenbideak errepikatzearen eragina? Ikuspegi oso sinplea erabiltzen dugu: etapa berri bat ezartzeko hasierako kapital-kostuak urteko produktu-kostu orokorrei egozten dizkiegu, eta, ondoren, denen artean banatzen ditugu errepikatzerakoan.
Garapenaren zatiak mapan etapa eta urrats gisa islatzen dira dagoeneko. Produktuen kostuen murrizketan eragin dezakegu fase tipikoetarako automatizazioaren ezarpenaren bidez. Horren ostean, ezaugarri kualitatiboetan, neurketa kuantitatiboetan eta taldeek jasotako irabazien aldaketak kalkulatzen ditugu (aurreztutako gizon-orduetan edo makina-orduetan).
Ekoizpen-prozesuaren mapa teknologikoa
Gure etapa eta urrats guztiak hartzen baditugu, etiketarekin kodetzen baditugu eta kate batean zabaltzen baditugu, orduan oso luzea eta ulergaitza izango da (artikuluaren hasieran hitz egin genuen "pitoi buztana" bera) :
[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]Hauek dira produktuak muntatzeko [Eraiki], probako zerbitzarietan inplementatzeko [Inplementatu], probatzeko [Probatzeko], probaren emaitzetan oinarritutako biltegiak askatzeko muntaketak sustatzea [Sustatu], lizentziak sortu eta argitaratzea [Lizentzia], argitaratzea [Argitaratu] GUS eguneratze zerbitzarian eta FLUS eguneraketak zerbitzarietara bidaltzea, produktuaren osagaien instalazioa eta eguneratzea bezeroaren azpiegituran Product Configuration Management [Instalatu] erabiliz, baita instalatutako produktuen telemetria [Telemetria] biltzea ere.
Horietaz gain, fase bereiziak bereiz ditzakegu: azpiegituren egoeraren jarraipena [InfMonitoring], iturburu-kodearen bertsioak kudeatzea [SourceCodeControl], muntaia-ingurunea prestatzea [Prestatu], proiektuen kudeaketa [Workflow], taldeei komunikazio tresnak ematea [ Komunikazioa], produktuaren ziurtapena [Ziurtagiria] eta CI prozesuen autosufizientzia bermatzea [CISelfSufficiency] (adibidez, batzarren independentzia Internetekiko). Gure prozesuetan dozenaka urrats ere ez ditugu kontuan hartuko, oso zehatzak direlako.
Askoz errazagoa izango da ekoizpen-prozesu osoa ulertzea eta aztertzea, forman imajinatzen baduzu mapa teknologikoa; Taula bat da, non Ereduaren ekoizpen-etapa indibidualak eta deskonposatutako urratsak errenkadetan erregistratzen dira, eta zutabeetan etapa edo urrats bakoitzean egiten denaren deskribapena. Etapa bakoitzak eskaintzen dituen baliabideak eta ardura-eremuak mugatzea da azpimarra nagusia.
Guretzat, mapa sailkatzaile moduko bat da. Produktuen ekoizpenaren zati teknologiko handiak islatzen ditu. Horri esker, gure automatizazio-taldearentzat errazagoa izan da garatzaileekin elkarreragina eta automatizazio faseen ezarpena elkarrekin planifikatzea, baita horretarako zer lan-kostu eta baliabide (giza eta hardware) beharko diren ulertzea ere.
Gure enpresaren barruan, mapa automatikoki jinja txantiloi batetik sortzen da HTML fitxategi arrunt gisa, eta gero GitLab Pages zerbitzarira kargatzen da. Erabat sortutako mapa baten adibide batekin pantaila-argazkia ikus daiteke .
Egin klik irudian tamaina osoan irekitzeko
Laburbilduz, mapa teknologikoa produkzio-prozesuaren irudi orokor bat da, funtzionalitate estandarra duten bloke argi eta garbi islatzen dituena.
Gure mapa teknologikoaren egitura
Mapak hainbat zati ditu:
- Goiburu-eremua - hona hemen maparen deskribapen orokorra, oinarrizko kontzeptuak sartzen dira eta ekoizpen-prozesuaren baliabide eta emaitza nagusiak zehazten dira.
- Informazio panela - hemen produktu indibidualen datuen bistaratzea kontrola dezakezu; inplementatutako faseen eta, oro har, produktu guztien pausoen laburpena eskaintzen da.
- Mapa teknologikoa - prozesu teknologikoaren deskribapen taula. Mapan:
- etapa, urrats eta haien kodeak ematen dira;
- etapen deskribapen labur eta osoak ematen dira;
- fase bakoitzean erabilitako sarrera-baliabideak eta zerbitzuak adierazten dira;
- etapa bakoitzaren eta urrats indibidualaren emaitzak adierazten dira;
- etapa eta urrats bakoitzeko erantzukizun-eremua adierazten da;
- baliabide teknikoak zehaztu dira, adibidez, HDD (SSD), RAM, vCPU eta fase honetan lan egiteko beharrezkoak diren lan-orduak, bai gaur egun, bai etorkizuneko planak;
- produktu bakoitzerako zein fase edo urrats teknologiko ezarri diren, ezartzeko aurreikusita dauden, garrantzirik gabekoak edo ezarri ez diren adierazten da.
Mapa teknologikoan oinarrituta erabakiak hartzea
Mapa aztertu ondoren, ekintza batzuk egin ditzakezu, langileak enpresan duen eginkizunaren arabera (garapen arduraduna, produktuaren arduraduna, garatzailea edo probatzailea):
- benetako produktu edo proiektu batean zein fase falta diren ulertzea eta horiek ezartzeko beharra baloratzea;
- Hainbat sailen artean ardura-eremuak mugatzea, fase ezberdinetan ari badira;
- faseetako sarrera-irteeretarako kontratuak negoziatzea;
- zure lan-etapa garapen-prozesu orokorrean integratzea;
- zehatzago ebaluatzea etapa bakoitzari laguntzeko baliabideen beharra.
Aurreko guztia laburbilduz
Mapa teknologikoa aldakorra, hedagarria eta mantentzen erraza da. Askoz errazagoa da prozesuen deskribapenak forma honetan garatzea eta mantentzea IDEF0 eredu akademiko zorrotzean baino. Gainera, deskribapen taula bat eredu funtzional bat baino sinpleagoa, ezagunagoa eta egituratuagoa da.
Barne-tresna berezi bat, CrossBuilder, urratsen inplementazio teknikoaz arduratzen da - CI sistemen, zerbitzuen eta azpiegituren arteko geruza-tresna bat. Garatzaileak ez du bizikleta moztu behar: gure CI sisteman nahikoa da CrossBuilder tresnaren scriptetako bat (zeregin deritzona) exekutatzen duena, zuzen exekutatuko duena, gure azpiegituraren ezaugarriak kontuan hartuta.
Emaitzak
Artikulua nahiko luzea izan zen, baina hori saihestezina da prozesu konplexuen modelizazioa deskribatzean. Bukatzeko, gure ideia nagusiak laburki adierazi nahi nituzke:
- Gure enpresan DevOps ideiak sartzearen helburua konpainiaren produktuen ekoizpen eta mantentze-kostua modu kuantitatiboetan etengabe murriztea da (gizon-orduak edo makina-orduak, vCPU, RAM, Diskoa).
- Garapenaren kostu orokorra murrizteko modu bat serieko zeregin estandarrak egitearen kostua gutxitzea da: prozesu teknologikoaren faseak eta urratsak.
- Zeregin arrunta bere konponbidea guztiz edo partzialki automatizatuta dagoen zeregina da, ez die zailtasunik eragiten interpreteei eta ez du lan-kostu handirik behar.
- Ekoizpen-prozesua fasez osatuta dago, faseak urrats zatiezinetan banatzen dira, eskala eta bolumen ezberdinetako zeregin tipikoak adierazten dituztenak.
- Zeregin estandar isolatuetatik kate teknologiko konplexuetara eta produkzio-prozesuaren maila anitzeko ereduetara iritsi gara, IDEF0 eredu funtzional baten bidez edo mapa teknologiko sinpleago baten bidez deskriba daitezkeenak.
- Fluxu-diagrama produkzio-prozesu baten faseen eta pausoen taula-irudikapena da. Garrantzitsuena: mapak prozesu osoa bere osotasunean ikusteko aukera ematen du, zati handitan xehetasunak emateko aukerarekin.
- Mapa teknologikotik abiatuta, produktu jakin batean etapak ezartzeko beharra baloratu, erantzukizun-eremuak mugatu, etapetako sarrera-irteeretarako kontratuak adostu eta baliabideen beharra zehatzago baloratu dezakezu.
Hurrengo artikuluetan zehatzago hitz egingo dugu zer tresna tekniko erabiltzen diren gure mapan etapa teknologiko batzuk ezartzeko.
Artikuluaren egileak:
- — Positive Technologies-ko Automatizazio Saileko (DevOps) burua
- - diputatua Positive Technologies-ko Automatizazio Saileko (DevOps) burua
Iturria: www.habr.com