ProHoster > Blog > administratë > Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Foto: Unsplash

Përshëndetje të gjithëve! Ne jemi inxhinierë automatizimi nga kompania Teknologjitë pozitive Ne mbështesim zhvillimin e produkteve të kompanisë: ne mbështesim të gjithë procesin e ndërtimit, nga zhvilluesit që kryejnë një rresht të vetëm kodi deri te publikimi i produkteve të përfunduara dhe licencave në serverat e përditësimit. Ne quhemi informalisht inxhinierë DevOps. Në këtë artikull, do të diskutojmë fazat teknologjike të procesit të prodhimit të softuerëve, si i shohim ato dhe si i klasifikojmë ato.

Ky artikull do të shpjegojë kompleksitetet e koordinimit të zhvillimit të shumë produkteve, çfarë është një hartë procesesh dhe si ndihmon në organizimin dhe replikimin e zgjidhjeve, fazat dhe hapat kryesorë të procesit të zhvillimit, si dhe si ndahen përgjegjësitë midis DevOps dhe ekipeve brenda kompanisë sonë.

Rreth Kaosit dhe DevOps

Le të theksojmë shkurtimisht se koncepti i DevOps përfshin mjete dhe shërbime zhvillimi, si dhe metodologji dhe praktikat më të mira për përdorimin e tyre. Le të nxjerrim në pah aspektin global qëllimi Përfitimet e zbatimit të ideve DevOps në kompaninë tonë janë një ulje e vazhdueshme e kostos së prodhimit dhe mbështetjes së produkteve në terma sasiorë (orë pune ose orë makinerie, CPU, RAM, disk, etj.). Mënyra më e thjeshtë dhe më e dukshme për të ulur koston e përgjithshme të zhvillimit në nivel të të gjithë kompanisë është duke minimizuar koston e kryerjes së detyrave tipike seriale në të gjitha fazat e prodhimit. Por cilat janë këto faza, si mund të dallohen nga procesi i përgjithshëm dhe nga cilat hapa përbëhen ato?

Kur një kompani zhvillon një produkt të vetëm, gjithçka është pak a shumë e qartë: zakonisht ekziston një plan i përbashkët zhvillimi dhe një plan zhvillimi. Por çfarë ndodh kur linja e produkteve zgjerohet dhe shfaqen më shumë produkte? Në shikim të parë, të gjitha kanë procese dhe linja montimi të ngjashme, dhe fillon një lojë "gjeni ndryshimet X" në regjistra dhe skripte. Por çfarë ndodh nëse tashmë ka mbi 5 projekte në zhvillim aktiv dhe kërkohet mbështetje për versione të shumëfishta të zhvilluara gjatë disa viteve? A duam të ripërdorim sa më shumë zgjidhje të jetë e mundur në të gjitha linjat tona të produkteve, apo jemi të gatshëm të investojmë në zhvillim unik për secilën?

Si të gjesh një ekuilibër midis zgjidhjeve unike dhe seriale?

Këto pyetje filluan të lindnin me frekuencë gjithnjë e në rritje duke filluar nga viti 2015. Numri i produkteve po rritej, por ne e mbajtëm departamentin tonë të automatizimit (DevOps), i cili mbështeti rrjedhën e ndërtimit për këto produkte, në minimum. Në të njëjtën kohë, ne donim të replikonim sa më shumë zgjidhje të ishte e mundur në të gjitha produktet. Në fund të fundit, pse të bëjmë të njëjtën gjë në dhjetë mënyra të ndryshme?

Drejtor i Zhvillimit"Djema, a ka ndonjë mënyrë se si mund të vlerësojmë se çfarë bën DevOps për produktet?"

Ne"Nuk e dimë, nuk ia kemi bërë vetes këtë pyetje, por cilët tregues duhen marrë parasysh?"

Drejtor i Zhvillimit"Kush e di! Mendo pak..."

Si nĂ« atĂ« filmin e famshĂ«m: "Duhet tĂ« shkoj nĂ« hotel!.." — "Ëh... A mund tĂ« mĂ« tregosh rrugĂ«n?" Pas disa mendimesh, arritĂ«m nĂ« pĂ«rfundimin se sĂ« pari duhej tĂ« pĂ«rcaktonim gjendjen pĂ«rfundimtare tĂ« produkteve; ky u bĂ« qĂ«llimi ynĂ« i parĂ«.

