Slika:
Bok svima! Mi smo inženjeri automatizacije iz tvrtke i pružamo podršku za razvoj proizvoda tvrtke: podržavamo cijeli proces sklapanja od upisivanja linije koda od strane programera do objavljivanja gotovih proizvoda i licenci na poslužiteljima za ažuriranje. Neformalno, zovemo se DevOps inženjeri. U ovom članku želimo govoriti o tehnološkim fazama procesa proizvodnje softvera, kako ih vidimo i kako ih klasificiramo.
Iz materijala ćete naučiti o složenosti koordinacije razvoja više proizvoda, što je tehnološka mapa i kako pomaže organizirati i replicirati rješenja, od kojih se glavnih faza i koraka sastoji razvojni proces, kako su razgraničena područja odgovornosti između DevOps-a i timova u našoj tvrtki.
O kaosu i DevOpsu
Ukratko napomenimo da koncept DevOps uključuje razvojne alate i usluge te metodologije i najbolje prakse za njihovo korištenje. Istaknimo globalno cilj od implementacije DevOps ideja u našoj tvrtki: ovo je dosljedno smanjenje troškova proizvodnje i održavanja proizvoda u kvantitativnom smislu (ljudski ili strojni sati, CPU, RAM, Disk itd.). Najjednostavniji i najočitiji način smanjenja ukupnih troškova razvoja na razini cijele tvrtke jest minimiziranje troškova izvođenja tipičnih serijskih zadataka u svim fazama proizvodnje. Ali koje su to faze, kako se mogu razlikovati od općeg procesa, od kojih se koraka sastoje?
Kad tvrtka razvija jedan proizvod, sve je više-manje jasno: obično postoji opći plan i shema razvoja. Ali što učiniti kada se linija proizvoda proširi i ima više proizvoda? Na prvi pogled, imaju slične procese i pokretne trake i počinje igra "pronađi X razlike" u zapisnicima i skriptama. Što ako već postoji 5+ projekata u aktivnom razvoju i potrebna je podrška za nekoliko verzija koje su se razvijale tijekom nekoliko godina? Želimo li ponovno upotrijebiti što više rješenja u proizvodnim programima ili smo spremni potrošiti novac na jedinstveni razvoj za svako?
Kako pronaći ravnotežu između jedinstvenosti i serijalnosti rješenja?
Ova pitanja počela su nam se sve češće nametati od 2015. godine. Broj proizvoda je rastao, a naš odjel za automatizaciju (DevOps), koji je podržavao montažne trake ovih proizvoda, nastojali smo proširiti na minimum. U isto vrijeme, želio sam 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: "Društvo, možemo li nekako procijeniti što DevOps čini za proizvode?"
Mi: "Ne znamo, nismo postavili ovo pitanje, ali koje pokazatelje treba izračunati?"
Direktor razvoja: "Tko zna! Razmišljati..."
Kao u onom poznatom filmu: “Idem u hotel!..” - “Uh... Možete li mi pokazati put?” Nakon razmišljanja došli smo do zaključka da prvo trebamo odlučiti o konačnom stanju proizvoda; ovo je postao naš prvi cilj.
Dakle, kako možete 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 Chaosa, odnosno DevOps na oštricama
Započeli smo 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 ti se kvadrati za svaki projekt mogu uvući u rep dugog pitona u 50+ koraka. Osjećao sam se tužno i htio sam zavijati na mjesec - nikako mi nije odgovaralo.
Tipični proizvodni zadaci
Modeliranje proizvodnih procesa vrlo je 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 krenuli s modeliranjem našeg proizvodnog procesa, imali smo specifičan cilj - prenijeti svakom zaposleniku koji je uključen u razvoj proizvoda naše tvrtke i voditeljima projekata:
- kako proizvodi i njihove komponente, počevši od predaje retka koda, dolaze do kupca u obliku programa za instalaciju i ažuriranja,
- koji su resursi osigurani u svakoj fazi proizvodnje proizvoda,
- koje su usluge uključene u svakoj fazi,
- kako su područja odgovornosti razgraničena za svaku fazu,
- koji ugovori postoje na ulazu i izlazu svake faze.
Kliknite na sliku za otvaranje u punoj veličini
Naš rad u tvrtki podijeljen je u nekoliko funkcionalnih područja. Odjel infrastrukture bavi se optimizacijom rada svih hardverskih resursa odjela, kao i automatizacijom postavljanja virtualnih strojeva i okruženja na njima. Monitoring direkcija osigurava kontrolu nad izvođenjem usluga 24/7; Također nudimo praćenje kao uslugu za programere. Smjer tijeka rada timovima pruža alate za upravljanje procesima razvoja i testiranja, analiziranje statusa koda i dobivanje analitike na projektima. I na kraju, smjer webdev osigurava objavljivanje izdanja na GUS i FLUS serverima za ažuriranje, kao i licenciranje proizvoda korištenjem usluge LicenseLab. Kako bismo podržali proizvodni proces, postavili smo i održavamo mnoge različite usluge podrške za programere (možete poslušati priče o nekima od njih na starim susretima: и). Također razvijamo interne alate za automatizaciju, uključujući .
U proteklih pet godina u našem radu nakupilo se puno sličnih i rutinskih operacija, te tzv tipični zadaci, čije je rješavanje potpuno ili djelomično automatizirano, ne stvara poteškoće izvođačima i ne zahtjeva značajne količine posla. Zajedno s vodećim područjima analizirali smo takve zadatke i uspjeli identificirati pojedine kategorije rada, odn faze proizvodnje, faze su podijeljene u nedjeljive korake, a nekoliko faza se zbraja lanac proizvodnog procesa.
Najjednostavniji primjer tehnološkog lanca su faze montaže, postavljanja i testiranja svakog našeg proizvoda unutar tvrtke. Zauzvrat, na primjer, faza izgradnje sastoji se od mnogo odvojenih standardnih koraka: preuzimanje izvora iz GitLaba, priprema ovisnosti i biblioteka trećih strana, testiranje jedinica i analiza statičkog koda, izvršavanje skripte za izgradnju na GitLab CI, objavljivanje artefakata u repozitorij na Artifactory i generiranje napomena o izdanju putem našeg internog alata ChangelogBuilder.
Možete pročitati o tipičnim DevOps zadacima u našim drugim člancima na Habréu: “"A"".
Formiraju se mnogi tipični proizvodni lanci proizvodni proces. Standardni pristup opisivanju procesa je korištenje funkcionalnih IDEF0 modela.
Primjer modeliranja proizvodnog CI procesa
Posebnu pozornost posvetili smo izradi tipskih projekata za sustav kontinuirane integracije. Time je omogućeno postizanje objedinjavanja projekata, ističući tzv dijagram izdanja međuverzija s promocijama.
Evo kako to radi. Svi projekti izgledaju tipično: uključuju konfiguraciju sklopova koji idu u repozitorij snimaka na Artifactoryju, nakon čega se postavljaju i testiraju na testnim stolovima, a zatim promiču u repozitorij za izdanje. Usluga Artifactory jedinstvena je točka za distribuciju svih artefakata izgradnje između timova i drugih usluga.
Ako uvelike pojednostavimo i generaliziramo našu shemu izdanja, ona uključuje sljedeće faze:
- izrada proizvoda na više platformi,
- postavljanje na ispitne stolove,
- pokretanje funkcionalnih i drugih testova,
- promicanje testiranih sklopova za izdavanje spremišta na Artifactoryju,
- objavljivanje verzija izdanja za ažuriranje poslužitelja,
- isporuka nadogradnji i ažuriranja za proizvodnju,
- pokretanje instalacije i ažuriranja proizvoda.
Razmotrimo, kao primjer, tehnološki model ove tipične sheme izdanja (u daljnjem tekstu jednostavno Model) u obliku funkcionalnog IDEF0 modela. Odražava glavne faze našeg CI procesa. IDEF0 modeli koriste tzv ICOM notacija (Input-Control-Output-Mechanism) kako bi se opisalo koji se resursi koriste u svakoj fazi, na temelju kojih se pravila i zahtjeva obavlja posao, koji je izlaz i koji mehanizmi, usluge ili ljudi provode određenu fazu.
Kliknite na sliku za otvaranje u punoj veličini
U pravilu je u funkcionalnim modelima lakše raščlaniti i detaljno opisati procese. Ali kako broj elemenata raste, postaje sve teže razumjeti nešto o njima. Ali u stvarnom razvoju postoje i pomoćne faze: praćenje, certificiranje proizvoda, automatizacija radnih procesa i drugo. Upravo zbog problema skaliranja odustali smo od ovog opisa.
Rođenje nade
U jednoj smo knjizi naišli na stare sovjetske karte s opisima tehnoloških procesa (koje se, usput rečeno, i danas koriste u mnogim državnim poduzećima i sveučilištima). Čekaj, čekaj, mi također imamo tehnološki proces!.. Postoje faze, rezultati, metrika, zahtjevi, indikatori, itd., itd... Zašto ne bismo pokušali primijeniti tehnološke mape na naše pokretne trake proizvoda? Postojao je osjećaj: „To je to! Pronašli smo pravu nit, vrijeme je da je dobro povučemo!"
U jednostavnu tablicu odlučili smo proizvode bilježiti po stupcima, a tehnološke faze i korake proizvodne trake po redovima. Faze su nešto veliko, kao što je faza sastavljanja proizvoda. A koraci su nešto manje i detaljnije, na primjer, korak preuzimanja izvornog koda na poslužitelj za izgradnju ili korak kompajliranja koda.
Na sjecištima redaka i stupaca karte postavljamo statuse za određenu fazu i proizvod. Za statuse su definirana mnoga stanja:
- Nema podataka - ili nepraktično. Potrebno je analizirati potražnju za fazom u proizvodu. Ili je analiza već obavljena, ali faza trenutno nije potrebna ili nije ekonomski opravdana.
- Odgođeno - ili nije relevantno u ovom trenutku. Ova faza u planu je potrebna, ali nema energije da se realizira ove godine.
- Planirani. Pozornica je planirana za realizaciju ove godine.
- Provedeno. Faza u cjevovodu je izvedena u potrebnoj mjeri.
Ispunjavanje tablice počelo je projekt po projekt. Prvo smo klasificirali faze i korake jednog projekta i zabilježili njihove statuse. Zatim su uzeli sljedeći projekt, zabilježili 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. Rezultat je nešto slično matrici kompetencija za pokretnu traku hrane. Takvu matricu nazvali smo tehnološka karta.
Uz pomoć tehnološke karte mjeriteljski sadržajno s timovima dogovaramo planove rada za godinu i ciljeve koje želimo zajednički postići: koje faze dodajemo projektu ove godine, a koje ostavljamo za kasnije. Također, dok radimo, možemo vidjeti poboljšanja koraka koje smo izvršili samo za jedan proizvod. Zatim proširujemo našu mapu i uvodimo to poboljšanje kao fazu ili novi korak, zatim provodimo analizu za svaki proizvod i otkrivamo izvedivost repliciranja poboljšanja.
Mogu nam prigovoriti: „Sve je to dobro, naravno, ali s vremenom će broj koraka i faza postati pretjerano velik. Što da napravim?
Uveli smo standardne i prilično potpune opise zahtjeva za svaku fazu i korak kako bi ih unutar tvrtke svi razumjeli na isti način. Tijekom vremena, kako se poboljšanja implementiraju, korak se može apsorbirati u drugi stupanj ili korak - tada će se urušiti. Istodobno, svi zahtjevi i tehnološke nijanse uklapaju se u zahtjeve generalizirajuće faze ili koraka.
Kako procijeniti učinak ponavljanja rješenja? Koristimo iznimno jednostavan pristup: početne kapitalne troškove za implementaciju nove faze pripisujemo godišnjim općim troškovima proizvoda, a zatim ih dijelimo među svima tijekom replikacije.
Dijelovi razvoja već se odražavaju kao faze i koraci na karti. Na smanjenje troškova proizvoda možemo utjecati uvođenjem automatizacije tipičnih faza. Nakon toga izračunavamo promjene u kvalitativnim karakteristikama, kvantitativnoj metrici i dobiti koju ostvaruju timovi (u ušteđenim ljudskim ili strojnim satima).
Tehnološka karta proizvodnog procesa
Ako uzmemo sve naše faze i korake, kodiramo ih oznakama i proširimo ih u jedan lanac, tada će ispasti vrlo dugo i nerazumljivo (točno isti "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 sastavljanja proizvoda [Build], njihove implementacije na testne poslužitelje [Deploy], testiranja [Test], promicanja sklopova za izdavanje repozitorija na temelju rezultata testiranja [Promote], generiranja i objavljivanja licenci [License], objavljivanja [Publish] na GUS serveru za ažuriranje i isporuku FLUS ažuriranja na poslužitelje, instalaciju i ažuriranje komponenti proizvoda na korisnikovoj infrastrukturi korištenjem upravljanja konfiguracijom proizvoda [Install], kao i prikupljanje telemetrije [Telemetry] od instaliranih proizvoda.
Osim njih, izdvajamo zasebne faze: praćenje stanja infrastrukture [InfMonitoring], upravljanje verzijama izvornog koda [SourceCodeControl], priprema okruženja sklopa [Prepare], upravljanje projektom [Workflow], opskrba timova komunikacijskim alatima [ Komunikacija], certifikacija proizvoda [Certification] i osiguravanje samodostatnosti CI procesa [CISelfSufficiency] (primjerice, neovisnost sklopova o Internetu). Nećemo ni razmatrati desetke koraka u našim procesima jer su vrlo specifični.
Bit će vam puno lakše razumjeti i sagledati cijeli proizvodni proces zamislite li ga u obliku tehnološka karta; Ovo je tablica u kojoj su u redovima zabilježene pojedinačne proizvodne faze i dekomponirani koraci Modela, au stupcima opis onoga što se radi u svakoj fazi ili koraku. Glavni naglasak je na resursima koji osiguravaju svaku fazu i razgraničenje područja odgovornosti.
Za nas je karta neka vrsta klasifikatora. Odražava velike tehnološke dijelove proizvodnje proizvoda. Zahvaljujući tome, našem timu za automatizaciju postalo je lakše komunicirati s 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 tvrtke, karta se automatski generira iz jinja predloška kao obična HTML datoteka, a zatim se učitava na poslužitelj GitLab Pages. Može se pogledati snimka zaslona s primjerom potpuno generirane karte .
Kliknite na sliku za otvaranje u punoj veličini
Ukratko, tehnološka karta je generalizirana slika proizvodnog procesa, koja odražava jasno klasificirane blokove sa standardnom funkcionalnošću.
Struktura naše tehnološke karte
Karta se sastoji od nekoliko dijelova:
- Područje naslova - ovdje je opći opis karte, uvode se osnovni koncepti i definiraju glavni resursi i rezultati proizvodnog procesa.
- Informacijska ploča - 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 karti:
- navedeni su svi stupnjevi, koraci i njihovi kodovi;
- daju se kratki i potpuni opisi faza;
- navedeni su ulazni resursi i usluge korištene u svakoj fazi;
- naznačeni su rezultati svake faze i pojedinačnog koraka;
- naznačeno je područje odgovornosti za svaku fazu i korak;
- utvrđeni su tehnički resursi, npr. HDD (SSD), RAM, vCPU, te radni sati potrebni za podršku radu u ovoj fazi, kako trenutno – č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 su ili nisu implementirani.
Donošenje odluka na temelju tehnološke karte
Nakon proučavanja karte, možete poduzeti neke radnje, ovisno o ulozi zaposlenika u tvrtki (voditelj razvoja, voditelj proizvoda, programer ili tester):
- razumjeti koje faze nedostaju u stvarnom proizvodu ili projektu i procijeniti potrebu za njihovom provedbom;
- razgraničiti područja odgovornosti između nekoliko odjela ako rade u različitim fazama;
- pregovarati o ugovorima za ulaze i izlaze faza;
- integrirati svoju fazu rada u cjelokupni proces razvoja;
- točnije procijeniti potrebu za resursima za podršku svakoj fazi.
Rezimirajući sve navedeno
Tehnološka karta je svestrana, proširiva i jednostavna za održavanje. Mnogo je lakše razviti i održavati opise procesa u ovom obliku nego u strogom akademskom IDEF0 modelu. Osim toga, tablični opis je jednostavniji, poznatiji i bolje strukturiran od funkcionalnog modela.
Za tehničku implementaciju koraka zaslužan je poseban interni alat CrossBuilder - alat za slojevitost između CI sustava, usluga i infrastrukture. Programer ne treba rezati svoj bicikl: u našem CI sustavu dovoljno je pokrenuti jednu od skripti (tzv. zadatak) alata CrossBuilder, koji će je ispravno izvršiti, uzimajući u obzir značajke naše infrastrukture.
Rezultati
Članak je ispao prilično dug, ali to je neizbježno kada se opisuje modeliranje složenih procesa. Na kraju bih želio ukratko iznijeti naše glavne ideje:
- Cilj uvođenja DevOps ideja u našu tvrtku je dosljedno smanjenje troškova proizvodnje i održavanja proizvoda tvrtke u kvantitativnom smislu (ljudski ili strojni sati, vCPU, RAM, Disk).
- Način smanjenja ukupnih troškova razvoja je minimiziranje troškova izvođenja standardnih serijskih zadataka: faza i koraka tehnološkog procesa.
- Tipični zadatak je zadatak čije je rješavanje potpuno ili djelomično automatizirano, ne stvara poteškoće izvođačima i ne zahtijeva značajne troškove rada.
- Proizvodni proces sastoji se od faza, faze su podijeljene na nedjeljive korake, koji predstavljaju tipične zadatke različitih mjerila i obujma.
- Od izoliranih standardnih zadataka došli smo do složenih tehnoloških lanaca i višerazinskih modela proizvodnog procesa koji se mogu opisati funkcionalnim IDEF0 modelom ili jednostavnijom tehnološkom kartom.
- Dijagram toka je tablični prikaz faza i koraka proizvodnog procesa. Ono što je najvažnije: karta vam omogućuje da vidite cijeli proces u cijelosti, u velikim komadima s mogućnošću detaljiziranja.
- Na temelju tehnološke karte možete procijeniti potrebu za implementacijom faza u pojedini proizvod, razgraničiti područja odgovornosti, dogovoriti ugovore za inpute i outpute faza te točnije procijeniti potrebu za resursima.
U sljedećim člancima ćemo detaljnije govoriti o tome koji se tehnički alati koriste za implementaciju određenih tehnoloških faza na našoj karti.
Autori članka:
- — Voditelj odjela za automatizaciju (DevOps) u Positive Technologies
- - zamjenik Voditelj odjela za automatizaciju (DevOps) u Positive Technologies
Izvor: www.habr.com