Kudhibiti Machafuko: Kuweka mambo katika mpangilio kwa usaidizi wa ramani ya kiteknolojia

Kudhibiti Machafuko: Kuweka mambo katika mpangilio kwa usaidizi wa ramani ya kiteknolojia

Picha: Unsplash

Salaam wote! Sisi ni wahandisi wa otomatiki kutoka kwa kampuni Teknolojia Chanya na tunaunga mkono ukuzaji wa bidhaa za kampuni: tunaunga mkono bomba zima la mkusanyiko kutoka kwa ahadi ya safu ya msimbo na wasanidi programu hadi uchapishaji wa bidhaa zilizomalizika na leseni kwenye seva za sasisho. Kwa njia isiyo rasmi, tunaitwa wahandisi wa DevOps. Katika makala hii, tunataka kuzungumza juu ya hatua za kiteknolojia za mchakato wa uzalishaji wa programu, jinsi tunavyoziona na jinsi tunavyoziainisha.

Kutoka kwa nyenzo utajifunza juu ya ugumu wa kuratibu maendeleo ya bidhaa nyingi, juu ya ramani ya kiteknolojia ni nini na jinsi inavyosaidia kurahisisha na kuiga suluhisho, ni hatua gani kuu na hatua za mchakato wa maendeleo, ni jinsi gani maeneo ya uwajibikaji. kati ya DevOps na timu katika kampuni yetu.

Kuhusu Machafuko na DevOps

Kwa ufupi, dhana ya DevOps inajumuisha zana na huduma za ukuzaji, pamoja na mbinu na mbinu bora za matumizi yao. Wacha tuangazie ulimwengu lengo kutoka kwa utekelezaji wa mawazo ya DevOps katika kampuni yetu: hii ni kupunguza mara kwa mara kwa gharama ya uzalishaji na matengenezo ya bidhaa kwa maneno ya kiasi (masaa ya mtu au masaa ya mashine, CPU, RAM, Disk, nk). Njia rahisi na dhahiri zaidi ya kupunguza gharama ya jumla ya maendeleo katika kiwango cha kampuni nzima ni kupunguza gharama ya kufanya kazi za kawaida za mfululizo katika hatua zote za uzalishaji. Lakini ni hatua gani hizi, jinsi ya kuwatenganisha na mchakato wa jumla, ni hatua gani zinazojumuisha?

Kampuni inapotengeneza bidhaa moja, kila kitu huwa wazi zaidi au kidogo: kwa kawaida kuna ramani ya barabara na mpango wa maendeleo. Lakini nini cha kufanya wakati mstari wa bidhaa unapanua na kuna bidhaa zaidi? Kwa mtazamo wa kwanza, wana michakato sawa na mistari ya kusanyiko, na mchezo wa "kupata tofauti za X" kwenye kumbukumbu na maandiko huanza. Lakini vipi ikiwa tayari kuna miradi 5+ katika maendeleo ya kazi na usaidizi wa matoleo kadhaa yaliyotengenezwa kwa miaka kadhaa inahitajika? Je, tunataka kutumia tena idadi ya juu iwezekanavyo ya suluhu katika mabomba ya bidhaa au tuko tayari kutumia pesa katika maendeleo ya kipekee kwa kila moja?

Jinsi ya kupata usawa kati ya kipekee na suluhisho za serial?

Maswali haya yalianza kuibuka mbele yetu mara nyingi zaidi tangu 2015. Idadi ya bidhaa ilikua, na tulijaribu kupanua idara yetu ya otomatiki (DevOps), ambayo iliunga mkono mistari ya kusanyiko ya bidhaa hizi, kwa kiwango cha chini. Wakati huo huo, tulitaka kuiga suluhisho nyingi iwezekanavyo kati ya bidhaa. Baada ya yote, kwa nini kufanya kitu kimoja katika bidhaa kumi kwa njia tofauti?

Mkurugenzi wa Maendeleo: "Jamani, tunaweza kutathmini kwa namna fulani kile DevOps hufanya kwa bidhaa?"

