Miundombinu kama Kanuni: jinsi ya kushinda matatizo kwa kutumia XP

Habari, Habr! Hapo awali, nililalamika kuhusu maisha katika Miundombinu kama kanuni ya kanuni na sikutoa chochote kutatua hali ya sasa. Leo nimerudi kukuambia ni mbinu na mazoea gani yatakusaidia kutoka kwenye dimbwi la kukata tamaa na kuelekeza hali katika mwelekeo sahihi.

Katika makala iliyopita "Miundombinu kama kanuni: kufahamiana kwanza" Nilishiriki maoni yangu kuhusu eneo hili, nilijaribu kutafakari hali ya sasa katika eneo hili, na hata kupendekeza kwamba mazoea ya kawaida yanayojulikana kwa wasanidi wote yanaweza kusaidia. Inaweza kuonekana kuwa kulikuwa na malalamiko mengi kuhusu maisha, lakini hakukuwa na mapendekezo ya njia ya kutoka kwa hali ya sasa.

Sisi ni nani, tuko wapi na tuna matatizo gani

Kwa sasa tuko katika Timu ya Uendeshaji ya Sre, ambayo ina watayarishaji programu sita na wahandisi watatu wa miundombinu. Sote tunajaribu kuandika Miundombinu kama msimbo (IaC). Tunafanya hivyo kwa sababu tunajua jinsi ya kuandika msimbo na tuna historia ya kuwa wasanidi "juu ya wastani".

• Tuna seti ya faida: historia fulani, ujuzi wa mazoea, uwezo wa kuandika kanuni, hamu ya kujifunza mambo mapya.
• Na kuna sehemu inayopungua, ambayo pia ni minus: ukosefu wa ujuzi kuhusu vifaa vya miundombinu.

Rafu ya teknolojia tunayotumia katika IaC yetu.

• Terraform kwa kuunda rasilimali.
• Kifungashio cha kuunganisha picha. Hizi ni picha za Windows, CentOS 7.
• Jsonnet kutengeneza muundo wenye nguvu katika drone.io, na pia kutengeneza kipakiaji json na moduli zetu za terraform.
• Azure.
• Inastahili wakati wa kuandaa picha.
• Python kwa huduma za usaidizi na hati za utoaji.
• Na haya yote katika VSCode na programu-jalizi zilizoshirikiwa kati ya washiriki wa timu.

Hitimisho kutoka kwangu makala ya mwisho ilikuwa hivi: Nilijaribu kuingiza (kwanza kabisa ndani yangu) matumaini, nilitaka kusema kwamba tutajaribu mbinu na mazoea tunayojua ili kukabiliana na matatizo na magumu yaliyopo katika eneo hili.

Kwa sasa tunapambana na masuala yafuatayo ya IaC:

• Kutokamilika kwa zana na njia za ukuzaji wa kanuni.
• Usambazaji polepole. Miundombinu ni sehemu ya ulimwengu wa kweli, na inaweza kuwa polepole.
• Ukosefu wa mbinu na mazoea.
• Sisi ni wapya na hatujui mengi.

Uwekaji Programu Uliokithiri (XP) kwenye uokoaji

Wasanidi programu wote wanaifahamu Extreme Programming (XP) na mbinu zinazotumika kuisimamia. Wengi wetu tumefanya kazi na njia hii, na imefanikiwa. Kwa hivyo kwa nini usitumie kanuni na mazoea yaliyowekwa hapo ili kuondokana na changamoto za miundombinu? Tuliamua kuchukua njia hii na kuona nini kinatokea.

Kuangalia utumiaji wa mbinu ya XP kwenye tasnia yakoHapa kuna maelezo ya mazingira ambayo XP inafaa vyema, na jinsi inavyohusiana nasi:

1. Kubadilisha mahitaji ya programu kwa nguvu. Ilikuwa wazi kwetu nini lengo la mwisho lilikuwa. Lakini maelezo yanaweza kutofautiana. Sisi wenyewe tunaamua wapi tunahitaji teksi, kwa hivyo mahitaji yanabadilika mara kwa mara (haswa na sisi wenyewe). Ikiwa tunachukua timu ya SRE, ambayo hufanya automatisering yenyewe, na yenyewe inapunguza mahitaji na upeo wa kazi, basi hatua hii inafaa vizuri.

2. Hatari zinazosababishwa na miradi ya muda maalum kwa kutumia teknolojia mpya. Huenda tukakabili hatari tunapotumia baadhi ya mambo ambayo hatujui. Na hii ni kesi yetu 100%. Mradi wetu wote ulikuwa wa matumizi ya teknolojia ambayo hatukuwa tunaifahamu kikamilifu. Kwa ujumla, hii ni shida ya mara kwa mara, kwa sababu ... Kuna teknolojia nyingi mpya zinazojitokeza katika sekta ya miundombinu kila wakati.

3,4. Timu ndogo ya maendeleo iliyojumuishwa pamoja. Teknolojia ya kiotomatiki unayotumia inaruhusu majaribio ya kitengo na utendakazi. Mambo haya mawili hayatufai kabisa. Kwanza, sisi sio timu iliyoratibiwa, na pili, kuna tisa kati yetu, ambayo inaweza kuchukuliwa kuwa timu kubwa. Ingawa, kulingana na ufafanuzi fulani wa timu "kubwa", mengi ni watu 14+.

Hebu tuangalie baadhi ya mazoea ya XP na jinsi yanavyoathiri kasi na ubora wa maoni.

Kanuni ya Kitanzi cha Maoni ya XP

Kwa ufahamu wangu, maoni ni jibu la swali, je, ninafanya jambo sahihi, tunaenda huko? XP ina mpango wa kimungu kwa hili: kitanzi cha maoni ya wakati. Jambo la kuvutia ni kwamba sisi ni chini, kwa kasi tunaweza kupata OS kujibu maswali muhimu.

Hii ni mada ya kupendeza kwa majadiliano, kwamba katika tasnia yetu ya IT inawezekana kupata OS haraka. Fikiria jinsi ilivyo chungu kufanya mradi kwa miezi sita na kisha kugundua kuwa kulikuwa na kosa mwanzoni. Hii hutokea katika kubuni na katika ujenzi wowote wa mifumo tata.

Kwa upande wetu wa IaC, maoni hutusaidia. Mara moja nitafanya marekebisho madogo kwenye mchoro hapo juu: mpango wa kutolewa hauna mzunguko wa kila mwezi, lakini hutokea mara kadhaa kwa siku. Kuna baadhi ya mazoea yaliyounganishwa na mzunguko huu wa OS ambayo tutaangalia kwa undani zaidi.

Muhimu: maoni yanaweza kuwa suluhisho kwa matatizo yote yaliyotajwa hapo juu. Ikichanganywa na mazoea ya XP, inaweza kukutoa kwenye dimbwi la kukata tamaa.

Jinsi ya kujiondoa kutoka kwa shimo la kukata tamaa: mazoea matatu

Majaribio

Majaribio yanatajwa mara mbili katika kitanzi cha maoni cha XP. Sio hivyo tu. Wao ni muhimu sana kwa mbinu nzima ya Utayarishaji Mkubwa.

Inachukuliwa kuwa una vipimo vya Kitengo na Kukubalika. Wengine hukupa maoni baada ya dakika chache, wengine baada ya siku chache, kwa hivyo huchukua muda mrefu kuandika na hukaguliwa mara chache.

Kuna piramidi ya kupima classic, ambayo inaonyesha kwamba kunapaswa kuwa na vipimo zaidi.

Je, mfumo huu unatumikaje kwetu katika mradi wa IaC? Kweli ... sio kabisa.

