obrázok:
Ahojte všetci! Sme automatizační inžinieri zo spoločnosti a podporujeme vývoj produktov spoločnosti: podporujeme celý montážny postup od odovzdania riadku kódu vývojármi až po zverejnenie hotových produktov a licencií na aktualizačných serveroch. Neformálne sa nazývame inžinieri DevOps. V tomto článku chceme hovoriť o technologických fázach procesu výroby softvéru, ako ich vidíme a ako ich klasifikujeme.
Z materiálu sa dozviete o zložitosti koordinácie vývoja viacerých produktov, o tom, čo je technologická mapa a ako pomáha zefektívniť a replikovať riešenia, aké sú hlavné etapy a kroky procesu vývoja, aké sú oblasti zodpovednosti medzi DevOps a tímami v našej spoločnosti.
O chaose a DevOps
Stručne povedané, koncept DevOps zahŕňa vývojové nástroje a služby, ako aj metodológie a osvedčené postupy na ich použitie. Vyzdvihnime globálne účel z implementácie nápadov DevOps v našej spoločnosti: ide o dôsledné znižovanie nákladov na výrobu a údržbu produktov v kvantitatívnom vyjadrení (osobohodiny alebo strojové hodiny, CPU, RAM, Disk atď.). Najjednoduchší a najzrejmejší spôsob, ako znížiť celkové náklady na vývoj na úrovni celej spoločnosti, je minimalizácia nákladov na vykonávanie typických sériových úloh vo všetkých fázach výroby. Ale aké sú tieto fázy, ako ich oddeliť od všeobecného procesu, z akých krokov pozostávajú?
Keď spoločnosť vyvíja jeden produkt, všetko je viac-menej jasné: zvyčajne existuje spoločný plán a schéma vývoja. Čo však robiť, keď sa produktový rad rozširuje a produktov je viac? Na prvý pohľad majú podobné procesy a montážne linky a začína sa hra „nájdi X rozdielov“ v protokoloch a skriptoch. Čo ak však už existuje 5+ projektov v aktívnom vývoji a je potrebná podpora pre niekoľko verzií vyvíjaných počas niekoľkých rokov? Chceme znovu použiť maximálny možný počet riešení v produktovom reťazci alebo sme pripravení minúť peniaze na jedinečný vývoj pre každé z nich?
Ako nájsť rovnováhu medzi jedinečnosťou a sériovými riešeniami?
Tieto otázky sa pred nami začali vynárať od roku 2015 čoraz častejšie. Počet produktov rástol a naše oddelenie automatizácie (DevOps), ktoré podporovalo montážne linky týchto produktov, sme sa snažili rozšíriť na minimum. Zároveň sme chceli replikovať čo najviac riešení medzi produkty. Napokon, prečo robiť to isté v desiatich produktoch rôznymi spôsobmi?
riaditeľ rozvoja: "Chlapi, môžeme nejako zhodnotiť, čo robí DevOps pre produkty?"
My: "Nevieme, takúto otázku sme nepoložili, ale aké ukazovatele by sa mali zvážiť?"
riaditeľ rozvoja: "Kto vie! Myslieť si…"
Ako v tom slávnom filme: "Som v hoteli! .." - "Uh... Môžete mi ukázať cestu?" Po zvážení sme dospeli k záveru, že najprv musíme rozhodnúť o konečnom stave produktov; toto sa stalo naším prvým cieľom.
Ako teda analyzovať tucet produktov s pomerne veľkými tímami od 10 do 200 ľudí a určiť merateľné metriky pri replikácii riešení?
1:0 v prospech Chaosu, alebo DevOps na lopatky
Začali sme pokusom o aplikáciu diagramov IDEF0 a rôznych diagramov obchodných procesov zo série BPwin. Zmätok začal po piatom štvorci ďalšej fázy ďalšieho projektu a tieto štvorce pre každý projekt je možné nakresliť v chvoste dlhého pytóna pod 50+ krokov. Cítil som sa smutný a chcel som zavýjať na mesiac - vo všeobecnosti sa to nehodilo.
Typické výrobné úlohy
Modelovanie výrobných procesov je veľmi zložitá a starostlivá práca: potrebujete zhromaždiť, spracovať a analyzovať množstvo údajov z rôznych oddelení a výrobných reťazcov. Viac o tom si môžete prečítať v článku "".
Keď sme začali modelovať náš výrobný proces, mali sme konkrétny cieľ – sprostredkovať každému zamestnancovi, ktorý sa podieľa na vývoji produktov našej spoločnosti, a projektovým manažérom:
- ako sa produkty a ich komponenty, počnúc odovzdaním riadku kódu, dostanú k zákazníkovi vo forme inštalátorov a aktualizácií,
- aké zdroje sa poskytujú pre každú fázu výroby produktov,
- aké služby sú zahrnuté v každej fáze,
- ako sú vymedzené oblasti zodpovednosti pre každú fázu,
- aké zmluvy existujú na vstupe a výstupe každej etapy.
Kliknutím na obrázok sa otvorí v plnej veľkosti.
Naša práca v spoločnosti je rozdelená do niekoľkých funkčných oblastí. Smerovanie infraštruktúry sa zaoberá optimalizáciou prevádzky všetkých „železných“ zdrojov oddelenia, ako aj automatizáciou nasadzovania virtuálnych strojov a prostredia na nich. Smer monitorovania poskytuje 24/7 kontrolu výkonu služby; Monitoring poskytujeme aj ako službu pre vývojárov. Smerovanie pracovného toku poskytuje tímom nástroje na riadenie procesov vývoja a testovania, analýzu stavu kódu a analýzu projektov. A nakoniec, smer webdev zabezpečuje zverejňovanie verzií na aktualizačných serveroch GUS a FLUS, ako aj licencovanie produktov pomocou služby LicenseLab. Na podporu produkčného kanála zriaďujeme a udržiavame mnoho rôznych podporných služieb pre vývojárov (príbehy o niektorých z nich si môžete vypočuť na starých stretnutiach: и). Vyvíjame tiež interné automatizačné nástroje, vrátane .
Za posledných päť rokov sa v našej práci nahromadilo množstvo operácií rovnakého typu a rutinných operácií a naši vývojári z iných oddelení pochádzajú najmä z tzv. typické úlohy, ktorého riešenie je plne alebo čiastočne automatizované, nespôsobuje interpretom ťažkosti a nevyžaduje značné množstvo práce. Spolu s vedúcimi oblasťami sme takéto úlohy analyzovali a dokázali identifikovať jednotlivé kategórie prác, príp výrobné kroky, etapy boli rozdelené do nedeliteľných krokov a niekoľko etáp sa sčítava reťazec výrobného procesu.
Najjednoduchším príkladom technologického reťazca sú fázy montáže, nasadenia a testovania každého z našich produktov v rámci spoločnosti. Na druhej strane napríklad fáza zostavovania pozostáva z mnohých samostatných typických krokov: sťahovanie zdrojov z GitLab, príprava závislostí a knižníc tretích strán, testovanie jednotiek a analýza statického kódu, spustenie zostavovacieho skriptu na GitLab CI, publikovanie artefaktov v úložisku na Umelá tvorba a generovanie poznámok k vydaniu prostredníctvom nášho interného nástroja ChangelogBuilder.
O typických úlohách DevOps si môžete prečítať v našich ďalších článkoch na Habré: ""A"".
Vzniká mnoho typických výrobných reťazcov výrobný proces. Štandardným prístupom k popisu procesov je použitie funkčných modelov IDEF0.
Príklad modelovania výrobného CI procesu
Osobitnú pozornosť sme venovali vývoju štandardných projektov pre systém kontinuálnej integrácie. To umožnilo dosiahnuť zjednotenie projektov, zvýraznenie tzv uvoľniť zostavovaciu schému s propagačnými akciami.
Tu je návod, ako to funguje. Všetky projekty vyzerajú typicky: zahŕňajú konfiguráciu zostáv, ktoré spadajú do úložiska snímok v Artifactory, potom sú nasadené a testované na testovacích stoloch a potom povýšené do úložiska verzií. Služba Artifactory je jednotný distribučný bod pre všetky artefakty zostavy medzi tímami a inými službami.
Ak výrazne zjednodušíme a zovšeobecníme našu schému vydania, potom zahŕňa nasledujúce kroky:
- multiplatformová montáž produktov,
- nasadenie na testovacie lavice,
- vykonávanie funkčných a iných testov,
- podpora testovaných verzií na uvoľnenie repozitárov v Artifactory,
- zverejnenie verzií vydaní na aktualizačných serveroch,
- dodávka zostáv a aktualizácií do výroby,
- spustenie inštalácie a aktualizácie produktu.
Uvažujme napríklad technologický model tejto typickej schémy vydania (ďalej len model) vo forme funkčného modelu IDEF0. Odráža hlavné fázy nášho procesu CI. Modely IDEF0 využívajú tzv ICOM notácia (Input-Control-Output-Mechanism) na popis toho, aké zdroje sa používajú v každej fáze, na základe akých pravidiel a požiadaviek sa práca vykonáva, aký je výstup a aké mechanizmy, služby alebo ľudia implementujú konkrétnu fázu.
Kliknutím na obrázok sa otvorí v plnej veľkosti.
Spravidla je jednoduchšie dekomponovať a detailne rozložiť popis procesov vo funkčných modeloch. Ale ako počet prvkov rastie, je čoraz ťažšie niečo v nich pochopiť. Ale v skutočnom vývoji existujú aj pomocné stupne: monitorovanie, certifikácia produktov, automatizácia pracovných procesov a iné. Tento popis sme opustili kvôli problémom s mierkou.
Zrodenie nádeje
V jednej knihe sme narazili na staré sovietske mapy popisujúce technologické postupy (ktoré sa mimochodom dodnes používajú na mnohých štátnych podnikoch a univerzitách). Počkajte, počkajte, pretože aj my máme pracovný postup!.. Existujú fázy, výsledky, metriky, požiadavky, ukazovatele atď. Bol tu pocit: „To je ono! Našli sme tú správnu niť, je čas ju poriadne potiahnuť!
V jednoduchej tabuľke sme sa rozhodli zaznamenávať produkty po stĺpcoch a technologické etapy a kroky produktovodu po riadkoch. Míľniky sú niečo veľké, ako napríklad krok pri vytváraní produktu. A kroky sú niečo menšie a podrobnejšie, ako napríklad krok stiahnutia zdrojového kódu na zostavovací server alebo krok kompilácie kódu.
Na priesečníky riadkov a stĺpcov mapy uvádzame stavy pre konkrétnu etapu a produkt. Pre stavy bola definovaná množina stavov:
- Žiadne informácie - alebo nevhodné. Je potrebné analyzovať dopyt po štádiu produktu. Buď analýza už bola vykonaná, ale etapa v súčasnosti nie je potrebná alebo nie je ekonomicky opodstatnená.
- Odložené - alebo momentálne nie sú relevantné. Je potrebná etapa prípravy, ale tento rok nie sú sily na realizáciu.
- Plánované. Etapa je naplánovaná na realizáciu v tomto roku.
- Implementovaná. Stupeň v potrubí je realizovaný v požadovanom objeme.
Vypĺňanie tabuľky začalo projekt po projekte. Najprv sa klasifikovali fázy a kroky jedného projektu a zaznamenávali sa ich stavy. Potom vzali ďalší projekt, opravili v ňom stavy a pridali fázy a kroky, ktoré v predchádzajúcich projektoch chýbali. Výsledkom je, že sme získali etapy a kroky celého nášho výrobného potrubia a ich stavy v konkrétnom projekte. Ukázalo sa niečo podobné ako matica kompetencií produktovodu. Takúto maticu sme nazvali technologická mapa.
Pomocou technologickej mapy metrologicky rozumne koordinujeme s tímami plány práce na rok a ciele, ktoré chceme spoločne dosiahnuť: ktoré etapy do projektu pridávame tento rok a ktoré necháme na neskôr. V priebehu práce môžeme mať tiež zlepšenia v etapách, ktoré sme dokončili iba pre jeden produkt. Potom rozšírime našu mapu a predstavíme toto zlepšenie ako etapu alebo nový krok, potom pre každý produkt analyzujeme a zistíme realizovateľnosť replikácie zlepšenia.
Môžu nám namietať: „To všetko je, samozrejme, dobré, len časom bude počet krokov a etáp neúmerne veľký. Ako byť?
Zaviedli sme štandardné a pomerne úplné popisy požiadaviek pre každú fázu a krok, aby ich každý v rámci spoločnosti chápal rovnako. Postupom času, ako sa zavádzajú vylepšenia, môže byť krok absorbovaný do inej fázy alebo kroku a potom sa „zrútia“. Všetky požiadavky a technologické nuansy zároveň zapadajú do požiadaviek zovšeobecňujúceho štádia alebo kroku.
Ako vyhodnotiť efekt replikujúcich sa riešení? Používame mimoriadne jednoduchý prístup: počiatočné kapitálové náklady na implementáciu novej etapy pripisujeme ročným všeobecným nákladom na produkt a potom ich pri replikácii vydelíme všetkými.
Časti vývoja sú už zobrazené ako míľniky a kroky na mape. Zníženie ceny produktu môžeme ovplyvniť zavedením automatizácie pre typické etapy. Potom zvážime zmeny v kvalitatívnych charakteristikách, kvantitatívnych metrikách a zisku, ktorý tímy získajú (v človekohodinách alebo strojohodinách úspor).
Technologická mapa výrobného procesu
Ak urobíme všetky naše fázy a kroky, zakódujeme ich značkami a rozšírime ich do jedného reťazca, potom sa ukáže, že je to veľmi dlhé a nepochopiteľné (rovnaký „pytónový chvost“, o ktorom sme hovorili na začiatku článku) :
[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]Toto sú fázy budovania produktov [Build], ich nasadenia na testovacie servery [Deploy], testovania [Test], podpory zostáv na uvoľnenie repozitárov na základe výsledkov testovania [Promote], generovania a publikovania licencií [License], publikovania [ Publikovanie] na aktualizačnom serveri GUS a doručenie na aktualizačné servery FLUS, inštalácia a aktualizácia komponentov produktu v infraštruktúre zákazníka pomocou správy konfigurácie produktu [Inštalovať], ako aj zhromažďovanie telemetrie [Telemetry] z nainštalovaných produktov.
Okrem nich možno rozlíšiť samostatné etapy: monitorovanie stavu infraštruktúry [InfMonitoring], verzovanie zdrojového kódu [SourceCodeControl], príprava prostredia zostavy [Príprava], riadenie projektu [Workflow], poskytovanie komunikačných nástrojov tímom [Komunikácia], certifikácia produktov [ Certifikácia] a zabezpečenie sebestačnosti procesov CI [CISelfSufficiency] (napríklad nezávislosť zostáv od internetu). Desiatky krokov v našich procesoch ani nebudeme brať do úvahy, pretože sú veľmi špecifické.
Bude oveľa jednoduchšie pochopiť a pozrieť sa na celý výrobný proces, ak je prezentovaný vo forme technologická mapa; toto je tabuľka, v ktorej sú v riadkoch zapísané jednotlivé výrobné etapy a rozložené kroky Modelu a v stĺpcoch popis toho, čo sa robí v jednotlivých etapách alebo krokoch. Hlavný dôraz sa kladie na zdroje, ktoré jednotlivé etapy poskytujú, a na vymedzenie oblastí zodpovednosti.
Mapa je pre nás akýmsi klasifikátorom. Odráža veľké technologické časti výroby produktov. Vďaka tomu bolo pre náš automatizačný tím jednoduchšie komunikovať s vývojármi a spoločne plánovať implementáciu etáp automatizácie, ako aj pochopiť, aké náklady na prácu a zdroje (ľudské a hardvérové) budú na to potrebné.
V našej spoločnosti sa mapa automaticky generuje zo šablóny jinja ako bežný súbor HTML a potom sa nahráva na server GitLab Pages. Môžete si pozrieť snímku obrazovky s príkladom úplne vygenerovanej mapy .
Kliknutím na obrázok sa otvorí v plnej veľkosti.
Stručne povedané, technologická mapa je zovšeobecnený obraz výrobného procesu, ktorý odráža jasne klasifikované bloky s typickou funkčnosťou.
Štruktúra našej cestovnej mapy
Mapa sa skladá z niekoľkých častí:
- Oblasť názvu - tu je všeobecný popis mapy, predstavené základné pojmy, definované hlavné zdroje a výsledky výrobného procesu.
- Dashboard - tu môžete ovládať zobrazovanie údajov pre jednotlivé produkty, poskytuje súhrn realizovaných etáp a krokov všeobecne pre všetky produkty.
- Technologická mapa – tabuľkový popis technologického postupu. Na mape:
- sú uvedené všetky fázy, kroky a ich kódy;
- sú uvedené krátke a úplné opisy etáp;
- sú uvedené vstupné zdroje a služby použité v každej fáze;
- sú uvedené výsledky každej etapy a samostatného kroku;
- je uvedená oblasť zodpovednosti za každú fázu a krok;
- boli určené technické zdroje, ako sú HDD (SSD), RAM, vCPU a človekohodiny potrebné na podporu práce v tejto fáze, a to ako v súčasnosti – skutočnosť, tak aj v budúcnosti – plán;
- pri každom produkte je uvedené, ktoré technologické etapy alebo kroky k nemu boli realizované, plánované na realizáciu, irelevantné alebo nerealizované.
Rozhodovanie na základe technologickej mapy
Po preskúmaní mapy je možné vykonať niektoré úkony – v závislosti od roly zamestnanca v spoločnosti (manažér vývoja, produktový manažér, vývojár alebo tester):
- pochopiť, ktoré fázy v skutočnom produkte alebo projekte chýbajú, a posúdiť potrebu ich implementácie;
- vymedziť oblasti zodpovednosti medzi niekoľko oddelení, ak pracujú na rôznych úrovniach;
- dohodnúť zmluvy na vstupoch a výstupoch z etáp;
- integrovať svoju pracovnú fázu do celkového procesu rozvoja;
- presnejšie posúdiť potrebu zdrojov, ktoré poskytujú každú z etáp.
Zhrnutie všetkého vyššie uvedeného
Smerovanie je všestranné, rozšíriteľné a ľahko sa udržiava. Vypracovať a udržiavať popis procesov v tejto forme je oveľa jednoduchšie ako v striktnom akademickom modeli IDEF0. Okrem toho je tabuľkový popis jednoduchší, známejší a lepšie štruktúrovaný ako funkčný model.
Na technickú implementáciu krokov máme špeciálny interný nástroj CrossBuilder – vrstvový nástroj medzi CI systémami, službami a infraštruktúrou. Vývojár si nemusí strihať bicykel: v našom CI systéme stačí spustiť jeden zo skriptov (tzv. task) nástroja CrossBuilder, ktorý ho správne spustí, berúc do úvahy vlastnosti našej infraštruktúry. .
Výsledky
Článok sa ukázal byť dosť dlhý, ale to je nevyhnutné pri popise modelovania zložitých procesov. Na záver by som chcel stručne opraviť naše hlavné myšlienky:
- Cieľom implementácie nápadov DevOps v našej spoločnosti je dôsledne znižovať náklady na výrobu a údržbu produktov spoločnosti v kvantitatívnom vyjadrení (osobohodiny alebo strojové hodiny, vCPU, RAM, Disk).
- Spôsob, ako znížiť celkové náklady na vývoj, je minimalizovať náklady na vykonávanie typických sériových úloh: etáp a krokov technologického procesu.
- Typickou úlohou je úloha, ktorej riešenie je plne alebo čiastočne automatizované, nespôsobuje interpretom ťažkosti a nevyžaduje značné mzdové náklady.
- Výrobný proces pozostáva z etáp, etapy sú rozdelené do nedeliteľných krokov, čo sú typické úlohy rôzneho rozsahu a rozsahu.
- Od nesúrodých typických úloh sme sa dostali ku zložitým technologickým reťazcom a viacúrovňovým modelom výrobného procesu, ktoré je možné popísať funkčným modelom IDEF0 alebo jednoduchšou technologickou mapou.
- Technologická mapa je tabuľkovým znázornením etáp a krokov výrobného procesu. Najdôležitejšia vec: mapa vám umožňuje vidieť celý proces v celku, vo veľkých častiach s možnosťou ich detailovania.
- Na základe technologickej mapy je možné posúdiť potrebu zavedenia etáp v konkrétnom produkte, vymedziť oblasti zodpovednosti, dohodnúť zmluvy na vstupoch a výstupoch etáp a presnejšie posúdiť potrebu zdrojov.
V nasledujúcich článkoch si bližšie popíšeme, aké technické nástroje sa používajú na realizáciu určitých technologických etáp na našej mape.
Autori článku:
- — Vedúci oddelenia automatizácie (DevOps) v spoločnosti Positive Technologies
- - Zástupca Vedúci oddelenia automatizácie (DevOps) v spoločnosti Positive Technologies
Zdroj: hab.com