Sisi: "Hatujui, hatukuuliza swali kama hilo, lakini ni viashiria gani vinapaswa kuzingatiwa?"

Mkurugenzi wa Maendeleo: "Nani anajua! Fikiria…”

Kama katika filamu hiyo maarufu: "Niko hotelini! .." - "Uh ... Unaweza kunionyesha njia?" Kwa kutafakari, tulifikia hitimisho kwamba tunahitaji kwanza kuamua juu ya majimbo ya mwisho ya bidhaa; hili likawa lengo letu la kwanza.

Kwa hivyo, unachanganuaje bidhaa kadhaa zilizo na timu kubwa kutoka kwa watu 10 hadi 200 na kubaini vipimo vinavyoweza kupimika wakati wa kunakili suluhu?

1:0 kwa kupendelea Machafuko, au DevOps kwenye blade za bega

Tulianza na jaribio la kutumia michoro ya IDEF0 na michoro mbalimbali za mchakato wa biashara kutoka kwa mfululizo wa BPwin. Mkanganyiko ulianza baada ya mraba wa tano wa hatua inayofuata ya mradi unaofuata, na miraba hii kwa kila mradi inaweza kuchorwa kwenye mkia wa chatu mrefu chini ya hatua 50+. Nilisikitika na nilitaka kuomboleza mwezi - haikufaa kwa ujumla.

Kazi za kawaida za uzalishaji

Kuiga michakato ya uzalishaji ni kazi ngumu sana na yenye uchungu: unahitaji kukusanya, kusindika na kuchambua data nyingi kutoka kwa idara na minyororo ya uzalishaji. Unaweza kusoma zaidi kuhusu hili katika makala "Uundaji wa michakato ya uzalishaji katika kampuni ya IT'.

Tulipoanza kuiga mchakato wetu wa uzalishaji, tulikuwa na lengo mahususi - kuwasilisha kwa kila mfanyakazi anayehusika katika utengenezaji wa bidhaa za kampuni yetu, na kwa wasimamizi wa mradi:

  • jinsi bidhaa na vifaa vyake, kuanzia ahadi ya safu ya msimbo, hufikia mteja kwa njia ya visakinishi na visasisho,
  • ni rasilimali gani hutolewa kwa kila hatua ya uzalishaji wa bidhaa,
  • ni huduma gani zinazohusika katika kila hatua,
  • jinsi maeneo ya uwajibikaji kwa kila hatua yamegawanywa,
  • ni mikataba gani ipo kwenye mlango na kutoka kwa kila hatua.

Kudhibiti Machafuko: Kuweka mambo katika mpangilio kwa usaidizi wa ramani ya kiteknolojia

Kubofya kwenye picha kutafungua kwa ukubwa kamili.

Kazi yetu katika kampuni imegawanywa katika maeneo kadhaa ya kazi. Mwelekeo wa miundombinu unahusika katika uboreshaji wa uendeshaji wa rasilimali zote za "chuma" za idara, pamoja na automatisering ya kupelekwa kwa mashine za kawaida na mazingira juu yao. Mwelekeo wa ufuatiliaji hutoa udhibiti wa utendaji wa huduma 24/7; pia tunatoa ufuatiliaji kama huduma kwa wasanidi programu. Mwelekeo wa mtiririko wa kazi huzipa timu zana za kudhibiti michakato ya ukuzaji na majaribio, kuchanganua hali ya kanuni, na kupata uchanganuzi wa miradi. Na hatimaye, mwelekeo wa webdev hutoa uchapishaji wa matoleo kwenye seva za sasisho za GUS na FLUS, pamoja na utoaji wa leseni ya bidhaa kwa kutumia huduma ya LicenseLab. Ili kusaidia uzalishaji, tunaanzisha na kudumisha huduma nyingi tofauti za usaidizi kwa wasanidi programu (unaweza kusikiliza hadithi kuhusu baadhi yao kwenye mikutano ya zamani: Op!DevOps! 2016 и Op!DevOps! 2017) Pia tunatengeneza zana za otomatiki za ndani, zikiwemo suluhu za chanzo wazi.