• Vipimo vya kitengo, licha ya ukweli kwamba kunapaswa kuwa na mengi yao, hawezi kuwa mengi sana. Au wanajaribu kitu kwa njia isiyo ya moja kwa moja. Kwa kweli, tunaweza kusema kwamba hatuziandiki kabisa. Lakini hapa kuna maombi machache ya majaribio kama haya ambayo tuliweza kufanya:
  1. Inajaribu nambari ya jsonnet. Hii, kwa mfano, ni bomba letu la kuunganisha drone, ambayo ni ngumu sana. Nambari ya jsonnet imefunikwa vizuri na majaribio.
     Tunatumia hii Mfumo wa upimaji wa kitengo cha Jsonnet.
  2. Majaribio ya hati ambazo hutekelezwa wakati rasilimali inapoanza. Maandishi yameandikwa kwa Python, na kwa hivyo majaribio yanaweza kuandikwa juu yao.
• Inawezekana kuangalia usanidi katika majaribio, lakini hatufanyi hivyo. Inawezekana pia kusanidi sheria za usanidi wa rasilimali kupitia tflint. Walakini, ukaguzi hapo ni wa msingi sana kwa terraform, lakini maandishi mengi ya majaribio yameandikwa kwa AWS. Na tuko kwenye Azure, kwa hivyo hii haitumiki tena.
• Vipimo vya ujumuishaji wa vipengele: inategemea jinsi unavyoviainisha na mahali unapoviweka. Lakini kimsingi wanafanya kazi.

  Hivi ndivyo majaribio ya ujumuishaji yanavyoonekana.

  
  
  Huu ni mfano wakati wa kujenga picha katika Drone CI. Ili kuwafikia, unapaswa kusubiri kwa dakika 30 ili picha ya Packer iundwe, kisha usubiri dakika 15 nyingine ili zipite. Lakini zipo!

  Algorithm ya uthibitishaji wa picha

  1. Packer lazima kwanza kuandaa picha kabisa.
  2. Karibu na jaribio kuna terraform na hali ya ndani, ambayo tunatumia kupeleka picha hii.
  3. Wakati wa kufunua, moduli ndogo iliyo karibu hutumiwa ili iwe rahisi kufanya kazi na picha.
  4. Mara tu VM inapotumwa kutoka kwa picha, ukaguzi unaweza kuanza. Kimsingi, ukaguzi unafanywa kwa gari. Inaangalia jinsi maandishi yalivyofanya kazi wakati wa kuanza na jinsi daemoni zinavyofanya kazi. Ili kufanya hivyo, kupitia ssh au winrm tunaingia kwenye mashine mpya iliyoinuliwa na kuangalia hali ya usanidi au ikiwa huduma ziko juu.

• Hali ni sawa na majaribio ya ujumuishaji katika moduli za terraform. Hapa kuna jedwali fupi linaloelezea sifa za majaribio kama haya.

  
  
  Maoni juu ya bomba ni kama dakika 40. Kila kitu hutokea kwa muda mrefu sana. Inaweza kutumika kwa kurudi nyuma, lakini kwa maendeleo mapya kwa ujumla sio kweli. Ikiwa umejitayarisha sana kwa hili, jitayarisha hati zinazoendesha, basi unaweza kupunguza hadi dakika 10. Lakini hizi bado sio vipimo vya kitengo, ambavyo hufanya vipande 5 kwa sekunde 100.

Kutokuwepo kwa majaribio ya Kitengo wakati wa kuunganisha picha au moduli za terraform huhimiza kuhamisha kazi hadi kwa huduma tofauti ambazo zinaweza kuendeshwa tu kupitia REST, au kwa hati za Python.

Kwa mfano, tulihitaji kuhakikisha kuwa mashine pepe inapoanza, inajiandikisha kwenye huduma ScaleFT, na mashine ya mtandaoni ilipoharibiwa, ilijifuta yenyewe.

Kwa kuwa tuna ScaleFT kama huduma, tunalazimika kufanya kazi nayo kupitia API. Kulikuwa na kanga iliyoandikwa hapo ambayo ungeweza kuvuta na kusema: “Ingia ndani na ufute hiki na kile.” Inahifadhi mipangilio yote muhimu na ufikiaji.

