Bildon:
Saluton al ĉiuj! Ni estas aŭtomatigaj inĝenieroj de la kompanio kaj ni subtenas la disvolviĝon de la produktoj de la kompanio: ni subtenas la tutan muntadon de la kompromiso de linio de kodo fare de programistoj ĝis la publikigo de finitaj produktoj kaj licencoj sur ĝisdatigaj serviloj. Neformale, ni nomiĝas DevOps-inĝenieroj. En ĉi tiu artikolo, ni volas paroli pri la teknologiaj stadioj de la programara produktada procezo, kiel ni vidas ilin kaj kiel ni klasifikas ilin.
De la materialo vi lernos pri la komplekseco de kunordigado de multprodukta evoluo, pri kio estas teknologia mapo kaj kiel ĝi helpas simpligi kaj reprodukti solvojn, kiuj estas la ĉefaj etapoj kaj paŝoj de la evoluprocezo, kiel estas la respondecaj kampoj. inter DevOps kaj teamoj en nia kompanio.
Pri Kaoso kaj DevOps
Mallonge, la koncepto de DevOps inkluzivas evoluajn ilojn kaj servojn, same kiel metodarojn kaj plej bonajn praktikojn por ilia uzo. Ni elstarigu la tutmondan la celo de la efektivigo de DevOps-ideoj en nia kompanio: ĉi tio estas konsekvenca redukto de la kosto de produktado kaj prizorgado de produktoj en kvantaj terminoj (homhoroj aŭ maŝinhoroj, CPU, RAM, Disko, ktp.). La plej facila kaj evidenta maniero redukti la ĝeneralan koston de disvolviĝo je la nivelo de la tuta kompanio estas minimumigante la koston de plenumado de tipaj seriaj taskoj en ĉiuj stadioj de produktado. Sed kio estas ĉi tiuj etapoj, kiel apartigi ilin de la ĝenerala procezo, el kiuj paŝoj ili konsistas?
Kiam firmao disvolvas unu produkton, ĉio estas pli-malpli klara: estas kutime komuna vojmapo kaj evoluskemo. Sed kion fari kiam la produktserio pligrandiĝas kaj estas pli da produktoj? Unuavide, ili havas similajn procezojn kaj muntajn liniojn, kaj komenciĝas la ludo "trovi X-diferencojn" en protokoloj kaj skriptoj. Sed kio se estas jam 5+ projektoj en aktiva disvolviĝo kaj subteno por pluraj versioj evoluigitaj dum pluraj jaroj estas postulata? Ĉu ni volas reuzi la maksimuman eblan nombron da solvoj en produktaj duktoj aŭ ĉu ni pretas elspezi monon por unika evoluo por ĉiu?
Kiel trovi ekvilibron inter unikeco kaj seriaj solvoj?
Ĉi tiuj demandoj ekestis antaŭ ni pli kaj pli ofte ekde 2015. La nombro da produktoj kreskis, kaj ni provis pligrandigi nian aŭtomatigan fakon (DevOps), kiu subtenis la muntajn liniojn de ĉi tiuj produktoj, al minimumo. Samtempe, ni volis reprodukti kiel eble plej multajn solvojn inter produktoj. Finfine, kial fari la samon en dek produktoj en malsamaj manieroj?
Direktoro pri Disvolviĝo: "Knaboj, ĉu ni povas iel taksi, kion DevOps faras por produktoj?"
Ni: "Ni ne scias, ni ne faris tian demandon, sed kiajn indikilojn oni devas konsideri?"
Direktoro pri Disvolviĝo: "Kiu scias! Pensu…”
Kiel en tiu fama filmo: "Mi estas en hotelo! .." - "Uh... Ĉu vi povas montri al mi la vojon?" Pripensinte, ni alvenis al la konkludo, ke ni unue devas decidi pri la finaj statoj de la produktoj; ĉi tio fariĝis nia unua celo.
Do, kiel vi analizas dekduon da produktoj kun sufiĉe grandaj teamoj de 10 ĝis 200 homoj kaj determinas mezureblajn metrikojn dum reproduktado de solvoj?
1:0 en favoro de Kaoso, aŭ DevOps sur la ŝultroj
Ni komencis per provo apliki IDEF0-diagramojn kaj diversajn komercajn procezajn diagramojn de la serio BPwin. La konfuzo komenciĝis post la kvina kvadrato de la sekva etapo de la sekva projekto, kaj ĉi tiuj kvadratoj por ĉiu projekto povas esti desegnitaj en la vosto de longa pitono sub 50+ paŝoj. Mi sentis malĝojon kaj volis hurli ĉe la luno - ĝenerale ne konvenis.
Tipaj produktaj taskoj
Modeligi produktadajn procezojn estas tre kompleksa kaj peniga laboro: vi devas kolekti, prilabori kaj analizi multajn datumojn de diversaj fakoj kaj produktaj ĉenoj. Vi povas legi pli pri tio en la artikolo "".
Kiam ni komencis modeligi nian produktadprocezon, ni havis specifan celon - transdoni al ĉiu dungito implikita en la disvolviĝo de la produktoj de nia kompanio, kaj al projektestroj:
- kiel produktoj kaj iliaj komponantoj, komencante de la kompromiso de linio de kodo, atingas la klienton en formo de instaliloj kaj ĝisdatigoj,
- kiaj rimedoj estas provizitaj por ĉiu etapo de produktado de produktoj,
- kiaj servoj estas implikitaj en ĉiu stadio,
- kiel la respondecaj kampoj por ĉiu stadio estas limigitaj,
- kiaj kontraktoj ekzistas ĉe la enirejo kaj eliro de ĉiu etapo.
Alklakante la bildon malfermos ĝin en plena grandeco.
Nia laboro en la kompanio estas dividita en plurajn funkciajn areojn. La direkto de la infrastrukturo okupiĝas pri la optimumigo de la funkciado de ĉiuj "feraj" rimedoj de la fako, kaj ankaŭ pri la aŭtomatigo de la disfaldiĝo de virtualaj maŝinoj kaj la medio sur ili. La direkto de monitorado provizas 24/7 servo-efikeckontrolon; ni ankaŭ provizas monitoradon kiel servon por programistoj. La laborflua direkto provizas teamojn per iloj por administri evoluajn kaj testajn procezojn, analizi la staton de la kodo kaj akiri analizojn pri projektoj. Kaj finfine, la webdev-direkto provizas la publikigon de eldonoj sur la ĝisdatigaj serviloj GUS kaj FLUS, kaj ankaŭ la licencadon de produktoj uzante la servon LicenseLab. Por subteni la produktaddukton, ni starigas kaj konservas multajn malsamajn helpservojn por programistoj (vi povas aŭskulti rakontojn pri kelkaj el ili en malnovaj renkontiĝoj: и). Ni ankaŭ disvolvas internajn aŭtomatigajn ilojn, inkluzive .
Dum la pasintaj kvin jaroj, nia laboro amasigis multajn samtipajn kaj rutinajn operaciojn, kaj niaj programistoj el aliaj fakoj ĉefe venas de la t.n. tipaj taskoj, kies solvo estas plene aŭ parte aŭtomatigita, ne kaŭzas malfacilaĵojn por prezentistoj kaj ne postulas signifajn kvantojn da laboro. Kune kun la gvidaj areoj, ni analizis tiajn taskojn kaj povis identigi individuajn kategoriojn de laboro, aŭ produktadaj paŝoj, la stadioj estis dividitaj en nedivideblajn ŝtupojn, kaj pluraj stadioj sumiĝas produktada proceza ĉeno.
La plej simpla ekzemplo de teknologia ĉeno estas la stadioj de muntado, deplojo kaj testado de ĉiu el niaj produktoj ene de la kompanio. Siavice, ekzemple, la konstrustadio konsistas el multaj apartaj tipaj paŝoj: elŝutado de fontoj de GitLab, preparado de dependencajoj kaj triaj bibliotekoj, unutestado kaj statika kodanalizo, ekzekuti konstruskripton sur GitLab CI, publikigado de artefaktoj en la deponejo sur Artefarita kaj generacio de eldonnotoj per nia interna ChangelogBuilder-ilo.
Vi povas legi pri tipaj DevOps-taskoj en niaj aliaj artikoloj pri Habré: ""Kaj"".
Formiĝas multaj tipaj produktĉenoj procezo de fabrikado. La norma aliro al priskribado de procezoj devas uzi funkciajn IDEF0-modelojn.
Ekzemplo de modeligado de produktada CI-procezo
Ni pruntis specialan atenton al la disvolviĝo de normaj projektoj por kontinua integriga sistemo. Tio ebligis atingi la unuigon de projektoj, reliefigante la tn liberigi konstruskemon kun promocioj.
Jen kiel ĝi funkcias. Ĉiuj projektoj aspektas tipaj: ili inkluzivas la agordon de asembleoj, kiuj falas en la momentan deponejon ĉe Artifactory, post kio ili estas deplojitaj kaj testitaj sur testbenkoj, kaj poste promociitaj al la eldondeponejo. La servo Artifactory estas ununura distribupunkto por ĉiuj konstruaj artefaktoj inter teamoj kaj aliaj servoj.
Se ni multe simpligas kaj ĝeneraligas nian eldonskemon, tiam ĝi inkluzivas la sekvajn paŝojn:
- transplatforma produkta asembleo,
- deplojo al testbenkoj,
- farante funkciajn kaj aliajn provojn,
- antaŭenigante provitajn konstruaĵojn por liberigi deponejojn ĉe Artifactory,
- publikigo de eldono konstruas sur ĝisdatigaj serviloj,
- livero de asembleoj kaj ĝisdatigoj al produktado,
- lanĉante la instaladon kaj ĝisdatigon de la produkto.
Ekzemple, konsideru la teknologian modelon de ĉi tiu tipa eldonskemo (ĉi-poste simple Modelo) en la formo de funkcia IDEF0-modelo. Ĝi reflektas la ĉefajn stadiojn de nia CI-procezo. IDEF0-modeloj uzas la tn ICOM-notacio (Enigo-Kontrolo-Eligo-Mekanismo) priskribi kiajn rimedojn estas uzataj en ĉiu etapo, surbaze de kiaj reguloj kaj postuloj funkcias, kio estas la eligo, kaj kiaj mekanismoj, servoj aŭ homoj efektivigas apartan etapon.
Alklakante la bildon malfermos ĝin en plena grandeco.
Kiel regulo, estas pli facile malkomponi kaj detali la priskribon de procezoj en funkciaj modeloj. Sed kiam la nombro da elementoj kreskas, pli kaj pli malfacilas kompreni ion en ili. Sed en reala evoluo ekzistas ankaŭ helpaj etapoj: monitorado, atestado de produktoj, aŭtomatigo de laborprocezoj kaj aliaj. Estas pro la skalproblemo ke ni forlasis ĉi tiun priskribon.
Naskiĝo de Espero
En unu libro, ni renkontis malnovajn sovetiajn mapojn priskribantajn teknologiajn procezojn (kiuj, cetere, estas ankoraŭ uzataj hodiaŭ ĉe multaj ŝtataj entreprenoj kaj universitatoj). Atendu, atendu, ĉar ni ankaŭ havas laborfluon!.. Estas etapoj, rezultoj, metrikoj, postuloj, indikiloj, ktp kaj tiel plu... Kial ne provi apliki flufoliojn ankaŭ al niaj produktaj duktoj? Estis sento: “Jen! Ni trovis la ĝustan fadenon, estas tempo bone tiri ĝin!
En simpla tabelo, ni decidis registri produktojn per kolumnoj, kaj teknologiaj etapoj kaj produktaj dukto paŝoj laŭ vicoj. Mejloŝtonoj estas io granda, kiel produkta konstrupaŝo. Kaj paŝoj estas io pli malgrandaj kaj pli detalaj, kiel la paŝo de elŝuti la fontkodon al la konstruservilo aŭ la paŝo de kompili la kodon.
Ĉe la intersekcoj de la vicoj kaj kolumnoj de la mapo, ni demetas la statusojn por specifa stadio kaj produkto. Por statusoj, aro de ŝtatoj estis difinita:
- Ne estas datumoj - aŭ netaŭga. Necesas analizi la postulon pri etapo en la produkto. Aŭ la analizo jam estas farita, sed la etapo nuntempe ne estas bezonata aŭ ne estas ekonomie pravigita.
- Prokrastita - aŭ ne grava en la momento. Etapo en la dukto necesas, sed ne ekzistas fortoj por efektivigo ĉi-jare.
- Planita. La stadio estas planita por efektivigo ĉi-jare.
- Efektivigita. La stadio en la dukto estas efektivigita en la bezonata volumo.
Plenigi la tabelon komenciĝis projekto post projekto. Unue, la stadioj kaj paŝoj de unu projekto estis klasifikitaj kaj iliaj statusoj estis registritaj. Tiam ili prenis la sekvan projekton, riparis la statusojn en ĝi kaj aldonis la etapojn kaj paŝojn, kiuj mankis en antaŭaj projektoj. Kiel rezulto, ni ricevis la stadiojn kaj paŝojn de nia tuta produktaddukto kaj iliajn statusojn en specifa projekto. Rezultis io simila al la produkta dukto-kompetenta matrico. Ni nomis tian matricon teknologia mapo.
Helpe de la teknologia mapo ni metrologie prudente kunordigas kun la teamoj la laborplanojn por la jaro kaj la celojn, kiujn ni volas atingi kune: kiujn etapojn ni aldonas ĉi-jare al la projekto, kaj kiujn ni lasas por poste. Ankaŭ, en la kurso de laboro, ni povas havi plibonigojn en la etapoj kiujn ni kompletigis por nur unu produkto. Poste ni vastigas nian mapon kaj enkondukas ĉi tiun plibonigon kiel etapon aŭ novan paŝon, tiam ni analizas por ĉiu produkto kaj ekscias la fareblecon reprodukti la plibonigon.
Ili povas kontraŭstari nin: “Ĉio ĉi tio estas, kompreneble, bona, nur kun la tempo la nombro da paŝoj kaj stadioj fariĝos malpermese granda. Kiel esti?
Ni enkondukis normajn kaj sufiĉe kompletajn priskribojn de postuloj por ĉiu etapo kaj paŝo, por ke ili estu komprenataj de ĉiuj en la kompanio sammaniere. Kun la tempo, ĉar plibonigoj estas enkondukitaj, paŝo povas esti absorbita en alian stadion aŭ paŝon, kaj tiam ili "kolapsos". Samtempe, ĉiuj postuloj kaj teknologiaj nuancoj konvenas al la postuloj de la ĝeneraliganta etapo aŭ paŝo.
Kiel taksi la efikon de reproduktado de solvoj? Ni uzas ekstreme simplan aliron: ni atribuas la komencajn kapitalkostojn por la efektivigo de nova etapo al ĉiujaraj ĝeneralaj produktokostoj, kaj poste dividas per ĉiuj dum reproduktado.
Partoj de la evoluo jam estas montritaj kiel mejloŝtonoj kaj paŝoj sur la mapo. Ni povas influi la redukton de la kosto de la produkto per la enkonduko de aŭtomatigo por tipaj stadioj. Post tio, ni konsideras la ŝanĝojn en kvalitaj trajtoj, kvantaj metrikoj kaj la profiton ricevita de la teamoj (en homhoroj aŭ maŝinhoroj de ŝparado).
Teknologia mapo de la produktada procezo
Se ni faros ĉiujn niajn stadiojn kaj paŝojn, kodi ilin per etikedoj kaj pligrandigi ilin en unu ĉenon, tiam ĝi estos tre longa kaj nekomprenebla (nur la "python-vosto", pri kiu ni parolis komence de la artikolo) :
[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]Ĉi tiuj estas la stadioj de konstruado de produktoj [Konstruo], deplojado de ili por testi servilojn [Deploji], testado [Testo], promocio de konstruoj por liberigi deponejojn bazitajn sur la rezultoj de testado [Promoti], generado kaj publikigado de licencoj [Licenco], eldonado [ Publiki] sur la GUS ĝisdatiga servilo kaj livero al FLUS ĝisdatigaj serviloj, instalado kaj ĝisdatigo de produktokomponentoj sur la infrastrukturo de la kliento uzante Product Configuration Management [Instali], same kiel kolekto de telemetrio [Telemetrio] de instalitaj produktoj.
Aldone al ili, apartaj stadioj povas esti distingitaj: infrastruktura statomonitorado [InfMonitoring], fontkoda versio [SourceCodeControl], konstrumedio-preparo [Prepari], projekt-administrado [Laborfluo], provizi teamojn per komunikadaj iloj [Komuniko], produkta atestado [ Atestado] kaj certigi memsufiĉon de CI-procezoj [CISelfSufficiency] (ekzemple, sendependeco de asembleoj de la Interreto). Dekoj da paŝoj en niaj procezoj eĉ ne estos konsiderataj, ĉar ili estas tre specifaj.
Estos multe pli facile kompreni kaj rigardi la tutan produktadprocezon, se ĝi estas prezentita en la formo teknologia mapo; ĉi tio estas tabelo en kiu la individuaj produktadstadioj kaj malkomponitaj ŝtupoj de la Modelo estas skribitaj en vicoj, kaj en kolumnoj priskribo de kio estas farita en ĉiu stadio aŭ paŝo. La ĉefa emfazo estas metita sur la rimedoj, kiuj provizas ĉiun etapon, kaj la limado de respondecaj kampoj.
La mapo por ni estas speco de klasigilo. Ĝi reflektas la ĉefajn teknologiajn partojn de la produktado de produktoj. Danke al ĝi, nia aŭtomatiga teamo fariĝis pli facile interagi kun programistoj kaj kune plani la efektivigon de aŭtomatigaj etapoj, kaj kompreni, kiaj laborkostoj kaj rimedoj (homaj kaj aparataro) estos postulataj por tio.
Ene de nia kompanio, la mapo estas aŭtomate generita el la ŝablono jinja kiel regula HTML-dosiero, kaj poste alŝutita al la servilo de GitLab Pages. Ekrankopio kun ekzemplo de plene generita mapo povas esti rigardita .
Alklakante la bildon malfermos ĝin en plena grandeco.
Mallonge, la teknologia mapo estas ĝeneraligita bildo de la produktada procezo, kiu reflektas klare klasifikitajn blokojn kun tipa funkcieco.
Strukturo de nia vojmapo
La mapo konsistas el pluraj partoj:
- Titolo areo - jen ĝenerala priskribo de la mapo, bazaj konceptoj estas enkondukitaj, la ĉefaj rimedoj kaj rezultoj de la produktada procezo estas difinitaj.
- Panelo - ĉi tie vi povas kontroli la montradon de datumoj por individuaj produktoj, resumo de la efektivigitaj etapoj kaj paŝoj ĝenerale por ĉiuj produktoj estas provizita.
- Teknologia mapo - tabela priskribo de la teknologia procezo. Sur la mapo:
- ĉiuj etapoj, paŝoj kaj iliaj kodoj estas donitaj;
- mallongaj kaj kompletaj priskriboj de la stadioj estas donitaj;
- la enigresursoj kaj servoj uzataj en ĉiu stadio estas indikitaj;
- la rezultoj de ĉiu etapo kaj aparta paŝo estas indikitaj;
- la areo de respondeco por ĉiu etapo kaj paŝo estas indikita;
- la teknikaj rimedoj, kiel HDD (SSD), RAM, vCPU, kaj la laborhoroj necesaj por subteni la laboron en ĉi tiu etapo, ambaŭ en la nuna momento - fakto, kaj en la estonteco - plano, estis determinitaj;
- por ĉiu produkto, estas indikite kiuj teknologiaj stadioj aŭ paŝoj por ĝi estis efektivigitaj, planitaj por efektivigo, senrilataj aŭ ne efektivigitaj.
Decidado surbaze de la teknologia mapo
Post ekzamenado de la mapo, eblas fari iujn agojn - depende de la rolo de la dungito en la firmao (disvolva administranto, produktestro, programisto aŭ testilo):
- kompreni, kiaj stadioj mankas en reala produkto aŭ projekto, kaj taksi la bezonon de ilia efektivigo;
- limigi la respondecajn kampojn inter pluraj fakoj se ili laboras en malsamaj stadioj;
- interkonsenti pri kontraktoj ĉe la enirejoj kaj eliroj de la stadioj;
- integru vian etapon de laboro en la ĝeneralan evoluprocezon;
- pli precize taksi la bezonon de rimedoj, kiuj provizas ĉiun el la etapoj.
Resumante ĉion supre
La vojigo estas multflanka, etendebla kaj facile konservebla. Estas multe pli facile disvolvi kaj konservi priskribon de procezoj en ĉi tiu formo ol en strikta akademia IDEF0-modelo. Krome, tabela priskribo estas pli simpla, pli konata kaj pli bone strukturita ol funkcia modelo.
Por la teknika efektivigo de la paŝoj, ni havas specialan internan ilon CrossBuilder - tavola ilo inter CI-sistemoj, servoj kaj infrastrukturo. La programisto ne bezonas tranĉi sian biciklon: en nia CI-sistemo, sufiĉas ruli unu el la skriptoj (la tiel nomata tasko) de la ilo CrossBuilder, kiu ekzekutos ĝin ĝuste, konsiderante la funkciojn de nia infrastrukturo. .
Rezultoj
La artikolo montriĝis sufiĉe longa, sed ĉi tio estas neevitebla kiam oni priskribas la modeladon de kompleksaj procezoj. Fine mi ŝatus mallonge ripari niajn ĉefajn ideojn:
- La celo efektivigi DevOps-ideojn en nia kompanio estas konstante redukti la koston de produktado kaj prizorgado de la produktoj de la kompanio en kvantaj terminoj (homhoroj aŭ maŝinhoroj, vCPU, RAM, Disko).
- La maniero redukti la totalan koston de evoluo estas minimumigi la koston de plenumado de tipaj seriaj taskoj: stadioj kaj paŝoj de la teknologia procezo.
- Tipa tasko estas tasko, kies solvo estas plene aŭ parte aŭtomatigita, ne kaŭzas malfacilaĵojn por prezentistoj kaj ne postulas signifajn laborkostojn.
- La produktada procezo konsistas el etapoj, la etapoj estas dividitaj en nedivideblajn paŝojn, kiuj estas tipaj taskoj de malsama skalo kaj amplekso.
- De malsimilaj tipaj taskoj, ni venis al kompleksaj teknologiaj ĉenoj kaj plurnivelaj modeloj de la produktada procezo, kiuj povas esti priskribitaj per funkcia IDEF0-modelo aŭ pli simpla teknologia mapo.
- La teknologia mapo estas tabela reprezentado de la stadioj kaj ŝtupoj de la produktada procezo. La plej grava afero: la mapo permesas vidi la tutan procezon en ĝia tuteco, en grandaj pecoj kun la ebleco detali ilin.
- Surbaze de la teknologia mapo, eblas taksi la bezonon enkonduki stadiojn en aparta produkto, kontuzi areojn de respondeco, konsenti pri kontraktoj ĉe la enigaĵoj kaj eliroj de stadioj, kaj pli precize taksi la bezonon de rimedoj.
En la sekvaj artikoloj, ni priskribos pli detale, kiajn teknikajn ilojn oni uzas por efektivigi iujn teknologiajn stadiojn sur nia mapo.
Artikolo-aŭtoroj:
- — Estro de Aŭtomatigo (DevOps) ĉe Positive Technologies
- - Deputito Estro de Aŭtomatiga Sekcio (DevOps) ĉe Positive Technologies
fonto: www.habr.com