Paveikslėlis:
Sveiki visi! Esame įmonės automatikos inžinieriai ir mes palaikome įmonės produktų kūrimą: palaikome visą surinkimo procesą nuo kūrėjų atliekamo kodo eilutės įvedimo iki gatavų produktų ir licencijų paskelbimo atnaujinimo serveriuose. Neoficialiai esame vadinami „DevOps“ inžinieriais. Šiame straipsnyje norime pakalbėti apie programinės įrangos gamybos proceso technologinius etapus, kaip juos matome ir kaip juos klasifikuojame.
Iš medžiagos sužinosite apie kelių produktų kūrimo koordinavimo sudėtingumą, apie tai, kas yra technologinis žemėlapis ir kaip jis padeda racionalizuoti ir atkartoti sprendimus, kokie yra pagrindiniai kūrimo proceso etapai ir žingsniai, kokios yra atsakomybės sritys. tarp „DevOps“ ir mūsų įmonės komandų.
Apie Chaosą ir DevOps
Trumpai tariant, „DevOps“ koncepcija apima kūrimo įrankius ir paslaugas, taip pat metodikas ir geriausią jų naudojimo praktiką. Išskirkime globalius tikslas nuo DevOps idėjų įgyvendinimo mūsų įmonėje: tai nuoseklus produktų gamybos ir priežiūros kaštų mažinimas kiekybine išraiška (žmogaus darbo valandos arba mašinos valandos, CPU, RAM, Diskas ir kt.). Lengviausias ir akivaizdžiausias būdas sumažinti bendras plėtros išlaidas visos įmonės lygiu yra sumažinti tipinių serijinių užduočių atlikimo išlaidas visuose gamybos etapuose. Bet kas tai yra etapai, kaip juos atskirti nuo bendro proceso, iš kokių žingsnių jie susideda?
Kai įmonė kuria vieną produktą, viskas daugmaž aišku: dažniausiai yra bendras planas ir plėtros schema. Tačiau ką daryti, kai prekių linija plečiasi ir prekių daugėja? Iš pirmo žvilgsnio jie turi panašius procesus ir surinkimo linijas, ir prasideda žaidimas „rasti X skirtumus“ žurnaluose ir scenarijuose. Bet ką daryti, jei jau aktyviai vystomi 5+ projektai ir reikalingas kelių versijų, sukurtų per kelerius metus, palaikymas? Ar norime pakartotinai panaudoti maksimalų įmanomą sprendimų skaičių gaminių vamzdynuose, ar esame pasirengę išleisti pinigus kiekvienam unikaliam vystymuisi?
Kaip rasti balansą tarp unikalumo ir serijinių sprendimų?
Šie klausimai mums vis dažniau kilo nuo 2015 m. Gaminių skaičius augo, mes stengėmės iki minimumo išplėsti savo automatikos skyrių (DevOps), kuris palaikė šių produktų surinkimo linijas. Tuo pačiu metu norėjome atkartoti kuo daugiau sprendimų tarp produktų. Galų gale, kodėl tą patį dalyką daryti dešimtyje produktų skirtingais būdais?
Vystymosi direktorius: "Vaikinai, ar galime kaip nors įvertinti, ką "DevOps" daro gaminiams?"
Mes: „Nežinome, tokio klausimo neuždavėme, bet į kokius rodiklius reikėtų atsižvelgti?
Vystymosi direktorius: "Kas žino! Pagalvok…”
Kaip tame garsiame filme: „Aš viešbutyje!..“ – „Ai... Ar gali man parodyti kelią?“ Pagalvoję padarėme išvadą, kad pirmiausia turime nuspręsti dėl galutinės gaminių būsenos; tai tapo pirmuoju mūsų įvarčiu.
Taigi, kaip išanalizuoti keliolika produktų su gana didelėmis komandomis nuo 10 iki 200 žmonių ir nustatyti išmatuojamus rodiklius atkartojant sprendimus?
1:0 Chaos naudai arba DevOps ant menčių
Pradėjome nuo bandymo pritaikyti IDEF0 diagramas ir įvairias verslo procesų diagramas iš BPwin serijos. Sumišimas prasidėjo po penkto kito kito projekto etapo kvadrato, o šiuos kiekvieno projekto kvadratus galima nupiešti ilgo pitono uodegoje po 50+ žingsnių. Jaučiausi liūdnas ir norėjau staugti į mėnulį - apskritai tai netiko.
Tipinės gamybos užduotys
Gamybos procesų modeliavimas yra labai sudėtingas ir kruopštus darbas: reikia surinkti, apdoroti ir analizuoti daug duomenų iš įvairių padalinių ir gamybos grandinių. Daugiau apie tai galite perskaityti straipsnyje "".
Pradėję modeliuoti gamybos procesą, turėjome konkretų tikslą – perteikti kiekvienam darbuotojui, dalyvaujančiam mūsų įmonės produktų kūrime, ir projektų vadovams:
- kaip produktai ir jų komponentai, pradedant nuo kodo eilutės įvedimo, pasiekia klientą montuotojų ir atnaujinimų forma,
- kokie ištekliai yra numatyti kiekvienam produktų gamybos etapui,
- kokios paslaugos dalyvauja kiekviename etape,
- kaip atskirtos kiekvieno etapo atsakomybės sritys,
- kokios sutartys egzistuoja prie kiekvieno etapo įėjimo ir išėjimo.
Paspaudus ant paveikslėlio jis bus atidarytas visu dydžiu
Mūsų darbas įmonėje suskirstytas į kelias funkcines sritis. Infrastruktūros kryptis užsiima visų skyriaus „geležinių“ resursų veikimo optimizavimu, taip pat virtualių mašinų ir jose esančios aplinkos diegimo automatizavimu. Stebėjimo kryptis užtikrina paslaugų teikimo kontrolę 24/7; taip pat teikiame stebėjimą kaip paslaugą kūrėjams. Darbo eigos kryptis suteikia komandoms įrankius, skirtus valdyti kūrimo ir testavimo procesus, analizuoti kodo būseną ir gauti projektų analizę. Ir galiausiai, žiniatinklio devėjo kryptis numato leidimų paskelbimą GUS ir FLUS naujinimo serveriuose, taip pat produktų licencijavimą naudojant „LicenseLab“ paslaugą. Siekdami palaikyti gamybinį vamzdyną, sukūrėme ir prižiūrime daugybę įvairių pagalbinių paslaugų kūrėjams (apie kai kurias istorijas galima išgirsti senuose susitikimuose: и). Taip pat kuriame vidines automatizavimo priemones, įskaitant .
Per pastaruosius penkerius metus mūsų darbe susikaupė daug to paties tipo ir įprastų operacijų, o mūsų kūrėjai iš kitų padalinių daugiausia ateina iš vadinamųjų. tipinės užduotys, kurio sprendimas yra visiškai arba iš dalies automatizuotas, nesukelia sunkumų atlikėjams ir nereikalauja didelių darbų kiekių. Kartu su pirmaujančiomis sritimis išanalizavome tokias užduotis ir galėjome nustatyti atskiras darbų kategorijas arba gamybos etapai, etapai buvo suskirstyti į nedalomas žingsnius, o keli etapai susideda gamybos proceso grandinė.
Paprasčiausias technologinės grandinės pavyzdys yra kiekvieno mūsų gaminio surinkimo, diegimo ir testavimo etapai įmonėje. Savo ruožtu, pavyzdžiui, kūrimo etapą sudaro daug atskirų tipiškų žingsnių: šaltinių atsisiuntimas iš „GitLab“, priklausomybių ir trečiųjų šalių bibliotekų paruošimas, vienetų testavimas ir statinio kodo analizė, kūrimo scenarijaus vykdymas „GitLab CI“, artefaktų paskelbimas saugykloje Išleidimo pastabų kūrimas ir generavimas naudojant mūsų vidinį „ChangelogBuilder“ įrankį.
Apie įprastas DevOps užduotis galite perskaityti kituose mūsų straipsniuose apie Habré: ""Ir"".
Susidaro daug tipiškų gamybos grandinių gamybos procesas. Standartinis procesų aprašymo metodas yra naudoti funkcinius IDEF0 modelius.
Gamybos CI proceso modeliavimo pavyzdys
Ypatingą dėmesį skyrėme nuolatinės integracijos sistemos standartinių projektų kūrimui. Tai leido pasiekti projektų suvienodinimą, išryškinant vadinamuosius išleidimo kūrimo schemą su reklamomis.
Štai kaip tai veikia. Visi projektai atrodo tipiški: jie apima rinkinių, patenkančių į momentinių nuotraukų saugyklą „Artifactory“, konfigūraciją, o po to jie diegiami ir išbandomi bandymų stenduose, o tada perkeliami į leidimo saugyklą. „Artifactory“ paslauga yra vienas platinimo taškas, skirtas visiems kūrimo artefaktams tarp komandų ir kitų paslaugų.
Jei labai supaprastinsime ir apibendrinsime savo išleidimo schemą, ji apima šiuos veiksmus:
- kelių platformų gaminio surinkimas,
- dislokuoti bandymų stenduose,
- atlikti funkcinius ir kitus testus,
- reklamuoti išbandytas versijas, kad būtų išleistos „Artifactory“ saugyklos,
- leidimo paskelbimas paremtas atnaujinimo serveriais,
- komplektų ir atnaujinimų pristatymas į gamybą,
- produkto diegimo ir atnaujinimo pradžia.
Pavyzdžiui, apsvarstykite šios tipinės išleidimo schemos technologinį modelį (toliau tiesiog Modelis) funkcinio IDEF0 modelio pavidalu. Tai atspindi pagrindinius mūsų KI proceso etapus. IDEF0 modeliuose naudojamas vadinamasis ICOM žymėjimas (Input-Control-Output-Mechanism), kad apibūdintų, kokie ištekliai naudojami kiekviename etape, remiantis kokiomis taisyklėmis ir reikalavimais atliekamas darbas, kokia yra išvestis ir kokie mechanizmai, paslaugos ar žmonės įgyvendina tam tikrą etapą.
Paspaudus ant paveikslėlio jis bus atidarytas visu dydžiu
Paprastai funkciniuose modeliuose lengviau išskaidyti ir detalizuoti procesų aprašymą. Tačiau elementų skaičiui augant darosi vis sunkiau juose ką nors suprasti. Tačiau realiame kūrime yra ir pagalbiniai etapai: stebėjimas, produktų sertifikavimas, darbo eigos automatizavimas ir kt. Būtent dėl mastelio problemos mes atsisakėme šio aprašymo.
Vilties gimimas
Vienoje knygoje aptikome senus sovietinius žemėlapius, kuriuose aprašomi technologiniai procesai (kurie, beje, ir šiandien naudojami daugelyje valstybinių įmonių ir universitetų). Palaukite, palaukite, nes mes taip pat turime darbo eigą!.. Yra etapai, rezultatai, metrika, reikalavimai, rodikliai ir t. Apėmė jausmas: „Štai! Mes radome tinkamą siūlą, laikas jį gerai ištraukti!
Paprastoje lentelėje nusprendėme produktus įrašyti pagal stulpelius, o technologinius etapus ir gaminių gamybos etapus – eilutes. Gairės yra kažkas didelio, pavyzdžiui, produkto kūrimo žingsnis. Veiksmai yra mažesni ir išsamesni, pvz., šaltinio kodo atsisiuntimas į kūrimo serverį arba kodo sudarymo veiksmas.
Žemėlapio eilučių ir stulpelių sankirtose užrašome konkretaus etapo ir produkto būsenas. Būsenoms buvo apibrėžtas būsenų rinkinys:
- Nėra informacijos – arba netinkamas. Būtina išanalizuoti produkto etapo paklausą. Arba analizė jau atlikta, bet šiuo metu etapas nereikalingas arba nėra ekonomiškai pagrįstas.
- Atidėtas – arba šiuo metu neaktualu. Reikalingas etapas, tačiau šiemet nėra jėgų įgyvendinti.
- Suplanuota. Etapas planuojamas įgyvendinti šiais metais.
- Įgyvendinta. Etapas dujotiekyje įgyvendinamas reikiamu tūriu.
Lentelės pildymas pradėtas pagal projektą. Pirmiausia buvo suskirstyti vieno projekto etapai ir žingsniai bei užfiksuoti jų statusai. Tada jie ėmėsi kito projekto, sutvarkė jame būsenas ir pridėjo etapus bei žingsnius, kurių trūko ankstesniuose projektuose. Dėl to gavome viso savo gamybos vamzdyno etapus ir žingsnius bei jų būsenas konkrečiame projekte. Paaiškėjo kažkas panašaus į produkto vamzdyno kompetencijų matricą. Tokią matricą pavadinome technologiniu žemėlapiu.
Technologinio žemėlapio pagalba metrologiškai pagrįstai deriname su komandomis metų darbų planus ir tikslus, kuriuos norime kartu pasiekti: kuriuos etapus papildome šiais metais, o kuriuos paliekame vėlesniam laikui. Taip pat darbo eigoje galime turėti patobulinimų etapuose, kuriuos atlikome tik vienam produktui. Tada išplečiame žemėlapį ir pristatome šį patobulinimą kaip etapą arba naują žingsnį, tada analizuojame kiekvieną produktą ir išsiaiškiname patobulinimo atkartojimo galimybes.
Jie gali mums prieštarauti: „Žinoma, viskas gerai, tik su laiku žingsnių ir etapų skaičius taps pernelyg didelis. Kaip būti?
Įvedėme standartinius ir gana išsamius kiekvieno etapo ir žingsnio reikalavimų aprašymus, kad visi įmonėje juos suprastų vienodai. Laikui bėgant, įvedant patobulinimus, žingsnis gali būti įtrauktas į kitą etapą ar žingsnį, o tada jie „sugrius“. Tuo pačiu visi reikalavimai ir technologiniai niuansai telpa į apibendrinimo etapo ar žingsnio reikalavimus.
Kaip įvertinti atkartojamų sprendimų poveikį? Naudojame itin paprastą metodą: pradines kapitalo sąnaudas naujo etapo įgyvendinimui priskiriame prie metinių bendrųjų produkto sąnaudų, o tada padalijame iš visų replikuodami.
Kai kurios plėtros dalys žemėlapyje jau rodomos kaip etapai ir žingsniai. Įdiegę tipinių etapų automatizavimą galime daryti įtaką gaminio savikainos mažinimui. Po to atsižvelgiame į kokybinių charakteristikų, kiekybinių metrikų ir komandų gaunamo pelno pokyčius (žmogiškomis ar mašininėmis taupymo valandomis).
Technologinis gamybos proceso žemėlapis
Jei imsimės visų savo etapų ir žingsnių, užkoduosime juos žymomis ir išplėsime į vieną grandinę, tada tai pasirodys labai ilga ir nesuprantama (tik pati „python uodega“, apie kurią kalbėjome straipsnio pradžioje) :
[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]Tai yra produktų [Build] kūrimo, jų diegimo bandomuosiuose serveriuose [Deploy], testavimo [Test], versijų, skirtų saugyklų leidimo, remiantis testavimo rezultatais [Promote], reklamavimo, licencijų [Licencija] generavimo ir paskelbimo, publikavimo [ Paskelbimas] GUS naujinimo serveryje ir pristatymas į FLUS naujinimo serverius, produkto komponentų diegimas ir atnaujinimas kliento infrastruktūroje naudojant Produkto konfigūracijos valdymą [Įdiegti], taip pat telemetrijos [Telemetrija] rinkimas iš įdiegtų produktų.
Be jų, galima išskirti atskirus etapus: infrastruktūros būklės stebėjimas [InfMonitoring], šaltinio kodo versijų kūrimas [SourceCodeControl], kūrimo aplinkos paruošimas [Prepare], projektų valdymas [Workflow], komandų aprūpinimas komunikacijos priemonėmis [Communication], produktų sertifikavimas [ Sertifikavimas] ir CI procesų savarankiškumo užtikrinimas [CISelfSuffficiency] (pavyzdžiui, mazgų nepriklausomumas nuo interneto). Dešimtys žingsnių mūsų procesuose net nebus svarstomi, nes jie labai specifiniai.
Bus daug lengviau suprasti ir pažvelgti į visą gamybos procesą, jei jis bus pateiktas formoje technologinis žemėlapis; tai lentelė, kurioje eilutėmis rašomi atskiri modelio gamybos etapai ir išskaidyti žingsniai, o stulpeliuose aprašoma, kas daroma kiekviename etape ar žingsnyje. Pagrindinis dėmesys skiriamas kiekvienam etapui suteikiantiems resursams ir atsakomybės sričių atskyrimui.
Žemėlapis mums yra savotiškas klasifikatorius. Tai atspindi dideles technologines produktų gamybos dalis. Jos dėka mūsų automatikos komandai tapo lengviau bendrauti su kūrėjais ir kartu planuoti automatizavimo etapų įgyvendinimą, taip pat suprasti, kokių darbo sąnaudų ir išteklių (žmogaus ir techninės įrangos) tam reikės.
Mūsų įmonėje žemėlapis automatiškai generuojamas iš Jinja šablono kaip įprastas HTML failas ir įkeliamas į GitLab puslapių serverį. Galima peržiūrėti ekrano kopiją su visiškai sugeneruoto žemėlapio pavyzdžiu .
Paspaudus ant paveikslėlio jis bus atidarytas visu dydžiu
Trumpai tariant, technologinis žemėlapis yra apibendrintas gamybos proceso vaizdas, kuriame atsispindi aiškiai suskirstyti blokai su tipiškomis funkcijomis.
Mūsų kelių žemėlapio struktūra
Žemėlapį sudaro kelios dalys:
- Pavadinimo sritis – čia pateikiamas bendras žemėlapio aprašymas, supažindinama su pagrindinėmis sąvokomis, apibrėžiami pagrindiniai gamybos proceso ištekliai ir rezultatai.
- Dashboard – čia galite valdyti atskirų produktų duomenų rodymą, pateikiama visų produktų įgyvendintų etapų ir žingsnių suvestinė.
- Technologinis žemėlapis – technologinio proceso lentelės aprašymas. Žemėlapyje:
- pateikti visi etapai, žingsniai ir jų kodai;
- pateikiami trumpi ir išsamūs etapų aprašymai;
- nurodomi kiekviename etape naudojami įvesties ištekliai ir paslaugos;
- nurodomi kiekvieno etapo ir atskiro žingsnio rezultatai;
- nurodoma kiekvieno etapo ir žingsnio atsakomybės sritis;
- nustatyti techniniai ištekliai, tokie kaip HDD (SSD), RAM, vCPU ir darbo valandos, reikalingos darbui šiame etape, tiek šiuo metu - faktas, tiek ateityje - planas;
- prie kiekvieno gaminio nurodoma, kurie technologiniai etapai ar žingsniai jai buvo įgyvendinti, planuojami įgyvendinti, neaktualu ar neįgyvendinti.
Sprendimų priėmimas remiantis technologiniu žemėlapiu
Išstudijavus žemėlapį, galima imtis tam tikrų veiksmų – priklausomai nuo darbuotojo vaidmens įmonėje (plėtros vadovas, produkto vadovas, kūrėjas ar testuotojas):
- suprasti, kokių etapų trūksta realiame gaminyje ar projekte, ir įvertinti jų įgyvendinimo poreikį;
- atskirti atsakomybės sritis tarp kelių skyrių, jei jie dirba skirtinguose etapuose;
- susitarti dėl sutarčių prie estradų įėjimų ir išvažiavimų;
- integruoti savo darbo etapą į bendrą kūrimo procesą;
- tiksliau įvertinti išteklių, suteikiančių kiekvieną iš etapų, poreikį.
Apibendrinant visa tai, kas išdėstyta pirmiau
Maršrutas yra universalus, išplečiamas ir lengvai prižiūrimas. Kur kas lengviau sukurti ir palaikyti procesų aprašymą tokia forma nei griežtame akademiniame IDEF0 modelyje. Be to, lentelės aprašas yra paprastesnis, labiau pažįstamas ir geriau struktūrizuotas nei funkcinis modelis.
Techniniam žingsnių įgyvendinimui turime specialų vidinį įrankį CrossBuilder – sluoksnio įrankį tarp CI sistemų, paslaugų ir infrastruktūros. Kūrėjui nereikia apkarpyti savo dviračio: mūsų CI sistemoje pakanka paleisti vieną iš CrossBuilder įrankio scenarijų (vadinamąją užduotį), kuris tinkamai jį atliks, atsižvelgiant į mūsų infrastruktūros ypatybes. .
rezultatai
Straipsnis pasirodė gana ilgas, tačiau tai neišvengiama aprašant sudėtingų procesų modeliavimą. Pabaigoje norėčiau trumpai pataisyti pagrindines mūsų idėjas:
- DevOps idėjų įgyvendinimo mūsų įmonėje tikslas – nuosekliai mažinti įmonės produktų gamybos ir priežiūros kaštus kiekybine prasme (žmogaus darbo valandos arba mašinų valandos, vCPU, RAM, Disk).
- Būdas sumažinti bendrąsias kūrimo išlaidas yra sumažinti tipinių serijinių užduočių atlikimo išlaidas: technologinio proceso etapus ir etapus.
- Tipinė užduotis – tai užduotis, kurios sprendimas yra visiškai arba iš dalies automatizuotas, nesukelia sunkumų vykdytojams ir nereikalauja didelių darbo sąnaudų.
- Gamybos procesas susideda iš etapų, etapai skirstomi į nedalomas etapus, kurios yra tipinės skirtingo masto ir apimties užduotys.
- Nuo skirtingų tipinių užduočių priėjome prie sudėtingų technologinių grandinių ir kelių lygių gamybos proceso modelių, kuriuos galima apibūdinti funkciniu IDEF0 modeliu arba paprastesniu technologiniu žemėlapiu.
- Technologinis žemėlapis yra gamybos proceso etapų ir etapų lentelė. Svarbiausias dalykas: žemėlapis leidžia matyti visą procesą ištisai, dideliais gabalais su galimybe juos detalizuoti.
- Remiantis technologiniu žemėlapiu, galima įvertinti poreikį įvesti etapus konkrečiame gaminyje, nubrėžti atsakomybės sritis, susitarti dėl sutarčių etapų įvesties ir išvesties vietose, tiksliau įvertinti išteklių poreikį.
Tolesniuose straipsniuose plačiau apibūdinsime, kokios techninės priemonės naudojamos tam tikriems technologiniams etapams mūsų žemėlapyje įgyvendinti.
Straipsnio autoriai:
- — „Positive Technologies“ automatizavimo (DevOps) vadovas
- – pavaduotojas „Positive Technologies“ automatizavimo skyriaus (DevOps) vadovas
Šaltinis: www.habr.com