Tunaweza tayari kuandika vipimo vya kawaida kwa hili, kwa kuwa sio tofauti na programu ya kawaida: aina fulani ya apiha inadhihakiwa, unaivuta, na uone kinachotokea.

Matokeo ya vipimo: Upimaji wa kitengo, ambacho kinapaswa kutoa OS kwa dakika, haitoi. Na aina za kupima juu katika piramidi ni nzuri, lakini hufunika sehemu tu ya matatizo.

Oanisha programu

Vipimo ni, bila shaka, nzuri. Unaweza kuandika mengi yao, yanaweza kuwa ya aina tofauti. Watafanya kazi katika viwango vyao na kutupa maoni. Lakini shida na vipimo vibaya vya kitengo, ambayo hutoa OS ya haraka sana, inabaki. Wakati huo huo, bado nataka OS ya haraka ambayo ni rahisi na ya kupendeza kufanya kazi nayo. Bila kutaja ubora wa suluhisho linalosababisha. Kwa bahati nzuri, kuna mbinu ambazo zinaweza kutoa maoni ya haraka zaidi kuliko vipimo vya kitengo. Hii ni programu ya jozi.

Unapoandika msimbo, unataka kupata maoni kuhusu ubora wake haraka iwezekanavyo. Ndio, unaweza kuandika kila kitu kwenye tawi la kipengele (ili usivunje chochote kwa mtu yeyote), fanya ombi la kuvuta huko Github, mpe mtu ambaye maoni yake yana uzito, na subiri jibu.

Lakini unaweza kusubiri kwa muda mrefu. Watu wote wana shughuli nyingi, na jibu, hata kama lipo, linaweza lisiwe la ubora wa juu. Tuseme kwamba jibu lilikuja mara moja, mhakiki alielewa wazo zima mara moja, lakini jibu bado linakuja kuchelewa, baada ya ukweli. Natamani ingekuwa mapema. Hivi ndivyo programu ya jozi inalenga - mara moja, wakati wa kuandika.

Ifuatayo ni mitindo ya upangaji jozi na utumiaji wao katika kufanya kazi kwenye IaC:

1. Kawaida, Mwenye Uzoefu+Uzoefu, badilisha kulingana na kipima muda. Majukumu mawili - dereva na navigator. Watu wawili. Wanafanya kazi kwa msimbo sawa na kubadilisha majukumu baada ya kipindi fulani cha muda kilichoamuliwa.

Wacha tuchunguze utangamano wa shida zetu na mtindo:

• Tatizo: kutokamilika kwa zana na zana za kuunda kanuni.
  Athari hasi: inachukua muda mrefu kuendeleza, tunapunguza kasi, kasi / rhythm ya kazi inapotea.
  Jinsi tunavyopigana: tunatumia zana tofauti, IDE ya kawaida na pia kujifunza njia za mkato.
• Tatizo: Usambazaji polepole.
  Athari hasi: huongeza muda unaotumika kuunda kipengee cha kufanya kazi cha msimbo. Tunapata kuchoka tunapongojea, mikono yetu inanyoosha mkono kufanya jambo lingine huku tukingoja.
  Jinsi tunavyopigana: hatukushinda.
• Tatizo: ukosefu wa mbinu na mazoea.
  Athari mbaya: hakuna ujuzi wa jinsi ya kuifanya vizuri na jinsi ya kuifanya vibaya. Hurefusha upokeaji wa maoni.
  Jinsi tunavyopigana: kubadilishana maoni na mazoea ya pande zote katika kazi ya jozi karibu kutatua tatizo.

Shida kuu ya kutumia mtindo huu katika IaC ni kasi isiyo sawa ya kazi. Katika maendeleo ya programu ya jadi, una harakati sare sana. Unaweza kutumia dakika tano na kuandika N. Tumia dakika 10 na kuandika 2N, dakika 15 - 3N. Hapa unaweza kutumia dakika tano na kuandika N, na kisha kutumia dakika nyingine 30 na kuandika sehemu ya kumi ya N. Hapa hujui chochote, umekwama, ujinga. Uchunguzi huchukua muda na huvuruga kutoka kwa programu yenyewe.