Pra, si i analizoni një duzinë produktesh me ekipe mjaft të mëdha prej 10 deri në 200 personash dhe përcaktoni metrika të matshme për replikimin e zgjidhjeve?

1:0 në favor të Kaosit, ose DevOps në shpatulla

Ne filluam duke u përpjekur të përdornim diagrame IDEF0 dhe diagrame të ndryshme të proceseve të biznesit nga seria BPwin. Konfuzioni filloi pas katrorit të pestë të fazës tjetër të projektit të ardhshëm, dhe për secilin projekt, këto katrorë mund të vizatoheshin si bishti i një skripti të gjatë Python me mbi 50 hapa. U ndjeva i trishtuar dhe doja të ulërija në hënë - thjesht nuk funksionoi.

Detyra tipike të prodhimit

Modelimi i proceseve të prodhimit është një detyrë shumë komplekse dhe e mundimshme: kërkon mbledhjen, përpunimin dhe analizimin e një mori të dhënash nëpër departamente dhe zinxhirë të ndryshëm prodhimi. Mund të lexoni më shumë rreth kësaj në artikullin "Modelimi i proceseve të prodhimit në një kompani IT'.

Kur filluam modelimin e procesit tonë të prodhimit, kishim një qëllim specifik në mendje: t'u komunikonim çdo punonjësi të përfshirë në zhvillimin e produkteve të kompanisë sonë dhe menaxherëve të projekteve:

  • si produktet dhe pĂ«rbĂ«rĂ«sit e tyre, duke filluar nga kryerja e njĂ« rreshti kodi, arrijnĂ« te klienti nĂ« formĂ«n e instaluesve dhe pĂ«rditĂ«simeve,
  • çfarĂ« burimesh ofrohen nĂ« secilĂ«n fazĂ« tĂ« prodhimit tĂ« produktit,
  • cilat shĂ«rbime pĂ«rfshihen nĂ« secilĂ«n fazĂ«,
  • si pĂ«rcaktohen fushat e pĂ«rgjegjĂ«sisĂ« pĂ«r secilĂ«n fazĂ«,
  • çfarĂ« kontratash ekzistojnĂ« nĂ« hyrje dhe dalje tĂ« secilĂ«s fazĂ«.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Klikoni mbi imazhin për ta hapur atë në madhësi të plotë.

Puna jonë brenda kompanisë është e ndarë në disa fusha funksionale. Zona e Infrastrukturës optimizon funksionimin e të gjitha burimeve harduerike brenda departamentit, si dhe automatizon vendosjen e makinave virtuale dhe mjediseve të tyre. Zona e Monitorimit siguron monitorim të disponueshmërisë së shërbimit 24/7; ne gjithashtu ofrojmë monitorim si shërbim për zhvilluesit. Zona e Fluksit të Punës u ofron ekipeve mjete për menaxhimin e proceseve të zhvillimit dhe testimit, analizimin e statusit të kodit dhe marrjen e analizave të projektit. Së fundmi, zona Webdev siguron publikimin e lëshimeve në serverat e përditësimit GUS dhe FLUS, si dhe licencimin e produkteve duke përdorur shërbimin LicenseLab. Për të mbështetur rrjedhën e prodhimit, ne konfigurojmë dhe mirëmbajmë një sërë shërbimesh ndihmëse për zhvilluesit (mund të dëgjoni histori rreth disa prej tyre në takimet e kaluara: Op!DevOps! 2016 О Op!DevOps! 2017). Ne gjithashtu zhvillojmë mjete automatizimi të brendshëm, duke përfshirë zgjidhje me burim të hapur.

