Kép:
Sziasztok! A cég automatizálási mérnökei vagyunk és támogatjuk a cég termékeinek fejlesztését: támogatjuk a teljes összeállítási folyamatot a fejlesztők által egy kódsor commitolásától a késztermékek és licencek frissítési szervereken való közzétételéig. Nem hivatalosan DevOps mérnököknek hívnak bennünket. Ebben a cikkben a szoftvergyártási folyamat technológiai szakaszairól szeretnénk beszélni, hogyan látjuk ezeket, és hogyan osztályozzuk őket.
Az anyagból megismerheti a többtermékes fejlesztés koordinálásának összetettségét, megtudhatja, hogy mi a technológiai térkép, és hogyan segíti a megoldások racionalizálását, lemásolását, mik a fejlesztési folyamat főbb szakaszai, lépései, milyenek a felelősségi területek. a DevOps és a cégünk csapatai között.
A Káoszról és a DevOpsról
Röviden, a DevOps koncepciója magában foglalja a fejlesztői eszközöket és szolgáltatásokat, valamint a használatukra vonatkozó módszereket és legjobb gyakorlatokat. Kiemeljük a globális a cél a DevOps ötletek cégünkben való megvalósításától: ez a termékek előállítási és karbantartási költségeinek következetes csökkentése mennyiségi értelemben (munkaóra vagy gépóra, CPU, RAM, Lemez stb.). A fejlesztés teljes költségének csökkentésének legegyszerűbb és legkézenfekvőbb módja az egész vállalat szintjén az minimálisra csökkentve a tipikus sorozatos feladatok elvégzésének költségeit a gyártás minden szakaszában. De mik ezek a szakaszok, hogyan különböztethetők meg az általános folyamattól, milyen lépésekből állnak?
Amikor egy cég egy terméket fejleszt, többé-kevésbé minden világos: általában van egy közös útiterv és fejlesztési séma. De mi a teendő, ha bővül a termékpaletta és egyre több termék van? Első pillantásra hasonló folyamatokkal és összeszerelő sorokkal rendelkeznek, és elkezdődik az „X különbségek keresése” játék a naplókban és a szkriptekben. De mi van akkor, ha már 5+ projekt van aktív fejlesztés alatt, és több, több éven keresztül kifejlesztett verzió támogatása szükséges? Szeretnénk a lehető legtöbb megoldást újra felhasználni a termékpályákon, vagy készek vagyunk pénzt költeni egy-egy egyedi fejlesztésre?
Hogyan lehet megtalálni az egyensúlyt az egyediség és a sorozatos megoldások között?
Ezek a kérdések 2015 óta egyre gyakrabban merültek fel előttünk. A termékek száma nőtt, és igyekeztünk minimálisra bővíteni automatizálási részlegünket (DevOps), amely ezen termékek összeszerelő sorait támogatta. Ugyanakkor a lehető legtöbb megoldást szerettük volna megismételni a termékek között. Végül is miért csinálja ugyanazt a dolgot tíz termékben különböző módon?
fejlesztési igazgató: "Srácok, ki tudnánk valahogy értékelni, hogy a DevOps mit tesz a termékekkel?"
Mi: "Nem tudjuk, nem tettünk fel ilyen kérdést, de milyen mutatókat érdemes figyelembe venni?"
fejlesztési igazgató: "Ki tudja! Gondol…"
Mint abban a híres filmben: "Szállodában vagyok! .." - "Uh... Meg tudod mutatni az utat?" Gondolkodva arra a következtetésre jutottunk, hogy először a termékek végső állapotáról kell döntenünk; ez lett az első gólunk.
Tehát hogyan lehet egy tucat terméket elemezni meglehetősen nagy, 10-200 fős csapatokkal, és hogyan lehet mérhető mutatókat meghatározni a megoldások replikálásakor?
1:0 a Chaos javára, vagy DevOps a lapockákon
Kezdetben kísérletet tettünk a BPwin sorozatból származó IDEF0 diagramok és különféle üzleti folyamat diagramok alkalmazására. A zűrzavar a következő projekt következő szakaszának ötödik négyzete után kezdődött, és ezek a négyzetek minden projekthez egy hosszú piton farkába rajzolhatók 50+ lépés alatt. Szomorúnak éreztem magam, és üvölteni akartam a Holdon - ez általában nem illett.
Tipikus gyártási feladatok
A gyártási folyamatok modellezése nagyon összetett és fáradságos munka: rengeteg adatot kell összegyűjteni, feldolgozni és elemezni a különböző részlegektől és gyártási láncoktól. Erről bővebben a " cikkben olvashat".
Amikor elkezdtük a gyártási folyamatunk modellezését, konkrét célunk volt, hogy a cégünk termékeinek fejlesztésében részt vevő minden munkatárshoz, projektmenedzserekhez eljuttassuk:
- hogyan jutnak el a termékek és összetevőik egy kódsor véglegesítésétől kezdve a vásárlóhoz telepítők és frissítések formájában,
- milyen erőforrásokat biztosítanak a termékek előállításának egyes szakaszaihoz,
- milyen szolgáltatásokról van szó az egyes szakaszokban,
- hogyan határolják el az egyes szakaszok felelősségi területeit,
- milyen szerződések léteznek az egyes szakaszok be- és kilépésénél.
A képre kattintva teljes méretben megnyílik.
Munkánk a cégnél több funkcionális területre oszlik. Az infrastruktúra osztály foglalkozik az osztály összes hardver erőforrásának működésének optimalizálásával, valamint a virtuális gépek és a rajtuk lévő környezet telepítésének automatizálásával. A felügyeleti irány a hét minden napján, 24 órában biztosítja a szolgáltatások teljesítményének ellenőrzését; fejlesztők számára szolgáltatásként monitorozást is biztosítunk. A munkafolyamat iránya eszközöket biztosít a csapatoknak a fejlesztési és tesztelési folyamatok menedzseléséhez, a kódállapot elemzéséhez és a projektekre vonatkozó elemzésekhez. És végül a webdev irány biztosítja a kiadások közzétételét a GUS és FLUS frissítési szervereken, valamint a LicenseLab szolgáltatás használatával a termékek licencelését. A gyártási folyamat támogatása érdekében számos különböző támogatási szolgáltatást hozunk létre és tartunk fenn a fejlesztők számára (néhányról történeteket hallgathat meg a régi találkozókon: и). Belső automatizálási eszközöket is fejlesztünk, pl .
Munkánkban az elmúlt öt évben rengeteg azonos típusú és rutinszerű művelet halmozódott fel, más részlegekről fejlesztőink elsősorban az ún. tipikus feladatok, melynek megoldása teljesen vagy részben automatizált, nem okoz nehézséget az előadóknak és nem igényel jelentős mennyiségű munkát. A vezető területekkel együtt elemeztük az ilyen feladatokat, és sikerült azonosítani az egyes munkakategóriákat, ill gyártási lépések, a szakaszokat oszthatatlan lépésekre osztották, és több szakasz összeadódik gyártási folyamat lánc.
A technológiai lánc legegyszerűbb példája az egyes termékeink összeszerelésének, telepítésének és tesztelésének szakaszai a vállalaton belül. Az összeállítási szakasz például sok különálló, tipikus lépésből áll: források letöltése a GitLab-ból, függőségek és harmadik féltől származó könyvtárak előkészítése, egységteszt és statikus kódelemzés, összeállítási szkript végrehajtása GitLab CI-n, műtermékek közzététele a tárolóban A kibocsátási megjegyzések mesterséges előállítása és generálása belső ChangelogBuilder eszközünkön keresztül.
A tipikus DevOps-feladatokról a Habréról szóló további cikkeinkben olvashat: ""És"".
Számos tipikus termelési lánc alakul ki gyártási folyamat. A folyamatok leírásának standard megközelítése a funkcionális IDEF0 modellek használata.
Példa egy gyártási CI folyamat modellezésére
Kiemelt figyelmet fordítottunk a folyamatos integrációs rendszer standard projektjeinek kidolgozására. Ezzel lehetővé vált a projektek egységesítése, kiemelve az ún kiadás build séma promóciókkal.
Íme, hogyan működik. Minden projekt tipikusnak tűnik: tartalmazzák az összeállítások konfigurációját, amelyek az Artifactory pillanatkép-lerakatába kerülnek, majd telepítik és tesztelik őket a tesztpadokon, majd előléptetik a kiadási tárba. Az Artifactory szolgáltatás egyetlen pont az összes összeállítási műtermék elosztására a csapatok és más szolgáltatások között.
Ha nagyban leegyszerűsítjük és általánosítjuk kiadási sémánkat, akkor az a következő lépéseket tartalmazza:
- keresztplatformos termékösszeállítás,
- kihelyezés a próbapadokra,
- funkcionális és egyéb tesztek indítása,
- tesztelt buildek népszerűsítése az Artifactory tárolóinak kiadásához,
- frissítési szerverekre épülő kiadás közzététele,
- összeállítások és frissítések szállítása a gyártásba,
- a termék telepítésének és frissítésének elindítása.
Vegyük például ennek a tipikus kiadási sémának a technológiai modelljét (a továbbiakban egyszerűen Modell) egy funkcionális IDEF0 modell formájában. Ez tükrözi a CI folyamatunk főbb szakaszait. Az IDEF0 modellek az ún ICOM jelölés (Input-Control-Output-Mechanism), hogy leírja, milyen erőforrásokat használnak az egyes szakaszokban, milyen szabályok és követelmények alapján történik a munka, mi a kimenet, és milyen mechanizmusok, szolgáltatások vagy emberek valósítanak meg egy adott szakaszt.
A képre kattintva teljes méretben megnyílik.
Általános szabály, hogy a folyamatok leírását a funkcionális modellekben könnyebb felbontani és részletezni. De ahogy növekszik az elemek száma, úgy válik egyre nehezebben megérteni bennük valamit. A valódi fejlesztésben azonban vannak segédszakaszok is: monitorozás, termékek tanúsítása, munkafolyamatok automatizálása és mások. A méretezési probléma miatt hagytuk el ezt a leírást.
Remény születése
Az egyik könyvben a technológiai folyamatokat leíró régi szovjet térképekre bukkantunk (melyeket egyébként sok állami vállalatnál és egyetemen ma is használnak). Várj, várj, mert nekünk is van munkafolyamatunk!... Vannak szakaszok, eredmények, mérőszámok, követelmények, mutatók, és így tovább, és így tovább… Miért ne próbálnánk meg folyamatábrákot alkalmazni a termékfolyamatainkra is? Volt egy érzés: „Ez az! Megtaláltuk a megfelelő szálat, ideje jól elhúzni!
Egy egyszerű táblázatban úgy döntöttünk, hogy a termékeket oszloponként, a technológiai szakaszokat és a termékfolyamatokat pedig soronként rögzítjük. A mérföldkövek valami nagy dolog, például egy terméképítési lépés. A lépések pedig kisebbek és részletesebbek, mint például a forráskód letöltése a build szerverre vagy a kód fordításának lépése.
A térkép sorainak és oszlopainak metszéspontjaiban egy adott szakasz és termék állapotát írjuk le. Az állapotokhoz egy sor állapotot határoztak meg:
- Нет данных - vagy nem megfelelő. Elemezni kell a termék egy szakasza iránti keresletet. Vagy az elemzés már megtörtént, de a szakaszra jelenleg nincs szükség, vagy gazdaságilag nem indokolt.
- Elhalasztva - vagy jelenleg nem releváns. Előkészületben lévő szakaszra van szükség, de ebben az évben nincs erő a megvalósításhoz.
- Tervezett. A szakasz megvalósítását az idén tervezik.
- Rájött. A folyamatban lévő szakasz a szükséges mennyiségben megvalósul.
A táblázat kitöltése projektről projektre kezdődött. Először egy projekt szakaszait és lépéseit osztályozták, és ezek állapotát rögzítették. Ezután vették a következő projektet, rögzítették benne a státuszokat, és hozzáadták azokat a szakaszokat és lépéseket, amelyek a korábbi projektekben hiányoztak. Ennek eredményeként megkaptuk a teljes gyártási folyamatunk szakaszait és lépéseit, valamint azok állapotát egy adott projektben. Valami hasonló a termékfolyamat kompetencia mátrixához. Az ilyen mátrixot technológiai térképnek neveztük.
A technológiai térkép segítségével metrológiailag ésszerűen egyeztetjük a csapatokkal az évre vonatkozó munkaterveket és a közösen megvalósítani kívánt célokat: mely szakaszokat egészítjük ki az idén, és melyeket hagyunk későbbre. Munka közben előfordulhat, hogy az általunk csak egy terméknél végrehajtott lépésekben is javultak. Ezután kibővítjük térképünket, és ezt a fejlesztést szakaszként vagy új lépésként bevezetjük, majd minden termékre vonatkozóan elemzést végzünk, és megtudjuk, hogy a fejlesztés megismételhető-e.
Kifogásolhatják velünk szemben: „Ez természetesen jó, csak idővel a lépések és szakaszok száma túlságosan nagy lesz. Hogyan legyen?
Az egyes szakaszokhoz és lépésekhez szabványos és meglehetősen teljes követelményleírásokat vezettünk be, hogy azokat a vállalaton belül mindenki egyformán értse. Idővel, ahogy a fejlesztések bevezetésre kerülnek, egy lépés egy másik szakaszba vagy lépésbe kerülhet, majd ezek "összeomlanak". Ugyanakkor minden követelmény és technológiai árnyalat illeszkedik az általánosító szakasz vagy lépés követelményeihez.
Hogyan értékelhető a replikált megoldások hatása? Rendkívül egyszerű megközelítést alkalmazunk: az új szakasz megvalósításának kezdeti tőkeköltségeit az éves általános termékköltségekhez rendeljük, majd a replikáció során elosztjuk az összessel.
A fejlesztés egyes részei már mérföldkövekként és lépésekként jelennek meg a térképen. A termék költségének csökkentését a jellemző szakaszok automatizálásának bevezetésével tudjuk befolyásolni. Ezt követően figyelembe vesszük a minőségi jellemzők, a mennyiségi mutatók változásait és a csapatok által elért profitot (munkaórában vagy gépórában).
A gyártási folyamat technológiai térképe
Ha minden szakaszunkat és lépésünket megtesszük, címkékkel kódoljuk és egy láncba bontjuk, akkor nagyon hosszú és érthetetlen lesz (csak a „python farok”, amelyről a cikk elején beszéltünk) :
[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]Ezek a termékek [Build] felépítésének, tesztszervereken való üzembe helyezésének [Deploy], tesztelésének [Test], a tesztelés eredményein alapuló lerakat-kiadások promóciójának [Promote], licencek generálásának és közzétételének szakaszai [Licenc], közzététel [ Közzététel] a GUS frissítési kiszolgálón és szállítás a FLUS frissítési kiszolgálókra, a termékösszetevők telepítése és frissítése az ügyfél infrastruktúrájában a Termékkonfiguráció-kezelés [Telepítés] segítségével, valamint a telemetria [Telemetria] összegyűjtése a telepített termékekből.
Rajtuk kívül külön szakaszok különböztethetők meg: infrastruktúra állapotfigyelés [InfMonitoring], forráskód verziószámítás [SourceCodeControl], build környezet előkészítése [Prepare], projektmenedzsment [Workflow], csapatok kommunikációs eszközökkel való ellátása [Kommunikáció], terméktanúsítás [ Tanúsítás] és a CI-folyamatok önellátásának biztosítása [CISelfSuffficiency] (például az összeállítások függetlensége az internettől). A folyamataink több tucat lépését nem is vesszük figyelembe, mert ezek nagyon specifikusak.
Sokkal könnyebb lesz megérteni és áttekinteni a teljes gyártási folyamatot, ha az formában jelenik meg technológiai térkép; ez egy táblázat, amelyben a Modell egyes gyártási szakaszai és felbontott lépései sorokba vannak írva, oszlopokba pedig az egyes szakaszokban vagy lépésekben végzett tevékenységek leírása. A fő hangsúly az egyes szakaszokat biztosító erőforrásokon, a felelősségi területek lehatárolásán van.
A térkép számunkra egyfajta osztályozó. A termékek előállításának nagy technológiai részét tükrözi. Ennek köszönhetően automatizálási csapatunk számára könnyebbé vált a fejlesztőkkel való együttműködés és az automatizálási szakaszok megvalósításának közös megtervezése, valamint annak megértése, hogy ehhez milyen munkaerő-költségek és erőforrások (emberi és hardver) szükségesek.
Cégünkön belül a térkép automatikusan generálódik a jinja sablonból normál HTML fájlként, majd feltöltődik a GitLab Pages szerverére. Megtekinthető egy képernyőkép egy teljesen generált térkép példájával .
A képre kattintva teljes méretben megnyílik.
Röviden, a technológiai térkép a gyártási folyamat általánosított képe, amely jól besorolt blokkokat tükröz, jellegzetes funkcionalitással.
Útitérképünk felépítése
A térkép több részből áll:
- Címterület - itt a térkép általános leírása, az alapfogalmak bemutatása, a gyártási folyamat fő erőforrásainak és eredményeinek meghatározása.
- Irányítópult - itt szabályozhatja az egyes termékek adatainak megjelenítését, az összes termékre vonatkozóan általánosságban összefoglalja a megvalósított szakaszokat és lépéseket.
- Technológiai térkép - a technológiai folyamat táblázatos leírása. A térképen:
- minden szakasz, lépés és ezek kódja adott;
- a szakaszok rövid és teljes leírását adják meg;
- az egyes szakaszokban felhasznált bemeneti erőforrások és szolgáltatások fel vannak tüntetve;
- az egyes szakaszok és az egyes lépések eredményeit feltüntetik;
- fel van tüntetve az egyes szakaszok és lépések felelősségi köre;
- meghatározásra kerültek a műszaki erőforrások, mint például a HDD (SSD), RAM, vCPU, és a munka ebben a szakaszban történő támogatásához szükséges munkaórák, mind a jelen pillanatban - tény, mind a jövőben - terv;
- minden terméknél fel kell tüntetni, hogy mely technológiai szakaszok vagy lépések valósultak meg, melyek megvalósítását tervezik, azok nem relevánsak vagy nem valósultak meg.
Döntéshozatal a technológiai térkép alapján
A térkép tanulmányozása után néhány lépést megtehet az alkalmazott vállalatban betöltött szerepétől függően (fejlesztési vezető, termékmenedzser, fejlesztő vagy tesztelő):
- megérteni, hogy mely szakaszok hiányoznak egy valós termékből vagy projektből, és felmérik azok megvalósításának szükségességét;
- több osztály közötti felelősségi körök elhatárolása, ha különböző szakaszokon dolgoznak;
- szerződések tárgyalása a szakaszok be- és kimeneteire vonatkozóan;
- integrálja munkaszakaszát az általános fejlesztési folyamatba;
- pontosabban felmérheti az egyes szakaszokat biztosító erőforrások szükségességét.
Összefoglalva a fentieket
A technológiai térkép sokoldalú, bővíthető és könnyen karbantartható. A folyamatok leírását ebben a formában sokkal könnyebb kidolgozni és fenntartani, mint egy szigorú akadémiai IDEF0 modellben. Ezenkívül a táblázatos leírás egyszerűbb, ismertebb és jobban felépített, mint egy funkcionális modell.
A lépések technikai megvalósításához speciális belső eszközünk a CrossBuilder - egy rétegeszköz a CI rendszerek, szolgáltatások és infrastruktúra között. A fejlesztőnek nem kell levágnia a motorját: CI rendszerünkben elegendő a CrossBuilder eszköz egyik szkriptjét (az ún. feladatot) lefuttatni, amely azt megfelelően végrehajtja, figyelembe véve infrastruktúránk adottságait. .
Eredményei
A cikk elég hosszúra sikeredett, de ez elkerülhetetlen a komplex folyamatok modellezésének ismertetésekor. Végezetül szeretném röviden rögzíteni fő gondolatainkat:
- A DevOps ötletek cégünkben való megvalósításának célja a cég termékeinek előállítási és karbantartási költségeinek következetes csökkentése mennyiségi értelemben (munkaóra vagy gépóra, vCPU, RAM, Disk).
- A fejlesztés összköltsége csökkentésének egyik módja a szabványos soros feladatok – a technológiai folyamat szakaszai és lépései – végrehajtásának költségének minimalizálása.
- Tipikus feladat olyan feladat, amelynek megoldása teljesen vagy részben automatizált, nem okoz nehézséget az elvégzőknek és nem igényel jelentős munkaerőköltséget.
- A gyártási folyamat szakaszokból áll, a szakaszok oszthatatlan lépésekre oszlanak, amelyek különböző léptékű és terjedelmű tipikus feladatok.
- Az egymástól eltérő tipikus feladatoktól elérkeztünk a bonyolult technológiai láncokhoz, a gyártási folyamat többszintű modelljéig, amelyek leírhatók funkcionális IDEF0 modellel vagy egyszerűbb technológiai térképpel.
- A technológiai térkép a gyártási folyamat szakaszainak és lépéseinek táblázatos ábrázolása. A legfontosabb: a térkép lehetővé teszi, hogy a teljes folyamatot teljes egészében, nagy darabokban, részletezési lehetőséggel láthassa.
- A technológiai térkép alapján felmérhető az adott termékben szakaszok bevezetésének szükségessége, a felelősségi területek lehatárolása, a szakaszok be- és kimenetein szerződések megkötése, az erőforrásigény pontosabb felmérése.
A következő cikkekben részletesebben leírjuk, milyen technikai eszközökkel valósítunk meg egyes technológiai szakaszokat térképünkön.
A cikk szerzői:
- — A Positive Technologies automatizálási (DevOps) vezetője
- - Helyettes A Positive Technologies automatizálási osztályának (DevOps) vezetője
Forrás: will.com