Slika:
Zdravo svima! Mi smo inženjeri automatizacije iz kompanije i podržavamo razvoj proizvoda kompanije: podržavamo čitav montažni proces od urezivanja linije koda od strane programera do objavljivanja gotovih proizvoda i licenci na serverima za ažuriranje. Neformalno se zovemo DevOps inženjeri. U ovom članku želimo govoriti o tehnološkim fazama procesa proizvodnje softvera, kako ih vidimo i kako ih klasifikujemo.
Iz materijala ćete naučiti o složenosti koordinacije razvoja više proizvoda, o tome što je tehnološka mapa i kako ona pomaže da se pojednostave i repliciraju rješenja, koje su glavne faze i koraci procesa razvoja, kako su područja odgovornosti između DevOps-a i timova u našoj kompaniji.
O Haosu i DevOps-u
Ukratko, koncept DevOps-a uključuje razvojne alate i usluge, kao i metodologije i najbolje prakse za njihovu upotrebu. Izdvojimo globalno svrhu od implementacije DevOps ideja u našoj kompaniji: ovo je dosledno smanjenje troškova proizvodnje i održavanja proizvoda u kvantitativnom smislu (radni sati ili mašinski sati, CPU, RAM, Disk, itd.). Najlakši i najočigledniji način da se smanje ukupni troškovi razvoja na nivou cijele kompanije je minimiziranje troškova izvođenja tipičnih serijskih zadataka u svim fazama proizvodnje. Ali koje su to faze, kako ih odvojiti od općeg procesa, od kojih se koraka sastoje?
Kada kompanija razvije jedan proizvod, sve je manje-više jasno: obično postoji zajednička mapa puta i šema razvoja. Ali što učiniti kada se linija proizvoda proširi i ima više proizvoda? Na prvi pogled imaju slične procese i montažne linije, a počinje igra “pronađi X razlike” u zapisnicima i skriptama. Ali što ako već postoji 5+ projekata u aktivnom razvoju i potrebna je podrška za nekoliko verzija razvijenih tijekom nekoliko godina? Da li želimo da ponovo iskoristimo maksimalni mogući broj rešenja u cevovodima proizvoda ili smo spremni da potrošimo novac na jedinstven razvoj za svako?
Kako pronaći balans između jedinstvenosti i serijskih rješenja?
Ova pitanja su nam se sve češće postavljala od 2015. godine. Broj proizvoda je rastao, a mi smo nastojali da naš odjel za automatizaciju (DevOps), koji je podržavao montažne linije ovih proizvoda, proširimo na minimum. Istovremeno, željeli smo replicirati što više rješenja između proizvoda. Uostalom, zašto istu stvar u deset proizvoda raditi na različite načine?
Direktor razvoja: "Momci, možemo li nekako procijeniti šta DevOps radi za proizvode?"
Mi: “Ne znamo, nismo postavili takvo pitanje, ali koje pokazatelje treba uzeti u obzir?”
Direktor razvoja: "Ko zna! Misli…”
Kao u onom čuvenom filmu: "U hotelu sam!.." - "Uh... Možete li mi pokazati put?" Razmišljajući, došli smo do zaključka da prvo trebamo odlučiti o konačnom stanju proizvoda; ovo je postao naš prvi cilj.
Dakle, kako analizirati desetak proizvoda s prilično velikim timovima od 10 do 200 ljudi i odrediti mjerljive metrike prilikom repliciranja rješenja?
1:0 u korist Haosa, odnosno DevOpsa na lopatice
Počeli smo s pokušajem primjene IDEF0 dijagrama i raznih dijagrama poslovnih procesa iz BPwin serije. Zabuna je počela nakon petog kvadrata sljedeće faze sljedećeg projekta, a ovi kvadrati za svaki projekat se mogu nacrtati u repu dugog pitona ispod 50+ koraka. Osećao sam se tužno i hteo sam da zavijam na mesec - uopšte nije odgovaralo.
Tipični proizvodni zadaci
Modeliranje proizvodnih procesa je vrlo složen i mukotrpan posao: potrebno je prikupiti, obraditi i analizirati mnogo podataka iz različitih odjela i proizvodnih lanaca. Više o tome možete pročitati u članku "".
Kada smo započeli modeliranje našeg proizvodnog procesa, imali smo specifičan cilj - svakom zaposleniku koji je uključen u razvoj proizvoda naše kompanije, kao i projekt menadžerima, prenijeti:
- kako proizvodi i njihove komponente, počevši od urezivanja linije koda, dođu do kupca u obliku instalatera i ažuriranja,
- koja su sredstva predviđena za svaku fazu proizvodnje proizvoda,
- koje su usluge uključene u svakoj fazi,
- kako su razgraničene oblasti odgovornosti za svaku fazu,
- koji ugovori postoje na ulazu i izlazu iz svake faze.
Klikom na sliku otvorit će se u punoj veličini
Naš rad u kompaniji podijeljen je u nekoliko funkcionalnih područja. Pravac infrastrukture se bavi optimizacijom rada svih „gvozdenih“ resursa odeljenja, kao i automatizacijom raspoređivanja virtuelnih mašina i okruženja na njima. Pravac nadzora omogućava kontrolu performansi usluge 24/7; takođe pružamo monitoring kao uslugu za programere. Smjer toka posla pruža timovima alate za upravljanje procesima razvoja i testiranja, analizu stanja koda i dobijanje analitičkih podataka o projektima. I na kraju, webdev pravac omogućava objavljivanje izdanja na serverima za ažuriranje GUS-a i FLUS-a, kao i licenciranje proizvoda pomoću usluge LicenseLab. Kako bismo podržali produkciju, postavili smo i održavamo mnogo različitih usluga podrške za programere (možete slušati priče o nekima od njih na starim okupljanjima: и). Takođe razvijamo interne alate za automatizaciju, uključujući .
U proteklih pet godina u našem radu nakupilo se dosta istovrstnih i rutinskih operacija, a naši programeri iz drugih odjela uglavnom dolaze iz tzv. tipični zadaci, čije je rješenje potpuno ili djelimično automatizovano, ne izaziva poteškoće izvođačima i ne zahteva značajne količine posla. Zajedno sa vodećim oblastima analizirali smo takve zadatke i uspjeli identificirati pojedine kategorije rada, odn proizvodnih koraka, faze su bile podijeljene u nedjeljive korake, a nekoliko faza se zbrajaju lanac proizvodnog procesa.
Najjednostavniji primjer tehnološkog lanca su faze montaže, implementacije i testiranja svakog našeg proizvoda unutar kompanije. Zauzvrat, na primjer, faza izgradnje sastoji se od mnogo odvojenih tipičnih koraka: preuzimanje izvora sa GitLab-a, priprema ovisnosti i biblioteka trećih strana, testiranje jedinica i statička analiza koda, izvršavanje skripte za izgradnju na GitLab CI, objavljivanje artefakata u spremištu na Artifaktura i generisanje bilješki o izdanju putem našeg internog ChangelogBuilder alata.
O tipičnim zadacima DevOps-a možete pročitati u našim drugim člancima na Habré-u: ""I"".
Formiraju se mnogi tipični proizvodni lanci proces proizvodnje. Standardni pristup opisivanju procesa je korištenje funkcionalnih IDEF0 modela.
Primjer modeliranja proizvodnog CI procesa
Posebnu pažnju smo posvetili izradi standardnih projekata za kontinuirani sistem integracije. Time je omogućeno da se postigne objedinjavanje projekata, ističući tzv objavi shemu izgradnje s promocijama.
Evo kako to funkcionira. Svi projekti izgledaju tipično: uključuju konfiguraciju sklopova koji padaju u spremište snimaka u Artifactory, nakon čega se postavljaju i testiraju na testnim stolovima, a zatim se promovišu u spremište izdanja. Usluga Artifactory je jedinstvena distributivna tačka za sve artefakte izgradnje između timova i drugih usluga.
Ako uvelike pojednostavimo i generaliziramo našu shemu izdavanja, ona uključuje sljedeće korake:
- sastavljanje proizvoda na više platformi,
- raspoređivanje na ispitnim stolovima,
- izvođenje funkcionalnih i drugih testova,
- promoviranje testiranih verzija za izdavanje spremišta u Artifactory,
- objavljivanje verzija izdanja na serverima za ažuriranje,
- isporuka sklopova i ažuriranja proizvodnje,
- pokretanje instalacije i ažuriranja proizvoda.
Na primjer, razmotrite tehnološki model ove tipične sheme izdanja (u daljem tekstu jednostavno Model) u obliku funkcionalnog IDEF0 modela. On odražava glavne faze našeg procesa CI. IDEF0 modeli koriste tzv ICOM notacija (Input-Control-Output-Mechanism) da se opiše koji se resursi koriste u svakoj fazi, na osnovu toga koja pravila i zahtjevi se obavljaju, kakav je rezultat i koji mehanizmi, usluge ili ljudi implementiraju određenu fazu.
Klikom na sliku otvorit će se u punoj veličini
U pravilu je lakše dekomponirati i detaljizirati opis procesa u funkcionalnim modelima. Ali kako broj elemenata raste, postaje sve teže razumjeti nešto u njima. Ali u stvarnom razvoju postoje i pomoćne faze: praćenje, sertifikacija proizvoda, automatizacija toka posla i druge. Zbog problema skaliranja napustili smo ovaj opis.
Rođenje nade
U jednoj knjizi naišli smo na stare sovjetske karte koje opisuju tehnološke procese (koje se, inače, i danas koriste u mnogim državnim preduzećima i univerzitetima). Čekaj, čekaj, jer i mi imamo tok posla!.. Postoje faze, rezultati, metrika, zahtjevi, indikatori, i tako dalje i tako dalje... Zašto ne bismo pokušali primijeniti i tokove toka na naše produkte? Postojao je osjećaj: „To je to! Našli smo pravu nit, vrijeme je da je dobro povučemo!
U jednostavnu tabelu odlučili smo da zabilježimo proizvode po kolonama, a tehnološke faze i korake produktovoda po redovima. Prekretnice su nešto veliko, kao što je korak izgradnje proizvoda. A koraci su nešto manje i detaljnije, kao što je korak preuzimanja izvornog koda na server za izgradnju ili korak kompajliranja koda.
Na sjecištima redova i stupaca karte ispisujemo statuse za određenu fazu i proizvod. Za statuse je definiran skup stanja:
- Nema informacija - ili neprikladan. Potrebno je analizirati potražnju za fazom u proizvodu. Ili je analiza već obavljena, ali faza trenutno nije potrebna ili nije ekonomski opravdana.
- Odloženo - ili nije relevantno u ovom trenutku. Potrebna je faza u pripremi, ali nema snage za implementaciju ove godine.
- Planirano. Etapa je planirana za realizaciju ove godine.
- Implementirano. Faza u cevovodu je implementirana u potrebnom obimu.
Popunjavanje tabele počelo je projekat po projekat. Prvo su klasifikovane faze i koraci jednog projekta i evidentiran njihov status. Zatim su uzeli sljedeći projekat, popravili statuse u njemu i dodali faze i korake koji su nedostajali u prethodnim projektima. Kao rezultat toga, dobili smo faze i korake cijelog našeg proizvodnog procesa i njihove statuse u konkretnom projektu. Ispalo je nešto slično matrici kompetencija za proizvod. Takvu matricu nazvali smo tehnološkom mapom.
Uz pomoć tehnološke karte, metrološki razumno koordiniramo s timovima planove rada za godinu i ciljeve koje želimo zajedno postići: koje faze dodajemo projektu ove godine, a koje ostavljamo za kasnije. Takođe, u toku rada možemo imati poboljšanja u fazama koje smo završili samo za jedan proizvod. Zatim širimo našu mapu i uvodimo ovo poboljšanje kao fazu ili novi korak, zatim analiziramo za svaki proizvod i saznajemo izvodljivost repliciranja poboljšanja.
Oni nam mogu prigovoriti: „Ovo je sve, naravno, dobro, samo će s vremenom broj koraka i faza postati neizmjerno veliki. Kako biti?
Uveli smo standardne i prilično potpune opise zahtjeva za svaku fazu i korak, tako da ih svi unutar kompanije razumiju na isti način. Vremenom, kako se uvode poboljšanja, korak se može apsorbovati u drugu fazu ili korak, a zatim će se „srušiti“. Istovremeno, svi zahtjevi i tehnološke nijanse uklapaju se u zahtjeve generalizirajuće faze ili koraka.
Kako procijeniti učinak repliciranja rješenja? Koristimo krajnje jednostavan pristup: početne kapitalne troškove za implementaciju nove faze pripisujemo godišnjim općim troškovima proizvoda, a zatim ih dijelimo na sve prilikom repliciranja.
Dijelovi razvoja već su prikazani kao prekretnice i koraci na mapi. Možemo utjecati na smanjenje cijene proizvoda kroz uvođenje automatizacije za tipične faze. Nakon toga razmatramo promjene u kvalitativnim karakteristikama, kvantitativnim metrikama i profitu koji su timovi primili (u radnim satima ili mašinskim satima uštede).
Tehnološka karta proizvodnog procesa
Ako preduzmemo sve naše faze i korake, kodiramo ih oznakama i proširimo ih u jedan lanac, onda će se ispostaviti da je jako dugačak i neshvatljiv (samo onaj "python rep" o kojem smo govorili na početku članka) :
[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]Ovo su faze izgradnje proizvoda [Build], njihova implementacija na servere za testiranje [Deploy], testiranje [Test], promoviranje buildova za izdavanje spremišta na osnovu rezultata testiranja [Promote], generiranje i objavljivanje licenci [License], objavljivanje [ Objavljivanje] na GUS serveru za ažuriranje i isporuka na FLUS servere za ažuriranje, instalacija i ažuriranje komponenti proizvoda na infrastrukturi korisnika pomoću upravljanja konfiguracijom proizvoda [Install], kao i prikupljanje telemetrije [Telemetrija] sa instaliranih proizvoda.
Pored njih, mogu se izdvojiti odvojene faze: praćenje stanja infrastrukture [InfMonitoring], verzioniranje izvornog koda [SourceCodeControl], priprema okruženja za izgradnju [Priprema], upravljanje projektom [Tok rada], pružanje timova komunikacijskim alatima [Komunikacija], certifikacija proizvoda [ Certifikacija] i osiguravanje samodovoljnosti CI procesa [CISelfSufficiency] (na primjer, nezavisnost sklopova od Interneta). Desetine koraka u našim procesima neće se ni razmatrati, jer su vrlo specifični.
Biće mnogo lakše razumeti i sagledati ceo proces proizvodnje ako se predstavi u formi tehnološka karta; ovo je tabela u kojoj su pojedinačne faze proizvodnje i dekomponovani koraci Modela ispisani u redovima, au kolonama opis onoga što se radi u svakoj fazi ili koraku. Glavni naglasak je stavljen na resurse koji obezbjeđuju svaku fazu, te razgraničenje područja odgovornosti.
Mapa je za nas neka vrsta klasifikatora. Ona odražava velike tehnološke dijelove proizvodnje proizvoda. Zahvaljujući tome, našem timu za automatizaciju postalo je lakše komunicirati sa programerima i zajednički planirati implementaciju faza automatizacije, kao i razumjeti koji će troškovi rada i resursi (ljudski i hardverski) biti potrebni za to.
Unutar naše kompanije, mapa se automatski generiše iz jinja šablona kao obična HTML datoteka, a zatim se postavlja na GitLab Pages server. Snimak ekrana sa primjerom potpuno generirane karte može se vidjeti .
Klikom na sliku otvorit će se u punoj veličini
Ukratko, tehnološka mapa je generalizirana slika proizvodnog procesa, koja odražava jasno klasificirane blokove sa tipičnom funkcionalnošću.
Struktura naše mape puta
Mapa se sastoji od nekoliko delova:
- Područje naslova - ovdje je opći opis karte, predstavljeni su osnovni koncepti, definirani su glavni resursi i rezultati proizvodnog procesa.
- Dashboard - ovdje možete kontrolirati prikaz podataka za pojedinačne proizvode, pruža se sažetak implementiranih faza i koraka općenito za sve proizvode.
- Tehnološka karta - tabelarni opis tehnološkog procesa. na mapi:
- date su sve faze, koraci i njihovi kodovi;
- dati su kratki i potpuni opisi faza;
- naznačeni su ulazni resursi i usluge koje se koriste u svakoj fazi;
- prikazani su rezultati svake faze i posebnog koraka;
- naznačeno je područje odgovornosti za svaku fazu i korak;
- utvrđeni su tehnički resursi, kao što su HDD (SSD), RAM, vCPU, i potrebni radni sati da se podrži rad u ovoj fazi, kako u ovom trenutku – činjenica, tako iu budućnosti – plan;
- za svaki proizvod je naznačeno koje su tehnološke faze ili koraci za njega implementirani, planirani za implementaciju, nebitni ili nisu implementirani.
Donošenje odluka na osnovu tehnološke karte
Nakon pregleda karte moguće je poduzeti neke radnje - ovisno o ulozi zaposlenika u kompaniji (menadžer razvoja, menadžer proizvoda, programer ili tester):
- razumjeti koje faze nedostaju u stvarnom proizvodu ili projektu i procijeniti potrebu za njihovom implementacijom;
- razgraničiti područja odgovornosti između nekoliko odjela ako rade u različitim fazama;
- dogovoriti ugovore na ulazima i izlazima bina;
- integrirati svoju fazu rada u cjelokupni razvojni proces;
- preciznije procijeniti potrebu za resursima koji obezbjeđuju svaku od faza.
Sumirajući sve navedeno
Rutiranje je raznovrsno, proširivo i lako za održavanje. Mnogo je lakše razviti i održavati opis procesa u ovom obliku nego u strogom akademskom IDEF0 modelu. Osim toga, tabelarni opis je jednostavniji, poznatiji i bolje strukturiran od funkcionalnog modela.
Za tehničku implementaciju koraka imamo poseban interni alat CrossBuilder - slojni alat između CI sistema, servisa i infrastrukture. Programer ne mora rezati svoj bicikl: u našem CI sistemu dovoljno je pokrenuti jednu od skripti (tzv. zadatak) alata CrossBuilder, koji će ga ispravno izvršiti, uzimajući u obzir karakteristike naše infrastrukture .
Ishodi
Članak se pokazao prilično dugim, ali to je neizbježno kada se opisuje modeliranje složenih procesa. Na kraju, želio bih ukratko popraviti naše glavne ideje:
- Cilj implementacije DevOps ideja u našoj kompaniji je dosledno smanjenje troškova proizvodnje i održavanja proizvoda kompanije u kvantitativnom smislu (radni ili mašinski sati, vCPU, RAM, Disk).
- Način smanjenja ukupnih troškova razvoja je minimiziranje troškova izvođenja tipičnih serijskih zadataka: faza i koraka tehnološkog procesa.
- Tipičan zadatak je zadatak čije je rješavanje potpuno ili djelomično automatizirano, ne uzrokuje poteškoće izvođačima i ne zahtijeva značajne troškove rada.
- Proizvodni proces se sastoji od faza, faze su podijeljene u nedjeljive korake, koji su tipični zadaci različitog obima i obima.
- Od raznorodnih tipičnih zadataka došli smo do složenih tehnoloških lanaca i višeslojnih modela proizvodnog procesa, koji se mogu opisati funkcionalnim IDEF0 modelom ili jednostavnijom tehnološkom mapom.
- Tehnološka karta je tabelarni prikaz faza i koraka proizvodnog procesa. Ono što je najvažnije: karta vam omogućava da vidite cijeli proces u cjelini, u velikim dijelovima s mogućnošću detaljnijeg detaljisanja.
- Na osnovu tehnološke mape moguće je procijeniti potrebu uvođenja faza u pojedini proizvod, razgraničiti područja odgovornosti, dogovoriti ugovore na ulazima i izlazima faza, te preciznije procijeniti potrebu za resursima.
U sljedećim člancima ćemo detaljnije opisati koji se tehnički alati koriste za implementaciju određenih tehnoloških faza na našoj karti.
Autori članaka:
- — šef automatizacije (DevOps) u Positive Technologies
- - Zamenik Šef odjela za automatizaciju (DevOps) u Positive Technologies
izvor: www.habr.com