Gjatë pesë viteve të fundit, shumë operacione të ngjashme dhe rutinë janë grumbulluar në punën tonë, dhe nga zhvilluesit tanë në departamente të tjera, kryesisht të ashtuquajturat detyra tipike, zgjidhja e së cilës është plotësisht ose pjesërisht e automatizuar, nuk paraqet vështirësi për interpretuesit dhe nuk kërkon sasi të konsiderueshme pune. Së bashku me specialistë kryesorë, ne analizuam detyra të tilla dhe ishim në gjendje të identifikonim kategori specifike të punës, ose fazat e prodhimit, fazat u ndanë në hapa të pandashëm, dhe disa faza përbëhen nga zinxhiri teknologjik i prodhimit.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Shembulli më i thjeshtë i një rrjedhe procesi është fazat e ndërtimit, vendosjes dhe testimit të secilit prej produkteve tona brenda kompanisë. Faza e ndërtimit, për shembull, përbëhet nga shumë hapa individualë, standardë: marrja e kodit burimor nga GitLab, përgatitja e varësive dhe bibliotekave të palëve të treta, testimi i njësive dhe analiza e kodit statik, ekzekutimi i një skripti ndërtimi në GitLab CI, publikimi i artefakteve në depon Artifactory dhe gjenerimi i shënimeve të lëshimit duke përdorur mjetin tonë të brendshëm, ChangelogBuilder.

Mund të lexoni rreth detyrave tipike DevOps në artikujt tanë të tjerë në Habr:Përvoja Personale: Si Duket Sistemi Ynë i Integrimit të Vazhdueshëm"Dhe"Automatizimi i proceseve të zhvillimit: si i zbatuam idetë e DevOps në Positive Technologies'.

Një mori zinxhirësh tipikë prodhimi formohen procesi i prodhimitQasja standarde për përshkrimin e proceseve është përdorimi i modeleve funksionale IDEF0.

Një shembull i modelimit të një procesi prodhimi CI

Ne i kushtuam vëmendje të veçantë zhvillimit të projekteve standarde për sistemin e integrimit të vazhdueshëm. Kjo na lejoi të arrinim unifikimin e projekteve, duke nxjerrë në pah të ashtuquajturin skemë ndërtimi lëshimi me promovime.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Ja se si funksionon. Të gjitha projektet janë standarde: ato përfshijnë konfigurime ndërtimi që vendosen në një depo të pamjeve të çastit në Artifactory, pastaj vendosen dhe testohen në platformat e testimit dhe më pas promovohen në depon e publikimit. Artifactory shërben si një pikë e vetme shpërndarjeje për të gjitha objektet e ndërtimit midis ekipeve dhe shërbimeve të tjera.

Për ta thjeshtuar dhe përgjithësuar shumë planin tonë të publikimit, ai përfshin fazat e mëposhtme:

  • montimi i produkteve ndĂ«rplatformĂ«,
  • vendosja nĂ« stendat e testimit,
  • kryerjen e testeve funksionale dhe tĂ« tjera,
  • promovimi i ndĂ«rtimeve tĂ« testuara pĂ«r tĂ« publikuar depo nĂ« Artifactory,
  • publikimi i versioneve tĂ« reja pĂ«r tĂ« pĂ«rditĂ«suar serverat,
  • dorĂ«zimin e ndĂ«rtimeve dhe pĂ«rditĂ«simeve nĂ« prodhim,
  • Nisja e instalimit dhe pĂ«rditĂ«simi i produktit.

Le të shohim një shembull të një modeli teknologjik të kësaj skeme tipike lëshimi (në tekstin e mëtejmë thjesht i referuar si Modeli) në formën e një modeli funksional IDEF0. Ai pasqyron fazat kryesore të procesit tonë CI. Modelet IDEF0 përdorin të ashtuquajturin Notacioni i ICOM-it (Mekanizmi i Hyrjes-Kontrollit-Daljes) për të përshkruar se cilat burime përdoren në secilën fazë, cilat rregulla dhe kërkesa qeverisin punën, cili është rezultati dhe cilat mekanizma, shërbime ose njerëz zbatojnë një fazë specifike.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Klikoni mbi imazhin për ta hapur atë në madhësi të plotë.

Modelet funksionale zakonisht lehtësojnë zbërthimin dhe përshkrimet e hollësishme të proceseve. Megjithatë, ndërsa numri i elementëve rritet, të kuptuarit e tyre bëhet gjithnjë e më i vështirë. Dhe në zhvillimin e botës reale, ekzistojnë edhe faza ndihmëse: monitorimi, certifikimi i produktit, automatizimi i rrjedhës së punës dhe të tjera. Ishte pikërisht për shkak të problemit të shkallëzueshmërisë që ne e braktisëm këtë lloj përshkrimi.

Lindja e Shpresës

