Obrázek:
Ahoj všichni! Jsme automatizační inženýři z firmy a podporujeme vývoj produktů společnosti: podporujeme celý proces montáže od odevzdání řádku kódu vývojáři až po zveřejnění hotových produktů a licencí na aktualizačních serverech. Neformálně se nazýváme DevOps inženýři. V tomto článku chceme hovořit o technologických fázích procesu výroby softwaru, jak je vidíme a jak je klasifikujeme.
Z materiálu se dozvíte o složitosti koordinace víceproduktového vývoje, o tom, co je technologická mapa a jak pomáhá zefektivnit a replikovat řešení, jaké jsou hlavní fáze a kroky procesu vývoje, jak jsou oblasti odpovědnosti mezi DevOps a týmy v naší společnosti.
O chaosu a DevOps
Stručně řečeno, koncept DevOps zahrnuje vývojové nástroje a služby, stejně jako metodiky a nejlepší postupy pro jejich použití. Vyjmenujme globální cíl z implementace nápadů DevOps v naší společnosti: jedná se o důsledné snižování nákladů na výrobu a údržbu produktů v kvantitativním vyjádření (osobohodiny nebo strojní hodiny, CPU, RAM, Disk atd.). Nejjednodušší a nejzřejmější způsob, jak snížit celkové náklady na vývoj na úrovni celé společnosti, je minimalizace nákladů na provádění typických sériových úloh ve všech fázích výroby. Ale jaké jsou tyto fáze, jak je oddělit od obecného procesu, z jakých kroků se skládají?
Když společnost vyvíjí jeden produkt, je vše víceméně jasné: obvykle existuje společný plán a schéma vývoje. Co ale dělat, když se produktová řada rozšiřuje a produktů je více? Na první pohled mají podobné procesy a montážní linky a začíná hra „najít X rozdílů“ v protokolech a skriptech. Ale co když již existuje 5+ projektů v aktivním vývoji a je vyžadována podpora pro několik verzí vyvíjených v průběhu několika let? Chceme znovu využít maximální možný počet řešení v produktových řadách nebo jsme připraveni utratit peníze za jedinečný vývoj pro každé?
Jak najít rovnováhu mezi jedinečností a sériovým řešením?
Tyto otázky se před námi začaly objevovat od roku 2015 stále častěji. Počet produktů rostl a naše oddělení automatizace (DevOps), které podporovalo montážní linky těchto produktů, jsme se snažili rozšířit na minimum. Zároveň jsme chtěli replikovat co nejvíce řešení mezi produkty. Koneckonců, proč dělat totéž v deseti produktech různými způsoby?
Ředitel vývoje: "Kluci, můžeme nějak zhodnotit, co dělá DevOps pro produkty?"
My: "Nevíme, takovou otázku jsme nepoložili, ale jaké ukazatele je třeba vzít v úvahu?"
Ředitel vývoje: "Kdo ví! Myslet si…"
Jako v tom slavném filmu: "Jsem v hotelu! .." - "Uh... Můžete mi ukázat cestu?" Po zamyšlení jsme došli k závěru, že nejprve musíme rozhodnout o konečných stavech produktů; to se stalo naším prvním cílem.
Jak tedy analyzovat tucet produktů s poměrně velkými týmy od 10 do 200 lidí a určit měřitelné metriky při replikaci řešení?
1:0 ve prospěch Chaosu, neboli DevOps na lopatky
Začali jsme pokusem o aplikaci diagramů IDEF0 a různých diagramů obchodních procesů ze série BPwin. Zmatek začal po pátém čtverci další fáze dalšího projektu a tyto čtverce pro každý projekt lze nakreslit v ocasu dlouhé krajty pod 50+ kroků. Bylo mi smutno a chtělo se mi výt na měsíc - obecně se to nehodilo.
Typické výrobní úkoly
Modelování výrobních procesů je velmi složitá a pečlivá práce: potřebujete shromáždit, zpracovat a analyzovat mnoho dat z různých oddělení a výrobních řetězců. Více si o tom můžete přečíst v článku "".
Když jsme začali modelovat náš výrobní proces, měli jsme konkrétní cíl – sdělit každému zaměstnanci, který se podílí na vývoji produktů naší společnosti, a projektovým manažerům:
- jak se produkty a jejich součásti, počínaje odevzdáním řádku kódu, dostanou k zákazníkovi ve formě instalačních programů a aktualizací,
- jaké zdroje jsou poskytovány pro každou fázi výroby produktů,
- jaké služby jsou zahrnuty v každé fázi,
- jak jsou vymezeny oblasti odpovědnosti za každou fázi,
- jaké smlouvy existují na vstupu a výstupu každé fáze.
Kliknutím na obrázek se otevře v plné velikosti.
Naše práce ve společnosti je rozdělena do několika funkčních oblastí. Směrování infrastruktury se zabývá optimalizací provozu všech „železných“ zdrojů oddělení a také automatizací nasazení virtuálních strojů a prostředí na nich. Směr monitorování zajišťuje nepřetržitou kontrolu výkonu služby; poskytujeme také monitoring jako službu pro vývojáře. Směr pracovního toku poskytuje týmům nástroje pro správu vývojových a testovacích procesů, analýzu stavu kódu a získávání analýz projektů. A konečně směr webdev zajišťuje publikování verzí na aktualizačních serverech GUS a FLUS a také licencování produktů pomocí služby LicenseLab. Abychom podpořili produkční kanál, nastavujeme a udržujeme mnoho různých podpůrných služeb pro vývojáře (příběhy o některých z nich si můžete poslechnout na starých setkáních: и). Vyvíjíme také nástroje pro interní automatizaci, včetně .
Za posledních pět let se v naší práci nashromáždilo mnoho stejného typu a rutinních operací a naši vývojáři z jiných oddělení pocházejí převážně z tzv. typické úkoly, jehož řešení je plně nebo částečně automatizované, nezpůsobuje interpretům potíže a nevyžaduje značné množství práce. Společně s vedoucími oblastmi jsme takové úkoly analyzovali a dokázali identifikovat jednotlivé kategorie prací, popř výrobní krokyetapy byly rozděleny do nedělitelných kroků a několik etap se sčítá řetězec výrobního procesu.
Nejjednodušším příkladem technologického řetězce jsou fáze montáže, nasazení a testování každého z našich produktů v rámci společnosti. Na druhé straně se například fáze sestavení skládá z mnoha samostatných typických kroků: stahování zdrojů z GitLab, příprava závislostí a knihoven třetích stran, testování jednotek a analýza statického kódu, spuštění skriptu sestavení na GitLab CI, publikování artefaktů v úložišti na Umělá tvorba a generování poznámek k vydání prostřednictvím našeho interního nástroje ChangelogBuilder.
O typických úlohách DevOps si můžete přečíst v našich dalších článcích o Habré: ""A"".
Vzniká mnoho typických výrobních řetězců výrobní proces. Standardním přístupem k popisu procesů je použití funkčních modelů IDEF0.
Příklad modelování výrobního CI procesu
Zvláštní pozornost jsme věnovali vývoji standardních projektů pro kontinuální integrační systém. To umožnilo dosáhnout sjednocení projektů, zvýraznění tzv uvolnit schéma sestavení s propagačními akcemi.
Zde je návod, jak to funguje. Všechny projekty vypadají typicky: zahrnují konfiguraci sestav, které spadají do úložiště snímků v Artifactory, poté jsou nasazeny a testovány na testovacích stolicích a poté povýšeny do úložiště verzí. Služba Artifactory je jediným distribučním místem pro všechny artefakty sestavení mezi týmy a dalšími službami.
Pokud výrazně zjednodušíme a zobecníme naše schéma vydání, pak zahrnuje následující kroky:
- montáž produktů napříč platformami,
- nasazení do testovacích lavic,
- provádění funkčních a dalších testů,
- propagace testovaných sestavení pro uvolnění repozitářů v Artifactory,
- zveřejnění sestavení vydání na aktualizačních serverech,
- dodání sestav a aktualizací do výroby,
- spuštění instalace a aktualizace produktu.
Vezměme si například technologický model tohoto typického schématu vydání (dále jen Model) ve formě funkčního modelu IDEF0. Odráží hlavní fáze našeho procesu CI. Modely IDEF0 využívají tzv ICOM notace (Input-Control-Output-Mechanism) k popisu toho, jaké zdroje se používají v každé fázi, na základě jakých pravidel a požadavků se práce provádí, jaký je výstup a jaké mechanismy, služby nebo lidé implementují konkrétní fázi.
Kliknutím na obrázek se otevře v plné velikosti.
Zpravidla je snazší rozložit a zpřesnit popis procesů ve funkčních modelech. Ale jak roste počet prvků, je čím dál těžší v nich něco pochopit. Ale v reálném vývoji existují i pomocné fáze: monitoring, certifikace produktů, automatizace pracovních procesů a další. Tento popis jsme opustili kvůli problému s škálováním.
Zrození naděje
V jedné knize jsme narazili na staré sovětské mapy popisující technologické postupy (které se mimochodem dodnes používají na mnoha státních podnicích a univerzitách). Počkejte, počkejte, protože máme také pracovní postup!... Existují fáze, výsledky, metriky, požadavky, ukazatele a tak dále a tak dále... Proč nezkusit aplikovat vývojové diagramy také na naše produkty? Byl tu pocit: „To je ono! Našli jsme správnou nit, je čas ji pořádně zatáhnout!
V jednoduché tabulce jsme se rozhodli zaznamenávat produkty po sloupcích a technologické fáze a kroky produktovodu po řádcích. Milníky jsou něco velkého, jako je krok vytváření produktu. A kroky jsou něco menšího a podrobnějšího, jako je krok stažení zdrojového kódu na server sestavení nebo krok kompilace kódu.
Na průsečíky řádků a sloupců mapy zapisujeme stavy pro konkrétní fázi a produkt. Pro stavy byla definována sada stavů:
- Нет данных - nebo nevhodné. Je nutné analyzovat poptávku po fázi produktu. Buď analýza již byla provedena, ale etapa v současné době není potřeba nebo není ekonomicky opodstatněná.
- Odloženo - nebo v tuto chvíli není relevantní. Je zapotřebí etapa v procesu, ale letos nejsou síly na realizaci.
- Plánováno. Etapa je plánována k realizaci v letošním roce.
- Realizováno. Stupeň v potrubí je realizován v požadovaném objemu.
Vyplňování tabulky začalo projekt po projektu. Nejprve byly klasifikovány fáze a kroky jednoho projektu a zaznamenány jejich stavy. Poté vzali další projekt, opravili v něm stavy a přidali fáze a kroky, které v předchozích projektech chyběly. Díky tomu jsme získali fáze a kroky celého našeho výrobního potrubí a jejich stavy v konkrétním projektu. Ukázalo se něco podobného jako matice kompetencí produktového potrubí. Takovou matici jsme nazvali technologická mapa.
Pomocí technologické mapy metrologicky rozumně koordinujeme s týmy plány práce na rok a cíle, kterých chceme společně dosáhnout: které etapy letos do projektu přidáme a které necháme na později. V průběhu práce také můžeme mít vylepšení ve fázích, které jsme dokončili pouze u jednoho produktu. Poté rozšíříme naši mapu a představíme toto vylepšení jako fázi nebo nový krok, poté pro každý produkt analyzujeme a zjišťujeme proveditelnost replikace vylepšení.
Mohou nám namítnout: „To je všechno samozřejmě dobré, jen časem se počet kroků a stupňů neúměrně zvětší. Jak být?
Zavedli jsme standardní a poměrně úplné popisy požadavků pro každou fázi a krok, aby je všichni v rámci společnosti chápali stejně. Postupem času, jak jsou zaváděna vylepšení, může být krok absorbován do jiné fáze nebo kroku, a pak se „zhroutí“. Všechny požadavky a technologické nuance přitom zapadají do požadavků zobecňující fáze či kroku.
Jak vyhodnotit efekt replikačních řešení? Používáme extrémně jednoduchý přístup: počáteční kapitálové náklady na implementaci nové etapy přiřadíme k ročním obecným nákladům na produkt a při replikaci je pak vydělíme všemi.
Části vývoje jsou již na mapě zobrazeny jako milníky a kroky. Snížení ceny produktu můžeme ovlivnit zavedením automatizace pro typické etapy. Poté zvážíme změny v kvalitativních charakteristikách, kvantitativních metrikách a zisku, který týmy dosáhnou (v člověkohodinách nebo strojohodinách úspor).
Technologická mapa výrobního procesu
Pokud provedeme všechny naše fáze a kroky, zakódujeme je pomocí značek a rozšíříme je do jednoho řetězce, ukáže se to jako velmi dlouhé a nesrozumitelné (jen ten „python tail“, o kterém jsme mluvili na začátku č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]Jedná se o fáze vytváření produktů [Build], jejich nasazení na testovací servery [Deploy], testování [Test], podpora sestavení pro vydání repozitářů na základě výsledků testování [Promote], generování a publikování licencí [Licence], publikování [ Publikování] na aktualizačním serveru GUS a doručení na aktualizační servery FLUS, instalace a aktualizace komponent produktu v infrastruktuře zákazníka pomocí Product Configuration Management [Install] a také shromažďování telemetrie [Telemetry] z nainstalovaných produktů.
Kromě nich lze rozlišit samostatné fáze: monitorování stavu infrastruktury [InfMonitoring], verzování zdrojového kódu [SourceCodeControl], příprava prostředí sestavení [Připravit], řízení projektu [Workflow], poskytování komunikačních nástrojů týmům [Communication], certifikace produktu [ Certifikace] a zajištění soběstačnosti procesů CI [CISelfSufficiency] (například nezávislost sestav na internetu). O desítkách kroků v našich procesech ani neuvažujeme, protože jsou velmi specifické.
Bude mnohem snazší pochopit a podívat se na celý proces výroby, pokud je prezentován ve formě technologická mapa; jedná se o tabulku, ve které jsou v řádcích zapsány jednotlivé fáze výroby a rozložené kroky Modelu a ve sloupcích popis toho, co se v každé fázi nebo kroku dělá. Hlavní důraz je kladen na zdroje, které jednotlivé etapy poskytují, a vymezení oblastí odpovědnosti.
Mapa je pro nás jakýmsi klasifikátorem. Odráží hlavní technologické části výroby produktů. Díky tomu bylo pro náš automatizační tým snazší komunikovat s vývojáři a společně plánovat implementaci automatizačních fází a také pochopit, jaké náklady na pracovní sílu a zdroje (lidské a hardwarové) k tomu budou zapotřebí.
Uvnitř naší společnosti se mapa automaticky generuje ze šablony jinja jako běžný soubor HTML a poté se nahraje na server GitLab Pages. Můžete si prohlédnout snímek obrazovky s příkladem plně vygenerované mapy .
Kliknutím na obrázek se otevře v plné velikosti.
Stručně řečeno, technologická mapa je zobecněným obrazem výrobního procesu, který odráží jasně klasifikované bloky s typickou funkčností.
Struktura naší cestovní mapy
Mapa se skládá z několika částí:
- Oblast názvu - zde je obecný popis mapy, jsou představeny základní pojmy, definovány hlavní zdroje a výsledky výrobního procesu.
- Dashboard - zde můžete ovládat zobrazení dat pro jednotlivé produkty, je uveden souhrn realizovaných fází a kroků obecně pro všechny produkty.
- Technologická mapa - tabulkový popis technologického postupu. Na mapě:
- jsou uvedeny všechny fáze, kroky a jejich kódy;
- jsou uvedeny krátké a úplné popisy fází;
- jsou uvedeny vstupní zdroje a služby používané v každé fázi;
- jsou uvedeny výsledky každé fáze a samostatného kroku;
- je uvedena oblast odpovědnosti za každou fázi a krok;
- byly stanoveny technické zdroje, jako je HDD (SSD), RAM, vCPU a člověkohodiny potřebné k podpoře práce v této fázi, a to jak v současné době – skutečnost, tak v budoucnu – plán;
- u každého produktu je uvedeno, které technologické etapy nebo kroky pro něj byly realizovány, plánované k realizaci, irelevantní nebo nerealizované.
Rozhodování na základě technologické mapy
Po prozkoumání mapy je možné provést některé akce - v závislosti na roli zaměstnance ve firmě (vývojový manažer, produktový manažer, vývojář nebo tester):
- porozumět tomu, jaké fáze ve skutečném produktu nebo projektu chybí, a posoudit potřebu jejich implementace;
- vymezit oblasti odpovědnosti mezi několik oddělení, pokud pracují na různých fázích;
- dohodnout smlouvy na vjezdech a výjezdech z etap;
- integrovat svou pracovní fázi do celkového procesu vývoje;
- přesněji posoudit potřebu zdrojů, které poskytují každou z fází.
Shrnutí všeho výše uvedeného
Směrování je univerzální, rozšiřitelné a snadno se udržuje. Vyvinout a udržovat popis procesů v této podobě je mnohem jednodušší než v přísném akademickém modelu IDEF0. Kromě toho je tabulkový popis jednodušší, známější a lépe strukturovaný než funkční model.
Pro technickou implementaci kroků máme speciální interní nástroj CrossBuilder - vrstvový nástroj mezi CI systémy, službami a infrastrukturou. Vývojář si nemusí sekat kolo: v našem CI systému stačí spustit jeden ze skriptů (tzv. task) nástroje CrossBuilder, který jej správně spustí s přihlédnutím k vlastnostem naší infrastruktury. .
Výsledky
Článek se ukázal být poměrně dlouhý, ale to je nevyhnutelné při popisu modelování složitých procesů. Na závěr bych rád krátce upřesnil naše hlavní myšlenky:
- Cílem implementace nápadů DevOps v naší společnosti je důsledně snižovat náklady na výrobu a údržbu produktů společnosti v kvantitativním vyjádření (osobohodiny nebo strojní hodiny, vCPU, RAM, Disk).
- Cestou ke snížení celkových nákladů na vývoj je minimalizace nákladů na provádění typických sériových úloh: etap a kroků technologického procesu.
- Typickým úkolem je úkol, jehož řešení je plně nebo částečně automatizováno, nezpůsobuje interpretům potíže a nevyžaduje značné mzdové náklady.
- Výrobní proces se skládá z etap, etapy jsou rozděleny do nedělitelných kroků, což jsou typické úkoly různého rozsahu a rozsahu.
- Od nesourodých typických úloh jsme se dostali ke složitým technologickým řetězcům a víceúrovňovým modelům výrobního procesu, které lze popsat funkčním modelem IDEF0 nebo jednodušší technologickou mapou.
- Technologická mapa je tabulkovým znázorněním fází a kroků výrobního procesu. To nejdůležitější: mapa umožňuje vidět celý proces v celku, ve velkých kouscích s možností jejich detailování.
- Na základě technologické mapy je možné posoudit nutnost zavedení etap u konkrétního produktu, vymezit oblasti odpovědnosti, dohodnout smlouvy na vstupech a výstupech etap a přesněji posoudit potřebu zdrojů.
V následujících článcích si blíže popíšeme, jaké technické nástroje se používají k realizaci určitých technologických etap na naší mapě.
Autoři článku:
- — Head of Automation (DevOps) ve společnosti Positive Technologies
- - Náměstek Vedoucí oddělení automatizace (DevOps) ve společnosti Positive Technologies
Zdroj: www.habr.com