Hitimisho: kwa fomu yake safi haifai kwetu.

2. Ping-pong. Mbinu hii inahusisha mtu mmoja kuandika mtihani na mwingine kufanya utekelezaji kwa ajili yake. Kwa kuzingatia ukweli kwamba kila kitu ni ngumu na vipimo vya Kitengo, na unapaswa kuandika mtihani wa ushirikiano ambao unachukua muda mrefu kupanga, urahisi wote wa ping-pong huenda.

Ninaweza kusema kwamba tulijaribu kutenganisha majukumu ya kuunda hati ya jaribio na kutekeleza nambari yake. Mshiriki mmoja alikuja na script, katika sehemu hii ya kazi alikuwa na jukumu, alikuwa na neno la mwisho. Na mwingine alihusika na utekelezaji. Ilifanya kazi vizuri. Ubora wa maandishi na mbinu hii huongezeka.

Hitimisho: ole, kasi ya kazi hairuhusu matumizi ya ping-pong kama mazoezi ya kupanga programu katika IaC.

3.Mtindo Mkali. Mazoezi magumu. Wazo ni kwamba mshiriki mmoja anakuwa navigator wa maelekezo, na wa pili anachukua jukumu la dereva wa utekelezaji. Katika kesi hii, haki ya kufanya maamuzi inategemea tu navigator. Dereva huchapisha tu na anaweza kuathiri kinachotokea kwa neno. Majukumu hayabadilika kwa muda mrefu.

Nzuri kwa kujifunza, lakini inahitaji ustadi wa nguvu laini. Hapa ndipo tulipoyumba. Mbinu ilikuwa ngumu. Na sio hata kuhusu miundombinu.

Hitimisho: inaweza kutumika, hatukati tamaa kujaribu.

4. Mitindo ya makundi, mbwembwe na mitindo yote inayojulikana lakini haijaorodheshwa Hatuzingatii, kwa sababu Hatujajaribu na haiwezekani kuzungumza juu yake katika mazingira ya kazi yetu.

Matokeo ya jumla ya kutumia programu jozi:

• Tuna kasi isiyo sawa ya kazi, ambayo inachanganya.
• Tulipata ujuzi mzuri wa kutosha. Na eneo la somo halisaidii kuondokana na mapungufu yetu haya.
• Majaribio ya muda mrefu na matatizo ya zana hufanya maendeleo ya jozi kuwa magumu.

5. Pamoja na hayo, kulikuwa na mafanikio. Tulikuja na njia yetu wenyewe "Convergence - Divergence". Nitaelezea kwa ufupi jinsi inavyofanya kazi.

Tuna washirika wa kudumu kwa siku chache (chini ya wiki). Tunafanya kazi moja pamoja. Tunakaa pamoja kwa muda: mmoja anaandika, mwingine anakaa na kuangalia timu ya usaidizi. Kisha tunatawanyika kwa muda, kila mmoja hufanya mambo ya kujitegemea, kisha tunakutana tena, kusawazisha haraka sana, kufanya kitu pamoja na kutawanyika tena.

Mipango na mawasiliano

Kizuizi cha mwisho cha mazoea ambacho shida za OS hutatuliwa ni shirika la kazi na kazi zenyewe. Hii pia inajumuisha kubadilishana uzoefu ambao ni nje ya kazi ya jozi. Hebu tuangalie mazoea matatu:

1. Malengo kupitia mti wa lengo. Tulipanga usimamizi wa jumla wa mradi kupitia mti ambao huenda bila kikomo katika siku zijazo. Kitaalam, ufuatiliaji unafanywa huko Miro. Kuna kazi moja - ni lengo la kati. Kutoka kwake huenda malengo madogo au vikundi vya kazi. Kazi zenyewe zinatoka kwao. Kazi zote zinaundwa na kudumishwa kwenye ubao huu.