Katika kipindi cha miaka mitano iliyopita, kazi yetu imekusanya shughuli nyingi za aina sawa na za kawaida, na watengenezaji wetu kutoka idara zingine hutoka kwa kile kinachojulikana. kazi za kawaida, suluhisho ambalo ni kikamilifu au sehemu ya automatiska, haina kusababisha matatizo kwa watendaji na hauhitaji kiasi kikubwa cha kazi. Pamoja na maeneo ya kuongoza, tulichambua kazi hizo na tukaweza kutambua aina za kazi za kibinafsi, au hatua za uzalishaji, hatua ziligawanywa katika hatua zisizogawanyika, na hatua kadhaa zinaongeza mlolongo wa mchakato wa uzalishaji.

Kudhibiti Machafuko: Kuweka mambo katika mpangilio kwa usaidizi wa ramani ya kiteknolojia

Mfano rahisi zaidi wa msururu wa kiteknolojia ni hatua za kuunganisha, kusambaza na kujaribu kila moja ya bidhaa zetu ndani ya kampuni. Kwa upande mwingine, kwa mfano, hatua ya ujenzi ina hatua nyingi tofauti za kawaida: kupakua vyanzo kutoka kwa GitLab, kuandaa utegemezi na maktaba za watu wengine, upimaji wa kitengo na uchanganuzi wa nambari tuli, kutekeleza hati ya ujenzi kwenye GitLab CI, kuchapisha vipengee kwenye ghala. Usanii na uundaji wa madokezo ya kutolewa kupitia zana yetu ya ndani ya ChangelogBuilder.

Unaweza kusoma juu ya kazi za kawaida za DevOps katika nakala zetu zingine kuhusu Habré: "Uzoefu wa kibinafsi: jinsi mfumo wetu wa Ujumuishaji Unaoendelea unavyoonekana"Na"Uendeshaji wa michakato ya maendeleo: jinsi tulivyotekeleza mawazo ya DevOps katika Positive Technologies'.

Minyororo mingi ya kawaida ya uzalishaji huunda mchakato wa utengenezaji. Mbinu ya kawaida ya kuelezea michakato ni kutumia mifano ya kazi ya IDEF0.

Mfano wa kuiga mchakato wa utengenezaji wa CI

Tulilipa kipaumbele maalum kwa maendeleo ya miradi ya kawaida ya mfumo wa ushirikiano unaoendelea. Hii ilifanya iwezekanavyo kufikia umoja wa miradi, ikionyesha kinachojulikana mpango wa ujenzi wa kutolewa na matangazo.

Kudhibiti Machafuko: Kuweka mambo katika mpangilio kwa usaidizi wa ramani ya kiteknolojia

Hivi ndivyo inavyofanya kazi. Miradi yote inaonekana ya kawaida: inajumuisha usanidi wa makusanyiko ambayo huanguka kwenye hazina ya muhtasari katika Artifactory, baada ya hapo hutumwa na kujaribiwa kwenye madawati ya majaribio, na kisha kukuzwa kwenye hazina ya kutolewa. Huduma ya Artifactory ni sehemu moja ya usambazaji kwa vizalia vyote vya ujenzi kati ya timu na huduma zingine.

Iwapo tutarahisisha na kujumlisha mpango wetu wa uchapishaji, basi unajumuisha hatua zifuatazo:

  • mkusanyiko wa bidhaa za jukwaa,
  • kupeleka kwenye madawati ya majaribio,
  • kufanya majaribio ya kufanya kazi na mengine,
  • kukuza ujenzi uliojaribiwa ili kutolewa hazina huko Artifactory,
  • uchapishaji wa kutolewa hujengwa kwenye seva za sasisho,
  • utoaji wa makusanyiko na sasisho za uzalishaji,
  • kuzindua ufungaji na uppdatering wa bidhaa.

