Pilt:
Tere kõigile! Oleme ettevõtte automaatikainsenerid ja toetame ettevõtte toodete arendamist: toetame kogu montaažikonveierit alates koodirea koostamisest arendajate poolt kuni valmistoodete ja litsentside avaldamiseni värskendusserverites. Mitteametlikult kutsutakse meid DevOpsi inseneriteks. Selles artiklis tahame rääkida tarkvara tootmisprotsessi tehnoloogilistest etappidest, sellest, kuidas me neid näeme ja kuidas neid liigitame.
Materjalist saad teada mitme toote arenduse koordineerimise keerukusest, sellest, mis on tehnoloogiline kaart ja kuidas see aitab lahendusi ühtlustada ja korrata, millised on arendusprotsessi peamised etapid ja sammud, kuidas on vastutusvaldkonnad. DevOpsi ja meie ettevõtte meeskondade vahel.
Kaose ja DevOpsi kohta
Lühidalt, DevOpsi kontseptsioon hõlmab arendustööriistu ja -teenuseid, samuti nende kasutamise metoodikat ja parimaid tavasid. Toome eraldi välja globaalse eesmärk DevOpsi ideede realiseerimisest meie ettevõttes: see on toodete tootmis- ja hoolduskulude järjepidev vähendamine kvantitatiivses mõttes (töötunnid või masinatunnid, protsessor, RAM, ketas jne). Lihtsaim ja ilmsem viis kogu ettevõtte tasemel arendustegevuse üldkulusid vähendada on minimeerida tüüpiliste seeriaülesannete täitmise kulud kõikides tootmisetappides. Aga mis need etapid on, kuidas neid üldisest protsessist eraldada, millistest etappidest need koosnevad?
Kui ettevõte arendab üht toodet, on kõik enam-vähem selge: tavaliselt on olemas ühine teekaart ja arendusskeem. Mida aga teha, kui tootesari laieneb ja tooteid tuleb juurde? Esmapilgul on neil sarnased protsessid ja koosteliinid ning algab logides ja skriptides mäng “leida X erinevusi”. Aga mis siis, kui aktiivses arenduses on juba 5+ projekti ja vaja on tuge mitmele mitme aasta jooksul arendatud versioonile? Kas soovime tootevalikus taaskasutada maksimaalset võimalikku arvu lahendusi või oleme valmis kulutama raha iga kordumatu arenduse peale?
Kuidas leida tasakaal unikaalsuse ja seerialahenduste vahel?
Need küsimused hakkasid meie ees üha sagedamini kerkima alates 2015. aastast. Toodete arv kasvas ja püüdsime oma automatiseerimisosakonda (DevOps), mis toetas nende toodete koosteliine, viia miinimumini. Samal ajal soovisime võimalikult palju lahendusi toodete vahel kopeerida. Lõppude lõpuks, miks teha sama asja kümnes tootes erineval viisil?
arendusdirektor: "Poisid, kas me saame kuidagi hinnata, mida DevOps toodete jaoks teeb?"
Me: "Me ei tea, me ei küsinud sellist küsimust, aga milliste näitajatega tuleks arvestada?"
arendusdirektor: "Kes teab! Mõtle…”
Nagu tolles kuulsas filmis: "Ma olen hotellis! .." - "Ah... Kas sa saad mulle teed näidata?" Mõeldes jõudsime järeldusele, et kõigepealt peame otsustama toodete lõppseisundi üle; sellest sai meie esimene eesmärk.
Niisiis, kuidas analüüsida tosinat toodet üsna suurte, 10–200 inimesest koosnevate meeskondadega ja määrata lahenduste kordamisel mõõdetavad mõõdikud?
1:0 Chaose kasuks ehk DevOps abaluudel
Alustasime katsega rakendada IDEF0 diagramme ja erinevaid BPwini seeria äriprotsesside diagramme. Segadus algas pärast järgmise projekti järgmise etapi viiendat ruutu ja need ruudud iga projekti kohta saab tõmmata pika püütoni saba alla 50+ sammu. Tundsin end kurvalt ja tahtsin kuu peale ulguda - üldiselt see ei sobinud.
Tüüpilised tootmisülesanded
Tootmisprotsesside modelleerimine on väga keeruline ja vaevarikas töö: tuleb koguda, töödelda ja analüüsida palju andmeid erinevatest osakondadest ja tootmisahelatest. Lisateavet selle kohta saate lugeda artiklist "'.
Tootmisprotsessi modelleerimisega alustades oli meil konkreetne eesmärk – edastada igale meie ettevõtte toodete arendamisega seotud töötajale ja projektijuhtidele:
- kuidas tooted ja nende komponendid, alustades koodirea sidumisest, jõuavad paigaldajate ja uuendustena kliendini,
- millised vahendid on ette nähtud toodete tootmise igaks etapiks,
- milliseid teenuseid igas etapis kaasatakse,
- kuidas on piiritletud iga etapi vastutusalad,
- millised lepingud on olemas iga etapi sisenemisel ja väljumisel.
Pildile klõpsates avaneb see täissuuruses.
Meie töö ettevõttes jaguneb mitmeks funktsionaalseks valdkonnaks. Infrastruktuuri suund tegeleb osakonna kõigi "raudsete" ressursside töö optimeerimisega, samuti virtuaalmasinate ja nendel oleva keskkonna juurutamise automatiseerimisega. Järelevalve suund tagab 24/7 teenuse toimivuse kontrolli; pakume arendajatele teenusena ka monitooringut. Töövoo suund pakub meeskondadele tööriistu arendus- ja testimisprotsesside haldamiseks, koodi oleku analüüsimiseks ja projektide analüüsi saamiseks. Ja lõpuks, veebidevi suund pakub väljaannete avaldamist GUS-i ja FLUS-i värskendusserverites, samuti toodete litsentsimist LicenseLabi teenuse abil. Tootmistoru toetamiseks seadistame ja hooldame arendajatele palju erinevaid tugiteenuseid (mõnede kohta saate lugusid kuulata vanadel kohtumistel: и). Samuti arendame sisemisi automatiseerimisvahendeid, sh .
Viimase viie aasta jooksul on meie töösse kogunenud palju sama tüüpi ja rutiinseid operatsioone ning meie arendajad teistest osakondadest tulevad peamiselt nn. tüüpilised ülesanded, mille lahendamine on täielikult või osaliselt automatiseeritud, ei tekita esinejatele raskusi ega nõua märkimisväärset töömahtu. Koos juhtivate valdkondadega analüüsisime selliseid ülesandeid ja suutsime välja tuua üksikud töökategooriad või tootmisetapid, etapid jagunesid jagamatuteks sammudeks ja mitu etappi liidetakse kokku tootmisprotsessi ahel.
Lihtsaim näide tehnoloogilisest ahelast on iga meie toote kokkupanemise, juurutamise ja testimise etapid ettevõtte sees. Näiteks koosneb ehitusetapp omakorda paljudest eraldi tüüpilistest etappidest: allikate allalaadimine GitLabist, sõltuvuste ja kolmanda osapoole teekide ettevalmistamine, üksuste testimine ja staatilise koodi analüüs, ehitusskripti käivitamine GitLabi CI-s, artefaktide avaldamine hoidlas Artefactory ja väljalaskemärkmete loomine meie sisemise tööriista ChangelogBuilder kaudu.
Tüüpiliste DevOpsi ülesannete kohta saate lugeda meie teistest Habré artiklitest: ""Ja"'.
Moodustub palju tüüpilisi tootmisahelaid tootmisprotsess. Standardne lähenemine protsesside kirjeldamisel on funktsionaalsete IDEF0 mudelite kasutamine.
Tootmis-CI protsessi modelleerimise näide
Erilist tähelepanu pöörasime pideva integratsioonisüsteemi tüüpprojektide väljatöötamisele. See võimaldas saavutada projektide ühtlustamise, tuues esile nn vabastamise ehitusskeem koos tutvustustega.
See toimib järgmiselt. Kõik projektid näevad tüüpilised välja: need hõlmavad Artifactory hetktõmmistehoidlasse kuuluvate koostude konfiguratsiooni, misjärel neid juurutatakse ja testitakse katsestendil ning seejärel viiakse need väljalaskehoidlasse. Teenus Artifactory on üks jaotuspunkt kõigi ehitusartefaktide jaoks meeskondade ja muude teenuste vahel.
Kui me oma väljalaskekava oluliselt lihtsustame ja üldistame, sisaldab see järgmisi samme:
- platvormideülene toote kokkupanek,
- kasutuselevõtt katsestendidesse,
- funktsionaalsete ja muude testide läbiviimine,
- Artifactori hoidlate väljalaskmiseks testitud ehituste reklaamimine,
- väljalase avaldamine põhineb värskendusserveritel,
- komplektide ja uuenduste tarnimine tootmisse,
- toote installimise ja värskendamise käivitamine.
Näiteks vaatleme selle tüüpilise väljalaske skeemi (edaspidi lihtsalt mudel) tehnoloogilist mudelit funktsionaalse IDEF0 mudeli kujul. See kajastab meie CI protsessi peamisi etappe. IDEF0 mudelid kasutavad nn ICOM-i märge (Input-Control-Output-Mechanism), et kirjeldada, milliseid ressursse igal etapil kasutatakse, milliste reeglite ja nõuete alusel tööd tehakse, milline on väljund ja millised mehhanismid, teenused või inimesed konkreetset etappi rakendavad.
Pildile klõpsates avaneb see täissuuruses.
Funktsionaalsetes mudelites on protsesside kirjeldust reeglina lihtsam lahti võtta ja detailselt kirjeldada. Kuid elementide arvu kasvades muutub neis millestki aru saamine järjest keerulisemaks. Kuid reaalses arenduses on ka abietapid: monitooring, toodete sertifitseerimine, tööprotsesside automatiseerimine ja muud. Mastaapimisprobleemi tõttu loobusime sellest kirjeldusest.
Lootuse sünd
Ühes raamatus leidsime vanu nõukogudeaegseid tehnoloogilisi protsesse kirjeldavaid kaarte (mis, muide, on kasutusel ka tänapäeval paljudes riigiettevõtetes ja ülikoolides). Oota, oota, sest meil on ka töövoog!.. On etappe, tulemusi, mõõdikuid, nõudeid, näitajaid ja nii edasi ja nii edasi... Miks mitte proovida rakendada vootabeleid ka meie tootejuhtmetele? Tekkis tunne: “See on see! Leidsime õige lõnga, on aeg see hästi tõmmata!
Lihtsas tabelis otsustasime kirjendada tooted veergude kaupa ning tehnoloogilised etapid ja tootekonveieri etapid ridade kaupa. Verstapostid on midagi suurt, näiteks toote loomise etapp. Ja sammud on midagi väiksemat ja üksikasjalikumat, näiteks lähtekoodi ehitusserverisse allalaadimise etapp või koodi koostamise etapp.
Kaardi ridade ja veergude ristumiskohtades paneme kirja konkreetse etapi ja toote staatused. Olekute jaoks määrati olekute komplekt:
- Teave puudub - või sobimatu. On vaja analüüsida nõudlust toote etapi järele. Kas analüüs on juba tehtud, kuid etapp ei ole hetkel vajalik või ei ole majanduslikult põhjendatud.
- Edasi lükatud - või ei ole hetkel asjakohane. Etapi ettevalmistamine on vajalik, kuid selle rakendamiseks sel aastal jõudu pole.
- Planeeritud. Etapp on plaanis ellu viia sel aastal.
- Rakendatud. Torustikus olev etapp on rakendatud vajalikus mahus.
Tabeli täitmine algas projektide kaupa. Esmalt klassifitseeriti ühe projekti etapid ja sammud ning fikseeriti nende staatused. Seejärel võtsid nad järgmise projekti, fikseerisid selles olekud ja lisasid etapid ja sammud, mis eelmistes projektides puudusid. Selle tulemusena saime kogu oma tootmiskonveieri etapid ja etapid ning nende staatused konkreetses projektis. Selgus midagi sarnast toote torujuhtme pädevusmaatriksiga. Me nimetasime sellist maatriksit tehnoloogiliseks kaardiks.
Tehnoloogilise kaardi abil kooskõlastame metroloogiliselt mõistlikult meeskondadega aasta tööplaanid ja eesmärgid, mida soovime koos saavutada: millised etapid sel aastal projekti lisame ja millised jätame hilisemaks. Samuti võib meil töö käigus tekkida täiustusi etappides, mille oleme lõpetanud vaid ühe toote puhul. Seejärel laiendame oma kaarti ja tutvustame seda täiustust etapi või uue sammuna, seejärel analüüsime iga toote puhul ja selgitame välja parenduse kordamise teostatavuse.
Nad võivad meile vastu vaielda: „See kõik on muidugi hea, ainult aja jooksul muutub sammude ja etappide arv üle jõu käivaks. Kuidas olla?
Oleme iga etapi ja sammu jaoks kasutusele võtnud standardsed ja üsna täielikud nõuete kirjeldused, et need oleksid ettevõttes kõigile ühtmoodi arusaadavad. Aja jooksul, kui täiustusi kasutusele võetakse, võib samm sulanduda teise etappi või astmesse ja seejärel "kokku kukkuda". Samas sobivad kõik nõuded ja tehnoloogilised nüansid üldistava etapi või sammu nõuetega.
Kuidas hinnata lahenduste kordamise mõju? Kasutame ülilihtsat lähenemist: omistame uue etapi rakendamise algkapitalikulud iga-aastastele toote üldkuludele ja jagame seejärel kordamisel kõigiga.
Osa arendusest on kaardil juba näidatud verstapostide ja sammudena. Toote maksumuse vähendamist saame mõjutada tüüpiliste etappide automatiseerimise juurutamise kaudu. Seejärel võtame arvesse muutusi kvalitatiivsetes näitajates, kvantitatiivsetes mõõdikutes ja meeskondadele laekuvas kasumis (säästu inim- või masintundides).
Tootmisprotsessi tehnoloogiline kaart
Kui võtame kõik oma etapid ja sammud, kodeerime need siltidega ja laiendame need üheks ahelaks, siis osutub see väga pikaks ja arusaamatuks (just see “püütoni saba”, millest me artikli alguses rääkisime) :
[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]Need on toodete loomise etapid [Build], nende testserveritesse juurutamine [juurutamine], testimine [Test], hoidlate väljalaskmise järkude reklaamimine testimise [Promote] tulemuste põhjal, litsentside loomine ja avaldamine [litsents], avaldamine [ Avaldamine] GUS-i värskendusserveris ja tarnimine FLUS-i värskendusserveritele, tootekomponentide installimine ja värskendamine kliendi infrastruktuuri tootekonfiguratsioonihalduse [Install] abil, samuti telemeetria [Telemeetria] kogumine installitud toodetest.
Lisaks neile saab eristada eraldi etappe: infrastruktuuri oleku jälgimine [InfMonitoring], lähtekoodi versioonide loomine [SourceCodeControl], ehituskeskkonna ettevalmistamine [Prepare], projektijuhtimine [Workflow], meeskondade varustamine suhtlusvahenditega [Communication], toote sertifitseerimine [ Sertifitseerimine] ja CI protsesside iseseisvuse tagamine [CISelfSuffiency] (näiteks sõlmede sõltumatus Internetist). Kümneid etappe meie protsessides isegi ei arvestata, sest need on väga spetsiifilised.
Kogu tootmisprotsessi on palju lihtsam mõista ja vaadata, kui see on vormis tehnoloogiline kaart; see on tabel, milles on ridadena kirjas mudeli üksikud tootmisetapid ja tükeldatavad etapid ning veergudes iga etapi või etapi tegemise kirjeldus. Põhirõhk on pandud iga etapi ressurssidele ja vastutusvaldkondade piiritlemisele.
Kaart on meie jaoks omamoodi klassifikaator. See peegeldab toodete tootmise suuri tehnoloogilisi osi. Tänu sellele muutus meie automatiseerimismeeskonnal lihtsamaks suhtlemine arendajatega ja ühine automatiseerimise etappide elluviimise kavandamine, samuti arusaamine, milliseid tööjõukulusid ja ressursse (inim- ja riistvara) selleks vaja on.
Meie ettevõttes genereeritakse kaart automaatselt jinja mallist tavalise HTML-failina ja laaditakse seejärel üles GitLabi lehtede serverisse. Täielikult loodud kaardi näitega saab vaadata ekraanipilti .
Pildile klõpsates avaneb see täissuuruses.
Lühidalt öeldes on tehnoloogiline kaart tootmisprotsessi üldistatud pilt, mis kajastab selgelt klassifitseeritud tüüpilise funktsionaalsusega plokke.
Meie teekaardi struktuur
Kaart koosneb mitmest osast:
- Pealkirja ala - siin on kaardi üldine kirjeldus, tutvustatakse põhimõisteid, määratletakse peamised ressursid ja tootmisprotsessi tulemused.
- Armatuurlaud - siin saate juhtida üksikute toodete andmete kuvamist, esitatakse kõigi toodete puhul rakendatud etappide ja sammude kokkuvõte üldiselt.
- Tehnoloogiline kaart – tehnoloogilise protsessi tabelikirjeldus. Kaardil:
- kõik etapid, sammud ja nende koodid on antud;
- esitatakse etappide lühikesed ja täielikud kirjeldused;
- näidatakse igas etapis kasutatavad sisendressursid ja teenused;
- näidatakse iga etapi ja eraldi etapi tulemused;
- on märgitud iga etapi ja sammu vastutusala;
- on kindlaks määratud tehnilised ressursid, nagu HDD (SSD), RAM, vCPU ja töötunnid, mis on vajalikud selles etapis töö toetamiseks nii praegusel hetkel - fakt kui ka tulevikus - plaan;
- iga toote puhul on märgitud, millised tehnoloogilised etapid või sammud selle jaoks on rakendatud, kavandatud juurutamiseks, ebaolulised või rakendamata.
Otsuste tegemine tehnoloogilise kaardi alusel
Peale kaardiga tutvumist on võimalik teha mõningaid toiminguid – olenevalt töötaja rollist ettevõttes (arendusjuht, tootejuht, arendaja või testija):
- mõista, millised etapid reaalses tootes või projektis puuduvad, ning hinnata nende elluviimise vajadust;
- piiritlema vastutusalad mitme osakonna vahel, kui need töötavad erinevatel etappidel;
- leppida kokku lepingud lavade sisse- ja väljapääsude juures;
- integreerida oma tööetapp üldisesse arendusprotsessi;
- täpsemalt hinnata ressursside vajadust, mis tagavad iga etapi.
Kõike eelnevat kokku võttes
Marsruutimine on mitmekülgne, laiendatav ja hõlpsasti hooldatav. Protsesside kirjeldust on sellisel kujul palju lihtsam välja töötada ja säilitada kui ranges akadeemilises IDEF0 mudelis. Lisaks on tabelikirjeldus lihtsam, tuttavam ja paremini struktureeritud kui funktsionaalne mudel.
Sammude tehniliseks teostamiseks on meil spetsiaalne sisemine tööriist CrossBuilder – kihitööriist CI süsteemide, teenuste ja infrastruktuuri vahel. Arendaja ei pea oma jalgratast lõikama: meie CI-süsteemis piisab CrossBuilderi tööriista ühe skripti (nn ülesande) käivitamisest, mis käivitab selle õigesti, võttes arvesse meie infrastruktuuri funktsioone. .
Tulemused
Artikkel osutus üsna pikaks, kuid keeruliste protsesside modelleerimise kirjeldamisel on see paratamatu. Lõpetuseks tahaksin lühidalt fikseerida meie peamised ideed:
- DevOps ideede elluviimise eesmärk meie ettevõttes on järjepidevalt vähendada ettevõtte toodete tootmis- ja hoolduskulusid kvantitatiivselt (töötunnid või masinatunnid, vCPU, RAM, Disk).
- Arengu üldkulude vähendamise viis on minimeerida tüüpiliste seeriaülesannete täitmise kulud: tehnoloogilise protsessi etapid ja sammud.
- Tüüpiline ülesanne on ülesanne, mille lahendamine on täielikult või osaliselt automatiseeritud, ei tekita täitjatele raskusi ega nõua olulisi tööjõukulusid.
- Tootmisprotsess koosneb etappidest, etapid on jagatud jagamatuteks etappideks, mis on erineva ulatuse ja ulatusega tüüpilised ülesanded.
- Erinevatest tüüpilistest ülesannetest oleme jõudnud keerukate tehnoloogiliste ahelate ja tootmisprotsessi mitmetasandiliste mudeliteni, mida saab kirjeldada funktsionaalse IDEF0 mudeli või lihtsama tehnoloogilise kaardiga.
- Tehnoloogiline kaart kujutab endast tootmisprotsessi etappide ja etappide tabelit. Kõige tähtsam: kaart võimaldab näha kogu protsessi tervikuna, suurte tükkidena koos võimalusega neid detailiseerida.
- Tehnoloogilise kaardi põhjal on võimalik hinnata konkreetse toote etappide juurutamise vajadust, piiritleda vastutusalad, leppida kokku lepingud etappide sisenditel ja väljunditel ning täpsemalt hinnata ressursivajadust.
Järgmistes artiklites kirjeldame üksikasjalikumalt, milliseid tehnilisi vahendeid kasutatakse teatud tehnoloogiliste etappide rakendamiseks meie kaardil.
Artikli autorid:
- — Positive Technologiesi automatiseerimise (DevOps) juht
- - Asetäitja Positive Technologiesi automatiseerimisosakonna (DevOps) juhataja
Allikas: www.habr.com