Në një libër, hasëm disa grafikë të vjetër të rrjedhës së procesit sovjetik (të cilët, meqë ra fjala, përdoren ende sot në shumë ndërmarrje dhe universitete shtetërore). Prit, prit, edhe ne kemi një rrjedhë procesi! Ka faza, rezultate, metrika, kërkesa, tregues e kështu me radhë... Pse të mos provojmë të aplikojmë grafikë procesesh në linjat tona të prodhimit? Ndjehesha sikur, "Ja ku është! E kemi gjetur fillin e duhur; është koha ta vazhdojmë vërtet!"

Në një tabelë të thjeshtë, vendosëm të regjistronim produktet në kolona dhe fazat dhe hapat e procesit të rrjedhës së produktit në rreshta. Fazat janë diçka e madhe, siç është një hap i montimit të produktit. Hapat janë diçka më e vogël dhe më e detajuar, siç është shkarkimi i kodit burimor në një server ndërtimi ose përpilimi i kodit.

Në kryqëzimet e rreshtave dhe kolonave të hartës, ne caktuam statuse për faza dhe produkte specifike. Ne përcaktuam një sërë gjendjesh për këto statuse:

  1. Nuk ka tĂ« dhĂ«na — ose Ă«shtĂ« e papraktike. Nevojitet njĂ« analizĂ« e kĂ«rkesĂ«s sĂ« produktit pĂ«r kĂ«tĂ« fazĂ«. Ose analiza Ă«shtĂ« kryer tashmĂ«, por faza aktualisht Ă«shtĂ« e panevojshme ose nuk Ă«shtĂ« ekonomikisht e realizueshme.
  2. ShtyrĂ« — ose nuk Ă«shtĂ« aktualisht e rĂ«ndĂ«sishme. Faza e tubacionit Ă«shtĂ« e nevojshme, por nuk ka kapacitet pĂ«r ta zbatuar atĂ« kĂ«tĂ« vit.
  3. PlanifikuarKjo fazë është planifikuar të zbatohet këtë vit.
  4. ZbatuarFaza në tubacion zbatohet në vëllimin e kërkuar.

Ne filluam të plotësojmë tabelën projekt pas projekti. Së pari, klasifikuam fazat dhe hapat e një projekti dhe regjistruam statusin e tyre. Pastaj morëm projektin tjetër, regjistruam statusin e tij dhe shtuam çdo fazë dhe hap që mungonte nga projektet e mëparshme. Rezultati përfundimtar ishin fazat dhe hapat e të gjithë tubacionit tonë të prodhimit dhe statusin e tyre për një projekt specifik. Rezultati ishte diçka që i ngjante një matrice kompetencash të tubacionit të produkteve. Ne e quajtëm këtë matricë hartë procesi.

Duke përdorur hartën e procesit, ne koordinohemi me ekipet, bazuar në provat metrologjike, planet vjetore të punës dhe objektivat që duam të arrijmë së bashku: cilat faza do t'i shtojmë projektit këtë vit dhe cilat do t'i shtyjmë. Gjithashtu, ndërsa punojmë, mund të zbulojmë përmirësime në fazat që kemi përfunduar vetëm për një produkt. Pastaj e zgjerojmë hartën tonë dhe e përfshijmë këtë përmirësim si një fazë ose një hap të ri, pastaj kryejmë një analizë për secilin produkt dhe përcaktojmë fizibilitetin e përsëritjes së përmirësimit.

Dikush mund tĂ« kundĂ«rshtojĂ«: "Sigurisht, e gjithĂ« kjo Ă«shtĂ« mirĂ« dhe e mirĂ«, por me kalimin e kohĂ«s numri i hapave dhe fazave do tĂ« bĂ«het jashtĂ«zakonisht i madh. ÇfarĂ« duhet tĂ« bĂ«jmĂ«?"

Ne kemi prezantuar përshkrime standarde dhe gjithëpërfshirëse të kërkesave për secilën fazë dhe hap për të siguruar që ato të kuptohen në mënyrë të qëndrueshme në të gjithë kompaninë. Me kalimin e kohës, ndërsa zbatohen përmirësimet, një hap mund të përthithet në një fazë ose hap tjetër, duke rezultuar në një "kolaps". Në këtë rast, të gjitha kërkesat dhe nuancat teknologjike integrohen në kërkesat e fazës ose hapit mbizotërues.