Kwa mfano, fikiria mfano wa kiteknolojia wa mpango huu wa kawaida wa kutolewa (hapa kwa kifupi Mfano) katika mfumo wa muundo wa kazi wa IDEF0. Inaonyesha hatua kuu za mchakato wetu wa CI. Aina za IDEF0 hutumia kinachojulikana Nukuu ya ICOM (Input-Control-Output-Mechanism) kuelezea ni rasilimali gani inatumika katika kila hatua, kulingana na sheria na mahitaji gani kazi inafanywa, ni matokeo gani, na ni njia gani, huduma au watu hutekeleza hatua fulani.

Kudhibiti Machafuko: Kuweka mambo katika mpangilio kwa usaidizi wa ramani ya kiteknolojia

Kubofya kwenye picha kutafungua kwa ukubwa kamili.

Kama sheria, ni rahisi kutengana na kufafanua maelezo ya michakato katika mifano ya kazi. Lakini kadiri idadi ya vipengele inavyoongezeka, inakuwa vigumu zaidi na zaidi kuelewa kitu ndani yao. Lakini katika maendeleo halisi pia kuna hatua za msaidizi: ufuatiliaji, vyeti vya bidhaa, automatisering ya michakato ya kazi, na wengine. Ni kwa sababu ya tatizo la kuongeza ukubwa ndipo tulipoacha maelezo haya.

Kuzaliwa kwa matumaini

Katika kitabu kimoja, tulikutana na ramani za zamani za Soviet zinazoelezea michakato ya kiteknolojia (ambayo, kwa njia, bado inatumiwa leo katika makampuni mengi ya serikali na vyuo vikuu). Subiri, subiri, kwa sababu pia tuna mtiririko wa kazi!.. Kuna hatua, matokeo, vipimo, mahitaji, viashirio, na kadhalika na kadhalika... Kwa nini usijaribu kutumia laha za mtiririko kwenye mabomba ya bidhaa zetu pia? Kulikuwa na hisia: "Hii ndio! Tumepata thread sahihi, ni wakati wa kuivuta vizuri!

Katika meza rahisi, tuliamua kurekodi bidhaa kwa safu, na hatua za teknolojia na hatua za bomba la bidhaa kwa safu. Milestones ni kitu kikubwa, kama vile hatua ya kujenga bidhaa. Na hatua ni kitu kidogo na kina maelezo zaidi, kama vile hatua ya kupakua msimbo wa chanzo kwenye seva ya ujenzi au hatua ya kuunda msimbo.

Katika makutano ya safu na safu wima za ramani, tunaweka hali za hatua na bidhaa maalum. Kwa hali, seti ya majimbo ilifafanuliwa:

  1. Hakuna data - au isiyofaa. Inahitajika kuchambua mahitaji ya hatua katika bidhaa. Labda uchambuzi tayari umefanywa, lakini hatua kwa sasa haihitajiki au haina haki ya kiuchumi.
  2. Imeahirishwa - au sio muhimu kwa sasa. Hatua katika bomba inahitajika, lakini hakuna nguvu za utekelezaji mwaka huu.
  3. Iliyopangwa. Hatua hiyo imepangwa kutekelezwa mwaka huu.
  4. Imetekelezwa. Hatua katika bomba inatekelezwa kwa kiasi kinachohitajika.

Kujaza jedwali kulianza mradi kwa mradi. Kwanza, hatua na hatua za mradi mmoja ziliainishwa na hali zao zilirekodiwa. Kisha walichukua mradi uliofuata, wakaweka takwimu ndani yake na kuongeza hatua na hatua ambazo hazikuwepo katika miradi iliyopita. Kwa hivyo, tulipata hatua na hatua za bomba letu zima la uzalishaji na hali zao katika mradi maalum. Ilibadilika kuwa kitu sawa na matrix ya uwezo wa bomba la bidhaa. Tuliita matrix kama hiyo ramani ya kiteknolojia.