Mpango huu pia hutoa maoni, ambayo hutokea mara moja kwa siku tunapolandanisha kwenye mikusanyiko. Kuwa na mpango wa pamoja mbele ya kila mtu, lakini muundo na wazi kabisa, inaruhusu kila mtu kuwa na ufahamu wa kile kinachotokea na jinsi mbali tumeendelea.

Manufaa ya maono ya kuona ya kazi:

• Sababu. Kila kazi inaongoza kwa lengo fulani la kimataifa. Majukumu yanajumuishwa katika malengo madogo. Kikoa cha miundombinu yenyewe ni ya kiufundi kabisa. Haijulikani mara moja ni athari gani maalum, kwa mfano, kuandika kitabu cha kukimbia kwenye kuhamia nginx nyingine ina kwenye biashara. Kuwa na kadi inayolengwa karibu kunaifanya iwe wazi zaidi.
  
  Causality ni mali muhimu ya matatizo. Inajibu moja kwa moja swali: "Je! ninafanya jambo sahihi?"
• Usambamba. Kuna tisa kati yetu, na haiwezekani kimwili kutupa kila mtu kwa kazi moja. Majukumu kutoka eneo moja yanaweza yasitoshe kila wakati. Tunalazimika kusawazisha kazi kati ya vikundi vidogo vya kufanya kazi. Wakati huo huo, vikundi vinakaa kwenye kazi yao kwa muda fulani, wanaweza kuimarishwa na mtu mwingine. Wakati mwingine watu huanguka kutoka kwa kikundi hiki cha kazi. Mtu huenda likizo, mtu anatoa ripoti kwa mkutano wa DevOps, mtu anaandika makala juu ya Habr. Kujua ni malengo gani na kazi gani zinaweza kufanywa kwa usawa inakuwa muhimu sana.

2. Wawasilishaji badala wa mikutano ya asubuhi. Katika kusimama tuna tatizo hili - watu hufanya kazi nyingi kwa sambamba. Wakati mwingine kazi zinaunganishwa kwa urahisi na hakuna ufahamu wa nani anafanya nini. Na maoni ya mwanachama mwingine wa timu ni muhimu sana. Hii ni maelezo ya ziada ambayo yanaweza kubadilisha njia ya kutatua tatizo. Bila shaka, kwa kawaida kuna mtu pamoja nawe, lakini ushauri na vidokezo daima ni muhimu.

Ili kuboresha hali hii, tulitumia mbinu ya "Kubadilisha Uongozi wa Kusimama-Up". Sasa zinazungushwa kulingana na orodha fulani, na hii ina athari yake. Ikifika zamu yako, unalazimika kuzama ndani na kuelewa kinachoendelea ili kuendesha mkutano mzuri wa Scrum.

3. Onyesho la ndani. Msaada katika kutatua tatizo kutoka kwa programu ya jozi, taswira kwenye mti wa tatizo na usaidizi katika mikutano ya scrum asubuhi ni nzuri, lakini sio bora. Kama wanandoa, mmewekewa kikomo na ujuzi wenu. Mti wa kazi husaidia kuelewa kimataifa ni nani anafanya nini. Na mtangazaji na wenzake kwenye mkutano wa asubuhi hawataingia ndani ya shida zako. Hakika wanaweza kukosa kitu.

Suluhisho lilipatikana kwa kuonyesha kazi iliyofanywa kwa kila mmoja na kisha kuijadili. Tunakutana mara moja kwa wiki kwa saa moja na kuonyesha maelezo ya masuluhisho ya kazi ambazo tumefanya katika wiki iliyopita.

Wakati wa maandamano, ni muhimu kufunua maelezo ya kazi na kuwa na uhakika wa kuonyesha uendeshaji wake.

Ripoti inaweza kufanywa kwa kutumia orodha ya ukaguzi.1. Ingiza katika muktadha. Kazi hiyo ilitoka wapi, kwa nini ilikuwa muhimu?