Si e vlerësojmë ndikimin e replikimit të zgjidhjeve? Ne përdorim një qasje shumë të thjeshtë: përfshijmë kostot fillestare të kapitalit për zbatimin e një faze të re në kostot e përgjithshme vjetore të produktit dhe më pas i ndajmë ato midis të gjithëve gjatë replikimit.

Fazat dhe hapat e zhvillimit janë hartëzuar tashmë. Ne mund të ulim kostot e produktit duke zbatuar automatizimin për fazat tipike. Pastaj llogarisim ndryshimet në karakteristikat e cilësisë, metrikat sasiore dhe fitimet e ekipeve (në terma të kursimeve në orë pune ose orë pune në makinë).

Harta teknologjike e procesit të prodhimit

Nëse i marrim të gjitha fazat dhe hapat tanë, i kodojmë me etiketa dhe i shpalosim në një zinxhir të vetëm, do të rezultonte shumë i gjatë dhe i pakuptueshëm (pikërisht i njëjti "bisht Python" për të cilin folëm në fillim të artikullit):

[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]

Këto janë fazat e montimit të produkteve [Ndërtimi], vendosja e tyre në serverat e testimit [Zhvendosja], testimi [Testimi], promovimi i ndërtimeve për të lëshuar depo bazuar në rezultatet e testimit [Promovimi], gjenerimi dhe publikimi i licencave [Licenca], publikimi [Publikimi] në serverin e përditësimit GUS dhe dorëzimi në serverat e përditësimit FLUS, instalimi dhe përditësimi i komponentëve të produktit në infrastrukturën e klientit duke përdorur Menaxhimin e Konfigurimit të Produkteve [Instalimi], si dhe mbledhja e telemetrisë [Telemetria] nga produktet e instaluara.

Përveç këtyre, ne mund të identifikojmë fazat individuale: monitorimin e infrastrukturës [InfMonitoring], kontrollin e versionit të kodit burimor [SourceCodeControl], përgatitjen e mjedisit të ndërtimit [Prepare], menaxhimin e projektit [Workflow], pajisjen e ekipeve me mjete komunikimi [Communication], certifikimin e produktit [Certification] dhe sigurimin e vetëmjaftueshmërisë së proceseve CI [CISelfSufficiency] (për shembull, sigurimin që ndërtimet janë të pavarura nga interneti). Ne as nuk do të shqyrtojmë dhjetëra hapa në proceset tona, pasi ato janë shumë specifike.

Do të jetë shumë më e lehtë të kuptoni dhe rishikoni të gjithë procesin e prodhimit nëse e imagjinoni si hartë teknologjikeKjo është një tabelë në të cilën fazat individuale të prodhimit dhe hapat e dekompozuar të Modelit renditen në rreshta, dhe kolonat përshkruajnë se çfarë bëhet në secilën fazë ose hap. Fokusi kryesor është në burimet që mbështesin secilën fazë dhe përcaktimin e fushave të përgjegjësisë.

Për ne, harta është një lloj klasifikuesi. Ajo pasqyron komponentët kryesorë teknologjikë të prodhimit të produktit. Falë saj, ekipi ynë i automatizimit është ndjerë më rehat duke bashkëpunuar me zhvilluesit dhe duke planifikuar së bashku zbatimin e fazave të automatizimit, si dhe duke kuptuar kostot e punës dhe burimet (njerëzore dhe harduerike) të kërkuara.

Brenda kompanisĂ« sonĂ«, harta gjenerohet automatikisht nga njĂ« shabllon Jinja si njĂ« skedar i rregullt HTML dhe mĂ« pas ngarkohet nĂ« serverin GitLab Pages. Mund tĂ« shihet njĂ« pamje e ekranit e njĂ« harte tĂ« gjeneruar plotĂ«sisht. ĐżĐŸ ссылĐșĐ”.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Klikoni mbi imazhin për ta hapur atë në madhësi të plotë.

Shkurt, një diagram rrjedhës i procesit është një pamje e përgjithësuar e procesit të prodhimit, i cili pasqyron blloqe të klasifikuara qartë me funksionalitet tipik.

Struktura e hartës sonë të procesit