Kwa usaidizi wa ramani ya kiteknolojia, tunaratibu kimawazo na timu na timu mipango ya kazi ya mwaka na malengo ambayo tunataka kufikia kwa pamoja: ni hatua zipi tunazoongeza kwenye mradi mwaka huu, na ni zipi tunazoacha baadaye. Pia, wakati wa kazi, tunaweza kuwa na maboresho katika hatua ambazo tumekamilisha kwa bidhaa moja tu. Kisha tunapanua ramani yetu na kutambulisha uboreshaji huu kama hatua au hatua mpya, kisha tunachanganua kwa kila bidhaa na kujua uwezekano wa kunakili uboreshaji.

Wanaweza kutupinga: "Hii ni yote, bila shaka, nzuri, tu baada ya muda idadi ya hatua na hatua zitakuwa kubwa sana. Jinsi ya kuwa?

Tumeanzisha maelezo ya kawaida na kamili ya mahitaji ya kila hatua na hatua, ili yaeleweke na kila mtu ndani ya kampuni kwa njia sawa. Baada ya muda, maboresho yanapoanzishwa, hatua inaweza kuingizwa kwenye hatua nyingine au hatua, na kisha "itaanguka". Wakati huo huo, mahitaji yote na nuances ya kiteknolojia inafaa katika mahitaji ya hatua ya jumla au hatua.

Jinsi ya kutathmini athari za kuiga suluhisho? Tunatumia mbinu rahisi sana: tunahusisha gharama za awali za mtaji kwa ajili ya utekelezaji wa hatua mpya kwa gharama za kila mwaka za bidhaa, na kisha kugawanya kwa wote wakati wa kunakili.

Sehemu za maendeleo tayari zimeonyeshwa kama hatua muhimu kwenye ramani. Tunaweza kushawishi kupunguzwa kwa gharama ya bidhaa kupitia kuanzishwa kwa otomatiki kwa hatua za kawaida. Baada ya hayo, tunazingatia mabadiliko katika sifa za ubora, vipimo vya kiasi na faida iliyopokelewa na timu (katika masaa ya mtu au masaa ya akiba ya mashine).

Ramani ya teknolojia ya mchakato wa uzalishaji

Ikiwa tutachukua hatua na hatua zetu zote, kuziweka kwa vitambulisho na kuzipanua kwenye mnyororo mmoja, basi itageuka kuwa ndefu sana na isiyoeleweka (tu "mkia wa python" ambao tulizungumzia mwanzoni mwa makala) :

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

Hizi ni hatua za bidhaa za ujenzi [Build], kuzipeleka kwenye majaribio ya seva [Weka], kujaribu [Jaribio], kukuza miundo ili kutoa hazina kulingana na matokeo ya majaribio [Kuza], kuzalisha na kuchapisha leseni [Leseni], uchapishaji [ Chapisha] kwenye seva ya sasisho ya GUS na uwasilishaji kwa seva za kusasisha za FLUS, usakinishaji na usasishaji wa vipengee vya bidhaa kwenye miundombinu ya mteja kwa kutumia Usimamizi wa Usanidi wa Bidhaa [Sakinisha], pamoja na ukusanyaji wa telemetry [Telemetry] kutoka kwa bidhaa zilizosakinishwa.

Kando na hizo, hatua tofauti zinaweza kutofautishwa: ufuatiliaji wa hali ya miundombinu [InfMonitoring], toleo la msimbo wa chanzo [SourceCodeControl], utayarishaji wa mazingira [Jitayarishe], usimamizi wa mradi [Mtiririko wa kazi], kuzipa timu zana za mawasiliano [Mawasiliano], uthibitishaji wa bidhaa [ Uthibitishaji] na kuhakikisha utoshelevu wa michakato ya CI [CISelfSufficiency] (kwa mfano, uhuru wa makusanyiko kutoka kwa Mtandao). Hatua kadhaa katika michakato yetu hazitazingatiwa, kwa sababu ni maalum sana.

