Ripoti itazungumza kuhusu baadhi ya mazoea ya DevOps, lakini kutoka kwa mtazamo wa msanidi programu. Kwa kawaida, wahandisi wote wanaojiunga na DevOps tayari wana uzoefu wa miaka kadhaa wa utawala chini ya ukanda wao. Lakini hii haimaanishi kuwa hakuna mahali pa msanidi programu hapa. Mara nyingi zaidi, wasanidi programu wanashughulika kurekebisha "kidudu kifuatacho muhimu cha siku," na hawana wakati wa kuangalia haraka uga wa DevOps. Kwa ufahamu wa mwandishi, DevOps ni, kwanza, akili ya kawaida. Pili, ni fursa ya kuwa na ufanisi zaidi. Ikiwa wewe ni msanidi programu, una akili timamu na unataka kuwa bora zaidi kama mchezaji wa timu, ripoti hii ni kwa ajili yako.
Ngoja nijitambulishe, nakiri kabisa kuwa kuna watu chumbani hawanijui. Jina langu ni Anton Boyko, mimi ni Microsoft Azure MVP. MVP ni nini? Hii ni Model-View-Presenter. Model-View-Presenter ni mimi haswa.
Kwa kuongezea, kwa sasa ninashikilia nafasi ya mbunifu wa suluhisho huko Ciklum. Na hivi majuzi nilijinunulia kikoa kizuri kama hicho, na nilisasisha barua pepe yangu, ambayo mimi huonyesha kwenye maonyesho. Unaweza kuniandikia kwa: me [mbwa] byokoant.pro. Unaweza kuniandikia maswali. Mimi huwa huwajibu. Jambo pekee ni kwamba nisingependa kupokea maswali kwa barua pepe ambayo yanahusiana na mada mbili: siasa na dini. Unaweza kuniandikia kuhusu kila kitu kingine kwa barua pepe. Muda utapita, nitajibu.
Maneno machache kuhusu wewe mwenyewe:
- Nimekuwa kwenye uwanja huu kwa miaka 10 sasa.
- Nilifanya kazi katika Microsoft.
- Mimi ndiye baba mwanzilishi wa jumuiya ya Kiukreni ya Azure, ambayo tulianzisha mahali fulani mwaka wa 2014. Na bado tunayo na tunayaendeleza.
- Mimi pia ni baba wa mwanzilishi wa mkutano wa Azure, ambao tunaandaa nchini Ukrainia.
- Pia ninasaidia kupanga Kambi ya Kimataifa ya Azure Bootcamp huko Kyiv.
- Kama nilivyosema, mimi ni MVP ya Microsoft Azure.
- Ninazungumza kwenye mikutano mara nyingi sana. Ninapenda sana kuzungumza kwenye mikutano. Katika mwaka uliopita niliweza kuigiza takriban mara 40. Ikiwa unapita Ukraine, Belarus, Poland, Bulgaria, Sweden, Denmark, Uholanzi, Hispania au kutoa au kuchukua nchi nyingine katika Ulaya, basi inawezekana kabisa kwamba unapoenda kwenye mkutano ambao una mandhari ya wingu katika mkondo wake, unaweza kuniona kwenye orodha ya wazungumzaji.
- Mimi pia ni shabiki wa Star Trek.
Hebu tuzungumze kidogo kuhusu Agenda. Agenda yetu ni rahisi sana:
- Tutazungumza juu ya DevOps ni nini. Hebu tuzungumze kwa nini hii ni muhimu. Hapo awali, DevOps lilikuwa neno muhimu uliloandika kwenye wasifu wako na ukapokea mshahara wa +$500. Sasa unahitaji kuandika, kwa mfano, blockchain katika wasifu wako ili kupata +500 dola kwa mshahara wako.
- Na kisha, tunapoelewa kidogo juu ya hii ni nini, tutazungumza juu ya mazoea ya DevOps ni nini. Lakini sio sana katika muktadha wa DevOps kwa ujumla, lakini kuhusu mazoea hayo ya DevOps ambayo yanaweza kuwa ya kupendeza kwa wasanidi. Nitakuambia kwa nini wanaweza kukuvutia. Nitakuambia kwa nini unapaswa kufanya hivi kabisa na jinsi inaweza kukusaidia kupata maumivu kidogo.
Picha ya jadi ambayo watu wengi huonyesha. Hivi ndivyo inavyotokea katika miradi mingi. Huu ndio wakati tuna idara za ukuzaji na utendakazi zinazotumia programu yetu. Na idara hizi haziwasiliani.
Pengine, ikiwa hukuweza kuhisi hivyo kwa uwazi katika idara za DevOps na uendeshaji, unaweza kuchora mlinganisho na idara za Dev na QA. Kuna watu ambao wanatengeneza programu na kuna watu wa QA ambao ni wabaya kutoka kwa maoni ya watengenezaji. Kwa mfano, ninaweka nambari yangu nzuri kwenye hazina, na kuna mlaghai fulani ameketi hapo ambaye ananirudishia nambari hii na kusema kuwa nambari yako ni mbaya.
Haya yote hutokea kwa sababu watu hawawasiliani. Na wanatupa vifurushi kadhaa, maombi kwa kila mmoja kupitia ukuta fulani wa kutokuelewana na kujaribu kufanya kitu nao.
Ni hasa ukuta huu ambao utamaduni wa DevOps umeundwa kuharibu, i.e. kuwalazimisha watu kuwasiliana wao kwa wao na angalau kuelewa kile ambacho watu tofauti katika mradi hufanya na kwa nini kazi yao ni muhimu.
Na tunapozungumza kuhusu DevOps, mtu atakuambia kuwa DevOps ni wakati mradi una ushirikiano unaoendelea; mtu atasema kuwa DevOps ni ikiwa mradi unatumia mazoezi ya "miundombinu kama kanuni"; mtu atasema kwamba hatua ya kwanza kwa DevOps ni kipengele cha matawi, bendera za kipengele.
Kimsingi, hii yote ni kweli kwa njia yake mwenyewe. Lakini haya ni mazoea ya mwisho tuliyo nayo. Kabla ya kuendelea na mazoea haya, ninapendekeza kutazama slaidi hii, ambayo inaonyesha hatua 3 za kutekeleza mbinu ya Dev-Ops katika mradi wako, katika kampuni yako.
Slaidi hii pia ina jina la pili lisilo rasmi. Unaweza kutafuta mtandaoni ili kujua Musketeers 3 wa DevOps ni nini. Inawezekana kwamba utapata makala hii. Kwa nini Musketeers 3? Chini inasema: watu, taratibu na bidhaa, i.e. PPP - Porthos, Porthos na Porthos. Hawa hapa Musketeers 3 wa DevOps. Nakala hii inaelezea kwa undani zaidi kwa nini hii ni muhimu na inahusu nini.
Unapoanza kutekeleza utamaduni wa DevOps, ni muhimu sana kwamba utekelezwe kwa utaratibu ufuatao.
Awali unahitaji kuzungumza na watu. Na unahitaji kueleza kwa watu ni nini na jinsi gani wanaweza kupata baadhi ya faida kutoka humo.
Mkutano wetu unaitwa DotNet Fest. Na kama waandaaji walivyoniambia, tulialika hadhira ya watengenezaji hapa, kwa hivyo ninatumai kuwa watu wengi kwenye ukumbi wanahusika katika maendeleo.
Tutazungumza juu ya watu, tutazungumza juu ya kile watengenezaji wanataka kufanya kila siku. Wanataka nini zaidi? Wanataka kuandika msimbo mpya, kutumia mifumo mpya, kuunda vipengele vipya. Je, watengenezaji wanataka nini kidogo? Rekebisha makosa ya zamani. Natumai unakubaliana nami. Hivi ndivyo watengenezaji wanataka. Wanataka kuandika vipengele vipya, hawataki kurekebisha hitilafu.
Idadi ya mende ambayo msanidi fulani hutoa inategemea jinsi mikono yake ilivyo sawa na ni kiasi gani inakua kutoka kwa mabega yake, na si kutoka kwenye mifuko yake ya kitako. Lakini hata hivyo, tunapokuwa na mradi mkubwa, wakati mwingine hutokea kwamba haiwezekani kufuatilia kila kitu, hivyo itakuwa nzuri kwetu kutumia baadhi ya mbinu ambazo zitatusaidia kuandika kanuni imara zaidi na ya juu zaidi.
QAs wanataka nini zaidi? Sijui kama wapo ukumbini. Ni vigumu kwangu kusema kwamba nataka QA, kwa sababu sijawahi kuwa moja. Na hakuna kosa kwa wavulana, itasemwa kuwa natumai sitawahi. Lakini si kwa sababu ninaona kazi yao haina maana na haina maana, lakini kwa sababu sijioni kuwa mtu ambaye angeweza kufanya kazi hii kwa ufanisi, kwa hiyo sitajaribu hata kuifanya. Lakini kutokana na kile ninachoelewa, kile ambacho QA haipendi zaidi ni kwenda kufanya kazi asubuhi, mara kwa mara kuendesha aina fulani za vipimo vya urekebishaji, kukanyaga mende zile zile ambazo waliripoti kwa watengenezaji mbio 3 zilizopita na kusema: "Utawahi lini. , Monsieur D 'Artagnan, rekebisha hitilafu hii.' Na Monsieur D'Artagnan anamjibu: "Ndiyo, ndiyo, ndiyo, tayari nimeshairekebisha." Na jinsi inavyotokea kwamba nilirekebisha mdudu mmoja na kufanya 5 njiani.
Watu wanaounga mkono suluhisho hili katika uzalishaji wanataka suluhisho hili lifanye kazi bila mende, ili wasifanye upya seva kila Ijumaa, wakati watu wote wa kawaida wanakwenda kwenye bar. Wasanidi programu waliotumwa siku ya Ijumaa, wasimamizi hukaa hadi Jumamosi, wakijaribu kutayarisha na kurekebisha utumaji huu.
Na unapowaelezea watu kuwa wanalenga kutatua matatizo sawa, unaweza kuendelea na kurasimisha taratibu. Ni muhimu sana. Kwa nini? Kwa sababu tunaposema "kurasimisha," ni muhimu kwako kuelezea jinsi michakato yako hutokea angalau mahali fulani kwenye kitambaa. Unahitaji kuelewa kwamba ikiwa, kwa mfano, unapeleka kwa mazingira ya QA au mazingira ya uzalishaji, basi kila wakati hufanyika kwa mpangilio huu; katika hatua hizi tunaendesha, kwa mfano, vipimo vya kitengo otomatiki na vipimo vya UI. Baada ya kupelekwa, tunaangalia kama upelekaji ulikwenda vizuri au hafifu. Lakini tayari unayo orodha ya wazi ya vitendo ambayo lazima irudiwe tena na tena unapopeleka kwenye uzalishaji.
Na tu wakati michakato yako imerasimishwa, unaanza kuchagua bidhaa ambazo zitakusaidia kubinafsisha michakato hii.
Kwa bahati mbaya, mara nyingi mimi huona hii ikitokea kinyume chake. Mara tu mtu anaposikia neno "DevOps", anapendekeza mara moja kusakinisha Jenkins, kwa sababu wanaamini kwamba mara tu watakapoweka Jenkins, watakuwa na DevOps. Waliweka Jenkins, wakasoma nakala za "Jinsi ya" kwenye wavuti ya Jenkins, walijaribu kuingiza michakato kwenye nakala hizi, kisha wakaja kwa watu na kuwainamisha watu, wakisema kwamba kitabu kinasema kwamba unahitaji kuifanya kwa njia hii, kwa hivyo tunafanya hivi.
Sio kwamba Jenkins ni zana mbaya. Simaanishi kusema hivyo kwa njia yoyote. Lakini hii ni moja tu ya bidhaa. Na ni bidhaa gani unayotumia inapaswa kuwa uamuzi wako wa mwisho, na sio wa kwanza kwako. Bidhaa yako haipaswi kuendeshwa na utekelezaji wa utamaduni na mbinu. Hii ni muhimu sana kuelewa, ndiyo sababu ninatumia muda mwingi kwenye slide hii na kuelezea haya yote kwa muda mrefu.
Wacha tuzungumze juu ya mazoea ya DevOps kwa ujumla. Wao ni kina nani? Tofauti ni nini? Jinsi ya kuwajaribu? Kwa nini ni muhimu?
Zoezi la kwanza ambalo huenda umesikia linaitwa Continuous Integration. Labda mtu kwenye mradi ana Ujumuishaji Unaoendelea (CI).
Shida kubwa ni kwamba mara nyingi ninapouliza mtu: "Je! una CI kwenye mradi?" na anasema: "Ndiyo," basi ninapouliza anachofanya, ananielezea kabisa mchakato mzima wa automatisering. Hii si kweli kabisa.
Kwa kweli, mazoezi ya CI yanalenga tu kuunganisha nambari ambayo watu tofauti huandika katika aina fulani ya msingi wa nambari moja. Ni hayo tu.
Pamoja na CI, kwa kawaida kuna mazoea mengine njiani - kama vile Usambazaji Kuendelea, Usimamizi wa Utoaji, lakini tutazungumza juu yake baadaye.
CI yenyewe inatuambia kwamba watu tofauti huandika msimbo na msimbo huu lazima uunganishwe mara kwa mara katika msingi mmoja wa msimbo.
Hii inatupa nini na kwa nini ni muhimu? Ikiwa tunayo DotNet, basi hiyo ni nzuri, ni lugha iliyokusanywa, tunaweza kukusanya maombi yetu. Ikiwa inakusanya, basi hii tayari ni ishara nzuri. Hii haimaanishi chochote bado, lakini ni ishara nzuri ya kwanza ambayo tunaweza angalau kukusanya.
Kisha tunaweza kuendesha majaribio kadhaa, ambayo pia ni mazoezi tofauti. Vipimo vyote ni vya kijani - hii ni ishara ya pili nzuri. Lakini tena, hii haimaanishi chochote.
Lakini kwa nini ungefanya hivi? Mazoea yote ambayo nitazungumza juu ya leo yana takriban thamani sawa, yaani takriban faida sawa na pia hupimwa takriban kwa njia sawa.
Kwanza, inakuwezesha kuharakisha utoaji. Je, hii inakuwezeshaje kuharakisha utoaji? Tunapofanya mabadiliko mapya kwenye msingi wetu wa msimbo, tunaweza kujaribu mara moja kufanya jambo kwa kutumia msimbo huu. Hatungoji hadi Alhamisi ifike kwa sababu Alhamisi tunaitoa kwa QA Environment, tunaifanya hapa na hapa hapa.
Nitakuambia hadithi moja ya kusikitisha kutoka kwa maisha yangu. Ilikuwa ni muda mrefu uliopita, nilipokuwa bado mdogo na mzuri. Sasa mimi tayari ni mchanga, mrembo na mwerevu, na mwenye kiasi. Wakati fulani uliopita nilikuwa kwenye mradi. Tulikuwa na timu kubwa ya watengenezaji wapatao 30. Na tulikuwa na mradi mkubwa, mkubwa wa Biashara ulioendelezwa kwa takriban miaka 10. Na tulikuwa na matawi tofauti. Katika hazina tulikuwa na tawi ambalo watengenezaji walitembea. Na kulikuwa na tawi ambalo lilionyesha toleo la msimbo ambalo liko katika uzalishaji.
Tawi la uzalishaji lilikuwa miezi 3 nyuma ya tawi ambalo lilipatikana kwa watengenezaji. Hii ina maana gani? Hii inamaanisha kwamba mara tu ninapokuwa na mdudu mahali fulani ambao huenda kwa uzalishaji kwa sababu ya kosa la watengenezaji, kwa sababu waliruhusu, na kwa sababu ya kosa la QA, kwa sababu waliiangalia, basi hii inamaanisha kwamba ikiwa nitapokea task kwa hotfix kwa uzalishaji, basi lazima nirudishe mabadiliko ya nambari yangu miezi 3 iliyopita. Lazima nikumbuke niliyokuwa nayo miezi 3 iliyopita na kujaribu kurekebisha hapo.
Ikiwa bado hujapata uzoefu huu, unaweza kujaribu kwenye mradi wako wa nyumbani. Jambo kuu ni, usijaribu kwenye biashara. Andika mistari kadhaa ya msimbo, sahau kuihusu kwa muda wa miezi sita, kisha urudi na ujaribu kueleza kwa haraka ni nini mistari hiyo ya msimbo inahusu na jinsi unavyoweza kuirekebisha au kuiboresha. Ni uzoefu wa kusisimua sana.
Ikiwa tuna mazoezi ya Kuendelea ya Ujumuishaji, basi hii huturuhusu kuikagua kwa zana kadhaa za kiotomatiki hapa na sasa hivi, mara tu ninapoandika nambari yangu. Hili linaweza lisinipe picha kamili, lakini hata hivyo, litaondoa angalau baadhi ya hatari. Na ikiwa kuna mdudu yeyote anayewezekana, nitajua juu yake sasa hivi, ambayo ni, katika dakika chache. Sitahitaji kurudi nyuma kwa miezi 3. Nitahitaji tu kurudi nyuma kwa dakika 2. Mashine nzuri ya kahawa haitakuwa na wakati wa kutengeneza kahawa kwa dakika 2, kwa hivyo ni nzuri sana.
Hii ina thamani ambayo inaweza kurudiwa mara kwa mara kwenye kila mradi, i.e. sio tu ile uliyoiweka. Unaweza kurudia mazoezi yenyewe na CI yenyewe itarudiwa kwa kila mabadiliko mapya utakayofanya kwenye mradi. Hii hukuruhusu kuboresha rasilimali kwa sababu timu yako inafanya kazi kwa ufanisi zaidi. Hutakuwa tena na hali ambapo hitilafu inakuja kwako kutoka kwa nambari uliyofanya kazi nayo miezi 3 iliyopita. Hutakuwa tena na ubadilishaji wa muktadha unapokaa na kutumia saa mbili za kwanza kujaribu kuelewa kilichotokea kisha kuingia katika kiini cha muktadha kabla ya kuanza kusahihisha kitu.
Je, tunawezaje kupima mafanikio au kushindwa kwa mazoezi haya? Ukiripoti kwa bwana mkubwa kile tulichotekeleza kwenye mradi wa CI, anasikia blah blah blah. Tuliitekeleza, sawa, lakini kwa nini, ilituletea nini, tunaipimaje, tunaitekeleza kwa usahihi au isivyo?
Ya kwanza ni kwamba, kwa shukrani kwa CI, tunaweza kupeleka mara nyingi zaidi na zaidi, na mara nyingi kwa usahihi kwa sababu nambari yetu inaweza kuwa thabiti zaidi. Kwa njia hiyo hiyo, wakati wetu wa kupata hitilafu umepunguzwa na wakati wa kurekebisha kosa hili umepunguzwa kwa usahihi kwa sababu tunapokea jibu kutoka kwa mfumo hapa na sasa hivi, ni nini kibaya na kanuni yetu.
Mazoezi mengine tuliyo nayo ni Majaribio ya Kiotomatiki, ambayo mara nyingi huja na mazoezi ya CI. Wanaenda kwa mkono.
Ni nini muhimu kuelewa hapa? Ni muhimu kuelewa kwamba vipimo vyetu ni tofauti. Na kila mtihani wa automatiska unalenga kutatua matatizo yake mwenyewe. Tuna, kwa mfano, vipimo vya kitengo vinavyotuwezesha kupima moduli tofauti, i.e. Inafanyaje kazi katika utupu? Hii ni nzuri.
Pia tuna majaribio ya ujumuishaji ambayo huturuhusu kuelewa jinsi moduli tofauti huunganishwa. Pia ni nzuri.
Tunaweza kuwa na majaribio ya otomatiki ya UI ambayo huturuhusu kuangalia jinsi kazi ya UI inavyokidhi mahitaji fulani yaliyowekwa na mteja, nk.
Majaribio mahususi unayofanya yanaweza kuathiri mara ngapi unayaendesha. Vipimo vya kitengo kawaida huandikwa kwa kifupi na kidogo. Na wanaweza kuzinduliwa mara kwa mara.
Ikiwa tunazungumza juu ya majaribio ya otomatiki ya UI, basi ni vizuri ikiwa mradi wako ni mdogo. Majaribio yako ya otomatiki ya UI yanaweza kuchukua muda wa kutosha. Lakini kawaida mtihani wa otomatiki wa UI ni kitu ambacho huchukua masaa kadhaa kwenye mradi mkubwa. Na ni vizuri ikiwa ni masaa machache. Jambo pekee ni kwamba hakuna maana katika kuziendesha kwa kila jengo. Ni mantiki kuwaendesha usiku. Na kila mtu alipokuja kazini asubuhi: wajaribu na wasanidi, walipokea aina fulani ya ripoti kwamba tuliendesha jaribio la kiotomatiki la UI usiku na kupata matokeo haya. Na hapa, saa ya kazi ya seva ambayo itahakikisha kuwa bidhaa yako inakidhi mahitaji fulani itakuwa nafuu zaidi kuliko saa moja ya kazi ya mhandisi huyo wa QA, hata kama ni mhandisi wa Junior QA ambaye anafanya kazi kwa chakula na shukrani. Vivyo hivyo, saa ya operesheni ya mashine itakuwa nafuu. Ndiyo maana ni busara kuwekeza ndani yake.
Nina mradi mwingine ambao nimekuwa nikifanya kazi. Tulikuwa na mbio za wiki mbili kwenye mradi huu. Mradi ulikuwa mkubwa, muhimu kwa sekta ya fedha, na kosa halikuweza kufanywa. Na baada ya kukimbia kwa wiki mbili, mzunguko wa maendeleo ulifuatiwa na mchakato wa kupima, ambao ulichukua wiki 4 nyingine. Jaribu kufikiria ukubwa wa mkasa huo. Tunaandika msimbo kwa wiki mbili, kisha tunaifanya ala CodeFreeze, ifungwe katika toleo jipya la programu, na kuisambaza kwa wanaojaribu. Wanaojaribu kupima kwa wiki nyingine 4, i.e. Wakati wanaijaribu, tuna wakati wa kuwaandalia matoleo mawili zaidi. Hii ni kesi ya kusikitisha sana.
Na tuliwaambia kwamba ikiwa unataka kuwa na tija zaidi, ni jambo la busara kwako kutekeleza mazoea ya Kujaribu Kiotomatiki, kwa sababu hii ndiyo inayokuumiza papa hapa, hivi sasa.
Fanya Mazoezi ya Usambazaji Unaoendelea. Mkuu, umemaliza kujenga. Hii tayari ni nzuri. Msimbo wako umekusanya. Sasa itakuwa nzuri kupeleka muundo huu kwenye mazingira fulani. Wacha tuseme katika mazingira ya watengenezaji.
Kwa nini ni muhimu? Kwanza, unaweza kuangalia jinsi umefanikiwa na mchakato wa kupeleka yenyewe. Nimekutana na miradi kama hii, ninapouliza: "Unasambazaje toleo jipya la programu?", wavulana huniambia: "Tunaikusanya na kuipakia kwenye kumbukumbu ya zip. Tunatuma kwa msimamizi kwa barua. Msimamizi anapakua na kupanua kumbukumbu hii. Na ofisi nzima inaanza kuomba kwamba seva itachukua toleo jipya.
Wacha tuanze na kitu rahisi. Kwa mfano, walisahau kuweka CSS kwenye kumbukumbu au walisahau kubadilisha alama ya reli katika jina la faili la java-script. Na tunapofanya ombi kwa seva, kivinjari kinafikiri kwamba tayari ina faili hii ya hati ya java na inaamua kutoipakua. Na kulikuwa na toleo la zamani, kitu kilikosekana. Kwa ujumla, kunaweza kuwa na matatizo mengi. Kwa hivyo, zoezi la Usambazaji Endelevu hukuruhusu kujaribu angalau kile ambacho kingetokea ikiwa utachukua picha safi ya marejeleo na kuipakia kwenye mazingira safi kabisa. Unaweza kuona ambapo hii inaongoza.
Pia, unapounganisha msimbo kati ya kila mmoja, i.e. kati ya amri, hii hukuruhusu kuona pia jinsi inavyoonekana kwenye UI.
Shida moja ambayo hutokea ambapo maandishi mengi ya java ya vanilla hutumiwa ni kwamba watengenezaji wawili walitangaza upesi kutofautisha na jina moja kwenye kitu cha dirisha. Na kisha, kulingana na bahati yako. Ambao faili ya hati ya java imetolewa kwa pili itafuta mabadiliko ya nyingine. Pia inasisimua sana. Unaingia: kitu kimoja kinafanya kazi kwa mtu mmoja, mwingine haifanyi kazi kwa mwingine. Na ni "ya ajabu" wakati yote yanatoka katika uzalishaji.
Mazoezi yanayofuata tuliyo nayo ni mazoezi ya Urejeshaji Kiotomatiki, yaani, kurudi kwenye toleo la awali la programu.
Kwa nini hii ni muhimu kwa wasanidi programu? Bado kuna wale wanaokumbuka miaka ya 90 ya mbali, wakati kompyuta zilikuwa kubwa na programu zilikuwa ndogo. Na njia pekee ya ukuzaji wa wavuti ilikuwa kupitia PHP. Sio kwamba PHP ni lugha mbaya, ingawa ni.
Lakini tatizo lilikuwa tofauti. Tulipotuma toleo jipya la tovuti yetu ya php, tuliitumiaje? Mara nyingi tulifungua Meneja wa Mbali au kitu kingine. Na kupakia faili hizi kwa FTP. Na ghafla tuligundua kuwa tulikuwa na mdudu mdogo, mdogo, kwa mfano, tulisahau kuweka semicolon au kusahau kubadilisha nenosiri kwa hifadhidata, na kuna nenosiri la hifadhidata, ambalo liko kwenye mwenyeji wa ndani. Na tunaamua kuunganisha haraka kwa FTP na kuhariri faili hapo hapo. Huu ni moto tu! Hii ndio ilikuwa maarufu katika miaka ya 90.
Lakini, ikiwa haujaangalia kalenda, miaka ya 90 ilikuwa karibu miaka 30 iliyopita. Sasa kila kitu kinatokea tofauti kidogo. Na jaribu kufikiria ukubwa wa janga hilo wanapokuambia: "Tulitumwa kwa uzalishaji, lakini kuna kitu kilienda vibaya hapo. Hapa kuna kuingia na nenosiri lako la FTP, unganisha kwenye toleo la umma na urekebishe hapo haraka." Ikiwa wewe ni Chuck Norris, hii itafanya kazi. Ikiwa sio, basi una hatari kwamba ukitengeneza mdudu mmoja, utafanya zaidi 10. Ndiyo maana mazoezi haya ya kurudi kwenye toleo la awali inakuwezesha kufikia mengi.
Hata kama kitu kibaya kwa namna fulani kiliingia kwenye prod mahali fulani, basi ni mbaya, lakini sio mbaya. Unaweza kurudi kwenye toleo la awali ulilonalo. Iite nakala rudufu, ikiwa ni rahisi kuitambua katika istilahi hiyo. Unaweza kurejesha toleo hili la awali, na watumiaji bado wataweza kufanya kazi na bidhaa yako, na utakuwa na muda wa kutosha wa bafa. Unaweza kwa utulivu, bila haraka, kuchukua yote haya na kuyajaribu ndani ya nchi, kurekebisha, na kisha kupakia toleo jipya. Inaleta maana sana kufanya hivi.
Sasa hebu tujaribu kuchanganya kwa namna fulani mazoea mawili ya awali pamoja. Tutapata ya tatu inayoitwa Usimamizi wa Kutolewa.
Tunapozungumza juu ya Usambazaji Unaoendelea katika mfumo wake wa kitamaduni, tunasema kwamba lazima tuchomoe msimbo kutoka kwa tawi fulani kutoka kwa hazina, tuikusanye na kuipeleka. Ni vizuri ikiwa tuna mazingira sawa. Ikiwa tunayo mazingira kadhaa, hii inamaanisha kwamba lazima tuvute nambari kila wakati, hata kutoka kwa ahadi moja. Tutaiondoa kila wakati, tutaijenga kila wakati na tutaipeleka kwa mazingira mapya. Kwanza, huu ni wakati, kwa sababu kujenga mradi, ikiwa una kubwa na ulikuja kutoka miaka ya 90, basi inaweza kuchukua saa kadhaa.
Isitoshe, kuna huzuni nyingine. Unapojenga, hata kwenye mashine hiyo hiyo, utajenga vyanzo sawa, bado huna uhakika kwamba mashine hii iko katika hali sawa na ilivyokuwa wakati wa ujenzi wa mwisho.
Hebu tuseme mtu alikuja na kusasisha DotNet kwa ajili yako au, kinyume chake, mtu aliamua kufuta kitu. Na kisha una ugomvi wa utambuzi kwamba kutoka kwa ahadi hii wiki mbili zilizopita tulikuwa tukiunda jengo na kila kitu kilikuwa sawa, lakini sasa inaonekana kama mashine ile ile, ahadi ile ile, nambari ile ile ambayo tunajaribu kujenga, lakini haifanyi kazi. . Utakuwa ukishughulika na hii kwa muda mrefu na sio ukweli kwamba utaigundua. Kwa uchache, utaharibu mishipa yako sana.
Kwa hivyo, mazoezi ya Kudhibiti Matoleo yanapendekeza kuanzishwa kwa uondoaji wa ziada unaoitwa hazina ya vizalia vya programu au ghala au maktaba. Unaweza kuiita chochote unachotaka.
Wazo kuu ni kwamba mara tu tunapokuwa na aina fulani ya ahadi huko, sema, katika tawi ambalo tuko tayari kupeleka kwa mazingira yetu tofauti, tunakusanya maombi kutoka kwa ahadi hii na kila kitu tunachohitaji kwa programu hii, tunaipakia. kwenye kumbukumbu ya zip na uihifadhi katika hifadhi fulani ya kuaminika. Na kutoka kwa hifadhi hii tunaweza kupata kumbukumbu hii ya zip wakati wowote.
Kisha tunaichukua na kuipeleka kiotomatiki kwa mazingira ya dev. Tunakimbia huko, na ikiwa kila kitu ni nzuri, basi tunapeleka kwenye hatua. Ikiwa kila kitu kiko sawa, basi tunapeleka kumbukumbu sawa kwa uzalishaji, jozi sawa, zilizokusanywa mara moja haswa.
Zaidi ya hayo, tunapokuwa na matunzio kama haya, hutusaidia pia kushughulikia hatari ambazo tulishughulikia kwenye slaidi ya mwisho tulipozungumza kuhusu kurejesha toleo la awali. Iwapo uliweka kitu kibaya kimakosa, unaweza kuchukua toleo lingine lolote la awali kutoka kwa ghala hili wakati wowote na kulisambaratisha kwa mazingira haya kwa njia ile ile. Hii hukuruhusu kurudi kwa urahisi kwenye toleo la awali ikiwa kitu kitaenda vibaya.
Kuna mazoezi mengine makubwa. Wewe na mimi sote tunaelewa kwamba tunaporejesha programu zetu kwenye toleo la awali, hii inaweza kumaanisha kwamba tunahitaji pia muundo msingi wa toleo la awali.
Tunapozungumza kuhusu miundombinu ya mtandaoni, watu wengi hufikiri kwamba hili ni jambo ambalo wasimamizi huanzisha. Na ikiwa unahitaji, sema, kupata seva mpya ambayo unataka kujaribu toleo jipya la programu yako, basi lazima uandike tikiti kwa wasimamizi au watoa huduma. Devops itachukua wiki 3 kwa hili. Na baada ya wiki 3 watakuambia kuwa tumekuwekea mashine ya kawaida, yenye msingi mmoja, gigabytes mbili za RAM na seva ya Windows bila DotNet. Unasema: "Lakini nilitaka DotNet." Wao: "Sawa, rudi baada ya wiki 3."
Wazo ni kwamba kwa kutumia Miundombinu kama mazoea ya Kanuni, unaweza kutibu miundombinu yako pepe kama rasilimali nyingine.
Labda, ikiwa yeyote kati yenu anatengeneza programu kwenye DotNet, unaweza kuwa umesikia kuhusu maktaba inayoitwa Mfumo wa Taasisi. Na labda umesikia kwamba Mfumo wa Taasisi ni mojawapo ya mbinu ambazo Microsoft inasukuma kikamilifu. Kwa kufanya kazi na hifadhidata, hii ni mbinu inayoitwa Code First. Huu ndio wakati unaelezea kwa msimbo jinsi unavyotaka hifadhidata yako ionekane. Na kisha upeleke programu. Inaunganisha kwenye hifadhidata, yenyewe huamua ni meza gani na ni meza gani ambazo hazipo, na huunda kila kitu unachohitaji.
Unaweza kufanya vivyo hivyo na miundombinu yako. Hakuna tofauti kati ya kama unahitaji hifadhidata ya mradi au kama unahitaji seva ya Windows kwa mradi. Ni rasilimali tu. Na unaweza kubinafsisha uundaji wa rasilimali hii, unaweza kubinafsisha usanidi wa rasilimali hii. Ipasavyo, kila wakati unataka kujaribu dhana mpya, mbinu mpya, hautahitaji kuandika tikiti kwa devops, unaweza tu kupeleka miundombinu iliyotengwa kwako kutoka kwa templeti zilizotengenezwa tayari, kutoka kwa hati zilizotengenezwa tayari na utekeleze. kuna majaribio yako yote. Unaweza kufuta hii, kupata baadhi ya matokeo na ripoti zaidi kuihusu.
Zoezi linalofuata, ambalo pia lipo na pia ni muhimu, lakini ambalo watu wachache hutumia, ni Ufuatiliaji wa Utendaji wa Maombi.
Nilitaka kusema jambo moja tu kuhusu Ufuatiliaji wa Utendaji wa Maombi. Ni nini muhimu zaidi kuhusu mazoezi haya? Hivi ndivyo Ufuatiliaji wa Utendaji wa Maombi unakaribia sawa na kukarabati ghorofa. Hii sio hali ya mwisho, ni mchakato. Unahitaji kuifanya mara kwa mara.
Kwa njia nzuri, itakuwa nzuri kutekeleza Ufuatiliaji wa Utendaji wa Maombi kwa karibu kila jengo, ingawa, kama unavyoelewa, hii haiwezekani kila wakati. Lakini, kwa kiwango cha chini, inahitaji kufanywa kwa kila toleo.
Kwa nini ni muhimu? Kwa sababu ikiwa ghafla unapata kushuka kwa utendaji, basi unahitaji kuelewa wazi kwa nini. Ikiwa timu yako ina, tuseme, mbio za wiki mbili, basi angalau mara moja kila wiki mbili unapaswa kupeleka programu yako kwa seva fulani tofauti, ambapo una kichakataji kilichowekwa wazi, RAM, diski, n.k. Na ufanyie majaribio yale yale ya utendaji. . Unapata matokeo. Tazama jinsi imebadilika kutoka kwa mbio zilizopita.
Na ikiwa utagundua kuwa mteremko ulipungua sana mahali fulani, itamaanisha kuwa ni kwa sababu ya mabadiliko yaliyotokea katika wiki mbili zilizopita. Hii itawawezesha kutambua na kurekebisha tatizo kwa kasi zaidi. Na tena, hizi ni takriban vipimo sawa ambavyo unaweza kupima jinsi ulivyoifanya kwa mafanikio.
Zoezi linalofuata tulilo nalo ni mazoezi ya Usimamizi wa Usanidi. Ni wachache sana wanaochukulia hili kwa uzito. Lakini niamini, hili ni jambo zito sana.
Kulikuwa na hadithi ya kuchekesha hivi majuzi. Vijana hao walinijia na kusema: "Tusaidie kufanya ukaguzi wa usalama wa ombi letu." Tuliangalia msimbo pamoja kwa muda mrefu, waliniambia kuhusu maombi, walichora michoro. Na pamoja na au minus kila kitu kilikuwa cha kimantiki, kinachoeleweka, salama, lakini kulikuwa na moja LAKINI! Walikuwa na faili za usanidi katika udhibiti wao wa chanzo, ikiwa ni pamoja na zile za uzalishaji na hifadhidata ya IP, zilizo na anwani na nywila za kuunganisha kwenye hifadhidata hizi, nk.
Nami nasema: "Jamani, sawa, umefunga mazingira yako ya uzalishaji na firewall, lakini ukweli kwamba una kuingia na nenosiri la hifadhidata ya uzalishaji kwenye udhibiti wa chanzo na msanidi programu yeyote anaweza kuisoma tayari ni hatari kubwa ya usalama. . Na haijalishi maombi yako yana usalama wa hali ya juu kutokana na mtazamo wa msimbo, ukiiacha katika udhibiti wa chanzo, basi hutawahi kupita ukaguzi wowote popote." Hiyo ndiyo ninayozungumzia.
Usimamizi wa usanidi. Tunaweza kuwa na usanidi tofauti katika mazingira tofauti. Kwa mfano, tunaweza kuwa na njia tofauti za kuingia na nywila za hifadhidata za QA, onyesho, mazingira ya uzalishaji, n.k.
Usanidi huu unaweza pia kuwa otomatiki. Inapaswa kuwa tofauti na programu yenyewe. Kwa nini? Kwa sababu uliunda programu mara moja, na kisha programu haijalishi ikiwa unaunganisha kwenye seva ya SQL kupitia IP kama hiyo au vile na IP kama hiyo, inapaswa kufanya kazi sawa. Kwa hivyo, ikiwa ghafla mmoja wenu bado anaandika kamba ya uunganisho kwenye msimbo, basi kumbuka kwamba nitakupata na kukuadhibu ikiwa unajikuta kwenye mradi huo na mimi. Hii daima huwekwa katika usanidi tofauti, kwa mfano, katika web.config.
Na usanidi huu tayari unasimamiwa kando, yaani, huu ndio wakati hasa ambapo msanidi programu na msimamizi wanaweza kuja na kuketi katika chumba kimoja. Na msanidi programu anaweza kusema: "Angalia, hizi ni jozi za programu yangu. Wanafanya kazi. Programu inahitaji hifadhidata ili kufanya kazi. Hapa karibu na jozi kuna faili. Katika faili hii, uwanja huu unawajibika kwa kuingia, hii ni kwa nenosiri, hii ni kwa IP. Ipeleke popote." Na ni rahisi na wazi kwa msimamizi. Anaweza kuipeleka popote kwa kudhibiti usanidi huu.
Na mazoezi ya mwisho ambayo ningependa kuzungumzia ni mazoezi ambayo yanahusiana sana na mawingu. Na huleta athari kubwa ikiwa unafanya kazi kwenye wingu. Huu ni uondoaji wa kiotomatiki wa mazingira yako.
Najua kuna watu kadhaa kwenye mkutano huu kutoka kwa timu ninazofanya nazo kazi. Na kwa timu zote ninazofanya nazo kazi, tunatumia mazoezi haya.
Kwa nini? Kwa kweli, itakuwa nzuri ikiwa kila msanidi programu angekuwa na mashine pepe ambayo ingefanya kazi 24/7. Lakini labda hii ni habari kwako, labda haukujali, lakini msanidi programu mwenyewe haifanyi kazi 24/7. Msanidi programu kawaida hufanya kazi masaa 8 kwa siku. Hata akifika kazini mapema, huwa na chakula kingi cha mchana wakati anaenda kwenye mazoezi. Hebu iwe saa 12 kwa siku wakati msanidi anatumia rasilimali hizi. Kulingana na sheria zetu, tuna siku 5 kati ya 7 katika wiki ambazo huchukuliwa kuwa siku za kazi.
Ipasavyo, siku za wiki mashine hii haipaswi kufanya kazi masaa 24, lakini 12 tu, na mwishoni mwa wiki mashine hii haipaswi kufanya kazi kabisa. Inaweza kuonekana kuwa kila kitu ni rahisi sana, lakini ni nini muhimu kusema hapa? Kwa kutekeleza mazoezi haya rahisi kwenye ratiba hii ya kimsingi, hukuruhusu kupunguza gharama ya kudumisha mazingira haya kwa 70%, yaani, ulichukua bei ya dev, QA, demo, mazingira na kuigawanya kwa 3.
Swali ni, nini cha kufanya na pesa iliyobaki? Kwa mfano, watengenezaji wanapaswa kununua ReSharper ikiwa bado hawajanunua. Au fanya karamu. Ikiwa hapo awali ulikuwa na mazingira ambayo dev na QA walilisha, na ndivyo ilivyo, sasa unaweza kutengeneza 3 tofauti ambazo zitatengwa, na watu hawataingiliana.
Kuhusu slaidi yenye kipimo endelevu cha utendakazi, tunawezaje kulinganisha utendakazi ikiwa tungekuwa na rekodi 1 kwenye hifadhidata katika mradi, miezi miwili baadaye kuna milioni? Jinsi ya kuelewa kwa nini na ni hatua gani ya kupima utendaji?
Hili ni swali zuri, kwa sababu unapaswa kupima utendaji kila wakati kwenye rasilimali sawa. Hiyo ni, unatoa nambari mpya, unapima utendaji kwenye nambari mpya. Kwa mfano, unahitaji kujaribu hali tofauti za utendaji, tuseme unataka kujaribu jinsi programu inavyofanya kazi kwenye mzigo mdogo, ambapo kuna watumiaji 1 na saizi ya hifadhidata ni gigabytes 000. Ulipima na kupata nambari. Ifuatayo, tunachukua hali nyingine. Kwa mfano, watumiaji 5, ukubwa wa hifadhidata 5 terabyte. Tulipokea matokeo na kuyakumbuka.
Nini muhimu hapa? Jambo muhimu hapa ni kwamba kulingana na hali, kiasi cha data, idadi ya watumiaji wa wakati huo huo, nk, unaweza kukimbia kwenye mipaka fulani. Kwa mfano, kwa kikomo cha kadi ya mtandao, au kwa kikomo cha gari ngumu, au kwa kikomo cha uwezo wa processor. Hili ndilo muhimu kwako kuelewa. Katika hali tofauti unaingia kwenye mipaka fulani. Na unahitaji kuelewa nambari wakati unazipiga.
Je, tunazungumzia kupima utendaji katika mazingira maalum ya mtihani? Hiyo ni, hii sio uzalishaji?
Ndiyo, hii sio uzalishaji, hii ni mazingira ya mtihani, ambayo daima ni sawa ili uweze kuilinganisha na vipimo vya awali.
Nimeelewa asante!
Ikiwa hakuna maswali, nadhani tunaweza kumaliza. Asante!
Chanzo: mapenzi.com