Harta përbëhet nga disa pjesë:

  1. Zona e kokës - Këtu ndodhet përshkrimi i përgjithshëm i hartës, prezantohen konceptet themelore dhe përcaktohen burimet dhe rezultatet kryesore të procesit të prodhimit.
  2. Paneli i kontrollit - Këtu mund të menaxhoni shfaqjen e të dhënave për produktet individuale, ofrohet një përmbledhje e fazave dhe hapave të përfunduar në përgjithësi për të gjitha produktet.
  3. Një diagram rrjedhës i procesit është një përshkrim tabelar i një procesi teknologjik. Grafiku tregon:
    • jepen tĂ« gjitha fazat, hapat dhe kodet e tyre;
    • jepen pĂ«rshkrime tĂ« shkurtra dhe tĂ« plota tĂ« fazave;
    • tregohen burimet hyrĂ«se dhe shĂ«rbimet e pĂ«rdorura nĂ« secilĂ«n fazĂ«;
    • rezultatet e secilĂ«s fazĂ« dhe hap individual tregohen;
    • tregohet fusha e pĂ«rgjegjĂ«sisĂ« pĂ«r secilĂ«n fazĂ« dhe hap;
    • JanĂ« identifikuar burimet teknike, tĂ« tilla si HDD (SSD), RAM, vCPU dhe orĂ«t e punĂ«s tĂ« nevojshme pĂ«r tĂ« mbĂ«shtetur punĂ«n nĂ« kĂ«tĂ« fazĂ«, si aktualisht (nĂ« fakt) ashtu edhe nĂ« tĂ« ardhmen (tĂ« planifikuara);
    • PĂ«r secilin produkt, tregohet se cilat faza ose hapa teknologjikĂ« janĂ« zbatuar, janĂ« planifikuar pĂ«r zbatim, janĂ« tĂ« parĂ«ndĂ«sishĂ«m ose nuk janĂ« zbatuar.

Marrja e vendimeve bazuar në një hartë procesi

Pas shqyrtimit të hartës, është e mundur të ndërmerren veprime të caktuara, varësisht nga roli i punonjësit në kompani (menaxher zhvillimi, menaxher produkti, zhvillues ose testues):

  • tĂ« kuptojnĂ« se cilat faza mungojnĂ« nĂ« njĂ« produkt ose projekt real dhe tĂ« vlerĂ«sojnĂ« nevojĂ«n pĂ«r zbatimin e tyre;
  • pĂ«rcaktojnĂ« fushat e pĂ«rgjegjĂ«sisĂ« midis disa departamenteve nĂ«se ato po punojnĂ« nĂ« faza tĂ« ndryshme;
  • tĂ« bien dakord pĂ«r kontratat pĂ«r inputet dhe rezultatet e fazave;
  • integroni fazĂ«n tuaj tĂ« punĂ«s nĂ« procesin e pĂ«rgjithshĂ«m tĂ« zhvillimit;
  • vlerĂ«soni mĂ« saktĂ« nevojĂ«n pĂ«r burime pĂ«r tĂ« mbĂ«shtetur secilĂ«n fazĂ«.

Për të përmbledhur të gjitha sa më sipër

NjĂ« diagram rrjedhĂ«s i procesit Ă«shtĂ« universal, i zgjerueshĂ«m dhe i lehtĂ« pĂ«r t’u mirĂ«mbajtur. Zhvillimi dhe mirĂ«mbajtja e pĂ«rshkrimeve tĂ« procesit nĂ« kĂ«tĂ« format Ă«shtĂ« shumĂ« mĂ« e lehtĂ« sesa nĂ« njĂ« model tĂ« rreptĂ« akademik IDEF0. PĂ«r mĂ« tepĂ«r, njĂ« pĂ«rshkrim tabelar Ă«shtĂ« mĂ« i thjeshtĂ«, mĂ« i njohur dhe mĂ« i strukturuar sesa njĂ« model funksional.

Ne përdorim një mjet të brendshëm të dedikuar, CrossBuilder, për të trajtuar zbatimin teknik të këtyre hapave. Ai vepron si një shtresë midis sistemeve CI, shërbimeve dhe infrastrukturës. Zhvilluesit nuk kanë nevojë të personalizojnë konfigurimin e tyre: në sistemin tonë CI, ata thjesht duhet të ekzekutojnë një nga skriptet e CrossBuilder (të quajtura detyra), i cili do ta ekzekutojë atë në mënyrë korrekte, duke marrë parasysh specifikat e infrastrukturës sonë.