Itakuwa rahisi zaidi kuelewa na kuangalia mchakato mzima wa uzalishaji ikiwa utawasilishwa kwa fomu ramani ya kiteknolojia; hii ni jedwali ambalo hatua za uzalishaji wa mtu binafsi na hatua zilizoharibika za Mfano zimeandikwa kwa safu, na katika safu maelezo ya kile kinachofanyika katika kila hatua au hatua. Msisitizo mkuu umewekwa kwenye rasilimali zinazotoa kila hatua, na uwekaji mipaka wa maeneo ya wajibu.

Ramani kwa ajili yetu ni aina ya kiainishi. Inaonyesha sehemu kubwa za kiteknolojia za uzalishaji wa bidhaa. Shukrani kwa hilo, ikawa rahisi kwa timu yetu ya automatisering kuingiliana na watengenezaji na kupanga kwa pamoja utekelezaji wa hatua za automatisering, na pia kuelewa ni gharama gani za kazi na rasilimali (binadamu na vifaa) zitahitajika kwa hili.

Ndani ya kampuni yetu, ramani inatolewa kiotomatiki kutoka kwa kiolezo cha jinja kama faili ya kawaida ya HTML, na kisha kupakiwa kwenye seva ya Kurasa za GitLab. Picha ya skrini yenye mfano wa ramani iliyozalishwa kikamilifu inaweza kutazamwa по ссылке.

Kudhibiti Machafuko: Kuweka mambo katika mpangilio kwa usaidizi wa ramani ya kiteknolojia

Kubofya kwenye picha kutafungua kwa ukubwa kamili.

Kwa kifupi, ramani ya kiteknolojia ni picha ya jumla ya mchakato wa uzalishaji, ambayo inaonyesha vitalu vilivyoainishwa wazi na utendaji wa kawaida.

Muundo wa ramani yetu ya barabara

Ramani ina sehemu kadhaa:

  1. Eneo la kichwa - hapa ni maelezo ya jumla ya ramani, dhana za msingi zinaletwa, rasilimali kuu na matokeo ya mchakato wa uzalishaji hufafanuliwa.
  2. Dashibodi - hapa unaweza kudhibiti maonyesho ya data kwa bidhaa za kibinafsi, muhtasari wa hatua zilizotekelezwa na hatua kwa ujumla kwa bidhaa zote hutolewa.
  3. Ramani ya kiteknolojia - maelezo ya jedwali ya mchakato wa kiteknolojia. Kwenye ramani:
    • hatua zote, hatua na kanuni zao zimetolewa;
    • maelezo mafupi na kamili ya hatua hutolewa;
    • rasilimali za pembejeo na huduma zinazotumiwa katika kila hatua zimeonyeshwa;
    • matokeo ya kila hatua na hatua tofauti huonyeshwa;
    • eneo la uwajibikaji kwa kila hatua na hatua imeonyeshwa;
    • rasilimali za kiufundi, kama HDD (SSD), RAM, vCPU, na masaa ya mtu muhimu kusaidia kazi katika hatua hii, kwa wakati huu - ukweli, na katika siku zijazo - mpango umedhamiriwa;
    • kwa kila bidhaa, imeonyeshwa ni hatua gani za kiteknolojia au hatua zake zimetekelezwa, zilizopangwa kwa utekelezaji, zisizo na maana au hazijatekelezwa.

Kufanya maamuzi kulingana na ramani ya kiteknolojia

Baada ya kukagua ramani, inawezekana kuchukua hatua kadhaa - kulingana na jukumu la mfanyakazi katika kampuni (meneja wa maendeleo, meneja wa bidhaa, msanidi programu au anayejaribu):

  • kuelewa ni hatua gani zinazokosekana katika bidhaa au mradi halisi, na kutathmini hitaji la utekelezaji wao;
  • kuweka mipaka ya maeneo ya uwajibikaji kati ya idara kadhaa ikiwa zinafanya kazi kwa hatua tofauti;
  • kukubaliana juu ya mikataba kwenye viingilio na kutoka kwa hatua;
  • kuunganisha hatua yako ya kazi katika mchakato wa maendeleo ya jumla;
  • kutathmini kwa usahihi zaidi hitaji la rasilimali zinazotoa kila moja ya hatua.