2. Tatizo lilitatuliwaje hapo awali? Kwa mfano, kubofya kwa panya kwa nguvu kulihitajika, au haikuwezekana kufanya chochote.

3. Jinsi tunavyoiboresha. Kwa mfano: "Angalia, sasa kuna scriptosik, hapa ni kusoma."

4. Onyesha jinsi inavyofanya kazi. Inashauriwa kutekeleza moja kwa moja hali fulani ya mtumiaji. Nataka X, nafanya Y, naona Y (au Z). Kwa mfano, mimi hupeleka NGINX, kuvuta url, na kupata 200 OK. Ikiwa hatua ni ndefu, itayarishe mapema ili uweze kuionyesha baadaye. Inashauriwa usiivunje sana saa moja kabla ya onyesho, ikiwa ni dhaifu.

5. Eleza jinsi tatizo lilitatuliwa kwa mafanikio, ni shida gani zimebakia, ambazo hazijakamilika, ni maboresho gani yanawezekana katika siku zijazo. Kwa mfano, sasa CLI, basi kutakuwa na automatisering kamili katika CI.

Inashauriwa kwa kila mzungumzaji kuiweka kwa dakika 5-10. Ikiwa hotuba yako ni muhimu na itachukua muda mrefu zaidi, ratibu hii mapema katika njia ya kuchukua sre.

Baada ya sehemu ya uso kwa uso daima kuna mjadala katika thread. Hapa ndipo maoni tunayohitaji kuhusu kazi zetu yanapoonekana.

Matokeo yake, uchunguzi unafanywa ili kujua manufaa ya kile kinachotokea. Haya ni maoni juu ya kiini cha hotuba na umuhimu wa kazi.

Hitimisho refu na nini kinachofuata

Inaweza kuonekana kuwa sauti ya makala ni ya kukata tamaa. Hii si sahihi. Viwango viwili vya chini vya maoni, ambayo ni vipimo na upangaji wa jozi, hufanya kazi. Sio kamili kama katika maendeleo ya jadi, lakini kuna athari nzuri kutoka kwake.

Majaribio, katika hali yake ya sasa, hutoa ufunikaji wa msimbo kwa sehemu tu. Vitendaji vingi vya usanidi huishia bila kujaribiwa. Ushawishi wao juu ya kazi halisi wakati wa kuandika msimbo ni mdogo. Walakini, kuna athari kutoka kwa vipimo vya ujumuishaji, na hukuruhusu kutekeleza urekebishaji bila woga. Haya ni mafanikio makubwa. Pia, pamoja na mabadiliko ya mwelekeo kwa maendeleo katika lugha za kiwango cha juu (tuna python, nenda), shida huisha. Na hauitaji ukaguzi mwingi wa "gundi"; ukaguzi wa jumla wa ujumuishaji unatosha.

Kufanya kazi kwa jozi inategemea zaidi watu maalum. Kuna kipengele cha kazi na ujuzi wetu laini. Kwa watu wengine hufanya kazi vizuri sana, na wengine hufanya kazi mbaya zaidi. Hakika kuna faida kutoka kwa hii. Ni wazi kwamba hata kama sheria za kazi ya jozi hazizingatiwi vya kutosha, ukweli wa kufanya kazi pamoja una athari nzuri juu ya ubora wa matokeo. Binafsi, ninaona kufanya kazi katika jozi kuwa rahisi na kufurahisha zaidi.

Njia za kiwango cha juu za kushawishi Mfumo wa Uendeshaji - kupanga na kufanya kazi na kazi huleta athari: ubadilishanaji wa maarifa wa hali ya juu na uboreshaji wa ubora wa maendeleo.

Hitimisho fupi katika mstari mmoja

• Wataalamu wa Utumishi wanafanya kazi katika IaC, lakini kwa ufanisi mdogo.
• Imarisha kile kinachofanya kazi.
• Njoo na mbinu na mazoea yako ya kufidia.

Chanzo: mapenzi.com