Rezultatet e

Ky artikull është mjaft i gjatë, por kjo është e pashmangshme kur përshkruhet modelimi kompleks i proceseve. Si përfundim, do të doja të përmbledh shkurtimisht idetë tona kryesore:

  • QĂ«llimi i zbatimit tĂ« ideve DevOps nĂ« kompaninĂ« tonĂ« Ă«shtĂ« ulja e vazhdueshme e kostos sĂ« prodhimit dhe mbĂ«shtetjes sĂ« produkteve tĂ« kompanisĂ« nĂ« terma sasiorĂ« (orĂ« pune ose orĂ« makinerie, vCPU, RAM, Disk).
  • NjĂ« mĂ«nyrĂ« pĂ«r tĂ« ulur koston e pĂ«rgjithshme tĂ« zhvillimit Ă«shtĂ« minimizimi i kostos sĂ« kryerjes sĂ« detyrave tipike serike: fazat dhe hapat e procesit teknologjik.
  • NjĂ« detyrĂ« tipike Ă«shtĂ« njĂ« detyrĂ«, zgjidhja e sĂ« cilĂ«s Ă«shtĂ« plotĂ«sisht ose pjesĂ«risht e automatizuar, nuk shkakton vĂ«shtirĂ«si pĂ«r interpretuesit dhe nuk kĂ«rkon kosto tĂ« konsiderueshme pune.
  • Procesi i prodhimit pĂ«rbĂ«het nga faza, tĂ« cilat ndahen nĂ« hapa tĂ« pandashĂ«m, tĂ« cilĂ«t pĂ«rfaqĂ«sojnĂ« detyra tipike me shkallĂ« dhe vĂ«llim tĂ« ndryshĂ«m.
  • Nga detyra tĂ« izoluara, tipike, kemi arritur nĂ« zinxhirĂ« kompleksĂ« teknologjikĂ« dhe modele shumĂ«nivelĂ«she tĂ« procesit tĂ« prodhimit, tĂ« cilat mund tĂ« pĂ«rshkruhen nga njĂ« model funksional IDEF0 ose njĂ« grafik mĂ« i thjeshtĂ« procesi.
  • NjĂ« grafik rrjedhĂ«s i procesit Ă«shtĂ« njĂ« paraqitje tabelare e fazave dhe hapave tĂ« njĂ« procesi prodhimi. MĂ« e rĂ«ndĂ«sishmja, njĂ« grafik ju lejon tĂ« shihni tĂ« gjithĂ« procesin nĂ« tĂ«rĂ«sinĂ« e tij, nĂ« pjesĂ« tĂ« mĂ«dha, me mundĂ«sinĂ« pĂ«r tĂ« hyrĂ« nĂ« seksione specifike.
  • Duke pĂ«rdorur njĂ« hartĂ« procesi, mund tĂ« vlerĂ«sohet nevoja pĂ«r zbatimin e fazave nĂ« njĂ« produkt tĂ« caktuar, tĂ« pĂ«rcaktohen fushat e pĂ«rgjegjĂ«sisĂ«, tĂ« negociohen kontrata pĂ«r inputet dhe rezultatet e fazave dhe tĂ« vlerĂ«sohen mĂ« saktĂ« kĂ«rkesat pĂ«r burime.

Në artikujt vijues, do të diskutojmë më në detaje mjetet teknike të përdorura për të zbatuar faza të ndryshme teknologjike në hartën tonë.

Autorët e artikullit:

  • AleksandĂ«r Pazdnikov — Drejtor i Departamentit tĂ« Automatizimit (DevOps) nĂ« Positive Technologies
  • Timur Gilmullin — ZĂ«vendĂ«sdrejtor i Departamentit tĂ« Automatizimit (DevOps) nĂ« Positive Technologies

Burimi: www.habr.com

Bleni njĂ« host tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, serverĂ« VPS VDS đŸ”„ Bleni hosting tĂ« besueshĂ«m tĂ« faqeve tĂ« internetit me mbrojtje DDoS, servera VPS VDS | ProHoster