Kwa muhtasari wa yote yaliyo hapo juu

Uelekezaji ni mwingi, unaweza kupanuka na ni rahisi kutunza. Ni rahisi zaidi kukuza na kudumisha maelezo ya michakato katika fomu hii kuliko kwa mfano mkali wa kitaaluma wa IDEF0. Kwa kuongeza, maelezo ya jedwali ni rahisi, yanajulikana zaidi, na yana muundo bora zaidi kuliko mfano wa kazi.

Kwa utekelezaji wa kiufundi wa hatua, tuna chombo maalum cha ndani CrossBuilder - chombo cha safu kati ya mifumo ya CI, huduma na miundombinu. Msanidi hauitaji kukata baiskeli yake: katika mfumo wetu wa CI, inatosha kuendesha moja ya maandishi (kinachojulikana kama kazi) ya chombo cha CrossBuilder, ambacho kitaifanya kwa usahihi, kwa kuzingatia sifa za miundombinu yetu. .

Matokeo ya

Nakala hiyo iligeuka kuwa ndefu sana, lakini hii haiwezi kuepukika wakati wa kuelezea muundo wa michakato ngumu. Mwishowe, ningependa kurekebisha kwa ufupi maoni yetu kuu:

  • Lengo la kutekeleza mawazo ya DevOps katika kampuni yetu ni kupunguza mara kwa mara gharama ya uzalishaji na matengenezo ya bidhaa za kampuni kwa maneno ya kiasi (saa za mtu au saa za mashine, vCPU, RAM, Disk).
  • Njia ya kupunguza gharama ya jumla ya maendeleo ni kupunguza gharama ya kufanya kazi za kawaida za serial: hatua na hatua za mchakato wa kiteknolojia.
  • Kazi ya kawaida ni kazi ambayo ufumbuzi wake ni automatiska kikamilifu au sehemu, haina kusababisha matatizo kwa watendaji na hauhitaji gharama kubwa za kazi.
  • Mchakato wa uzalishaji una hatua, hatua zimegawanywa katika hatua zisizogawanyika, ambazo ni kazi za kawaida za kiwango tofauti na upeo.
  • Kutoka kwa kazi tofauti za kawaida, tumekuja kwenye minyororo tata ya teknolojia na mifano ya ngazi mbalimbali ya mchakato wa uzalishaji, ambayo inaweza kuelezewa na mfano wa kazi wa IDEF0 au ramani rahisi ya teknolojia.
  • Ramani ya kiteknolojia ni uwakilishi wa jedwali wa hatua na hatua za mchakato wa uzalishaji. Jambo muhimu zaidi: ramani hukuruhusu kuona mchakato mzima kwa ukamilifu, kwa vipande vikubwa na uwezekano wa kuzielezea.
  • Kulingana na ramani ya kiteknolojia, inawezekana kutathmini hitaji la kuanzisha hatua katika bidhaa fulani, kuainisha maeneo ya uwajibikaji, kukubaliana juu ya mikataba katika pembejeo na matokeo ya hatua, na kutathmini kwa usahihi hitaji la rasilimali.

Katika makala zifuatazo, tutaelezea kwa undani zaidi ni zana gani za kiufundi zinazotumiwa kutekeleza hatua fulani za teknolojia kwenye ramani yetu.

Waandishi wa makala:

  • Alexander Pazdnikov - Mkuu wa Automation (DevOps) katika Positive Technologies
  • Timur Gilmullin - Naibu Mkuu wa Idara ya Automation (DevOps) katika Positive Technologies

Chanzo: mapenzi.com

Kuongeza maoni