Wacha tujadili kwa nini zana za CI na CI ni vitu tofauti kabisa.
Ni maumivu gani ambayo CI imekusudiwa kutatua, wazo lilitoka wapi, ni uthibitisho gani wa hivi karibuni ambao unafanya kazi, jinsi ya kuelewa kuwa una mazoezi na sio tu kusakinisha Jenkins.
Wazo la kutoa ripoti kuhusu Ushirikiano Unaoendelea lilionekana mwaka mmoja uliopita, nilipokuwa nikienda kwa mahojiano na kutafuta kazi. Nilizungumza na makampuni 10-15, mmoja wao tu ndiye aliyeweza kujibu wazi ni nini CI na kueleza jinsi walivyogundua kuwa hawakuwa nayo. Wengine walikuwa wakizungumza upuuzi usioeleweka kuhusu Jenkins :) Naam, tuna Jenkins, inajenga, CI! Wakati wa ripoti, nitajaribu kueleza ni nini Ushirikiano wa Kuendelea na kwa nini Jenkins na zana zinazofanana zina uhusiano dhaifu sana na hili.
Kwa hivyo, ni nini kawaida huja akilini unaposikia neno CI? Watu wengi watafikiria Jenkins, Gitlab CI, Travis, nk.
Hata tukigoogle, itatupatia zana hizi.
Ikiwa unajua kuuliza, basi mara baada ya kuorodhesha zana, watakuambia kuwa CI ni wakati unaunda na kuendesha majaribio katika Ombi la Kuvuta kwa ahadi.
Ushirikiano unaoendelea sio juu ya zana, sio juu ya makusanyiko yenye vipimo kwenye tawi! Ujumuishaji unaoendelea ni mazoezi ya ujumuishaji wa mara kwa mara wa nambari mpya na kuitumia sio lazima hata kidogo kuweka uzio Jenkins, GitLab, nk.
Kabla hatujagundua jinsi CI iliyojaa inavyoonekana, hebu kwanza tuzame muktadha wa watu walioibuka na kuhisi uchungu waliyokuwa wakijaribu kutatua.
Na walitatua uchungu wa kufanya kazi pamoja kama timu!
Wacha tuangalie mifano ya ugumu wa watengenezaji wanapokua katika timu. Hapa tuna mradi, tawi kuu katika git na watengenezaji wawili.
Nao waliingia kazini kama kila mtu alikuwa amezoea. Tulichukua jukumu katika mpango mkuu wa mambo, tukaunda tawi la kipengele, na tukaandika msimbo.
Mtu alimaliza kipengele haraka na akakiunganisha kwenye bwana.
Ya pili ilihitaji muda zaidi, iliunganishwa baadaye na kuishia na mgogoro. Sasa, badala ya kuandika vipengele ambavyo biashara inahitaji, msanidi hutumia muda wake na nishati kutatua migogoro.
Ni vigumu zaidi kuchanganya kipengele chako na bwana wa kawaida, wakati zaidi tunatumia juu yake. Na nilionyesha hii kwa mfano rahisi. Huu ni mfano ambapo kuna wasanidi 2 pekee. Hebu fikiria ikiwa watu 10 au 15 au 100 katika kampuni wanaandikia hazina moja. Utakuwa wazimu kutatua migogoro hii yote.
Kuna kesi tofauti kidogo. Tuna bwana na baadhi ya watengenezaji kufanya kitu.
Waliunda tawi.
Mmoja alikufa, kila kitu kilikuwa sawa, alipitisha kazi hiyo.
Msanidi wa pili, wakati huo huo, alikabidhi kazi yake. Wacha tuseme aliituma kwa ukaguzi. Makampuni mengi yana mazoezi yanayoitwa mapitio. Kwa upande mmoja, mazoezi haya ni nzuri na yenye manufaa, kwa upande mwingine, inatupunguza kwa njia nyingi. Hatutaingia katika hilo, lakini hapa kuna mfano mzuri wa nini hadithi mbaya ya ukaguzi inaweza kusababisha. Umewasilisha ombi la kuvuta kwa ukaguzi. Hakuna kingine cha kufanya kwa msanidi programu. Anaanza kufanya nini? Anaanza kuchukua majukumu mengine.
Wakati huu, msanidi wa pili alifanya kitu kingine.
Wa kwanza alikamilisha kazi ya tatu.
Na baada ya muda mrefu, hakiki yake ilijaribiwa, na anajaribu kukubaliana. Kwa hiyo nini kinaendelea? Inashika idadi kubwa ya migogoro. Kwa nini? Kwa sababu wakati ombi lake la kuvuta lilikuwa likining'inia kwenye ukaguzi, mambo mengi yalikuwa tayari yamebadilika katika kanuni.
Mbali na hadithi yenye migogoro, kuna hadithi yenye mawasiliano. Wakati nyuzi yako inakaguliwa, wakati inangojea kitu, wakati unashughulikia kipengele kwa muda mrefu, unaacha kufuatilia ni nini kingine kinachobadilika katika msingi wa nambari ya huduma yako. Labda kile unachojaribu kutatua sasa kilikuwa tayari kimetatuliwa jana na unaweza kuchukua njia fulani na kuitumia tena. Lakini hautaona hii kwa sababu unafanya kazi kila wakati na tawi la zamani. Na tawi hili lililopitwa na wakati daima husababisha wewe kusuluhisha mzozo wa kuunganisha.
Inabadilika kuwa ikiwa tunafanya kazi kama timu, i.e., sio mtu mmoja anayezunguka kwenye hazina, lakini watu 5-10, basi kadiri tunavyozidi kutoongeza nambari yetu kwa bwana, ndivyo tunavyoteseka kwa sababu mwishowe tunahitaji. kitu kisha unganisha. Na kadiri tunavyokuwa na mizozo, na toleo la zamani tunalofanya kazi nalo, ndivyo tunavyokuwa na matatizo.
Kufanya kitu pamoja ni chungu! Daima tunaingiliana.
Tatizo hili liligunduliwa zaidi ya miaka 20 iliyopita. Nilipata kutajwa kwa kwanza kwa mazoezi ya Ujumuishaji Unaoendelea katika Upangaji Uliokithiri.
Utayarishaji Mkubwa ndio mfumo wa kwanza mwepesi. Ukurasa ulionekana mnamo 96. Na wazo lilikuwa kutumia aina fulani ya mazoea ya programu, kupanga na mambo mengine, ili maendeleo yawe rahisi iwezekanavyo, ili tuweze kujibu haraka mabadiliko yoyote au mahitaji kutoka kwa wateja wetu. Na walianza kukabiliana na hii miaka 24 iliyopita, kwamba ikiwa unafanya jambo kwa muda mrefu sana na kwa pembeni, basi unatumia muda mwingi juu yake kwa sababu una migogoro.
Sasa tutachambua maneno "Ushirikiano wa Kuendelea" mmoja mmoja. Ikiwa tutaitafsiri moja kwa moja, tunapata ushirikiano unaoendelea. Lakini jinsi inavyoendelea si wazi sana; haiendelei sana. Lakini ni kiasi gani cha ushirikiano kina pia si dhahiri sana.
Na ndio maana ninakupa nukuu kutoka kwa Extreme Programming sasa. Na tutachambua maneno yote mawili tofauti.
Ujumuishaji - Kama nilivyosema tayari, tunajitahidi kuhakikisha kuwa kila mhandisi anafanya kazi na toleo la sasa la nambari, ili ajitahidi kuongeza nambari yake mara nyingi iwezekanavyo kwa tawi la kawaida, ili haya ni matawi madogo. Kwa sababu ikiwa ni kubwa, basi tunaweza kukwama kwa urahisi na migogoro ya kuunganisha kwa wiki. Hii ni kweli hasa ikiwa tuna mzunguko mrefu wa maendeleo kama vile maporomoko ya maji, ambapo msanidi programu alienda kwa mwezi mmoja ili kupunguza kipengele kikubwa. Na atakuwa amekwama katika hatua ya ushirikiano kwa muda mrefu sana.
Kuunganishwa ni wakati tunapochukua tawi letu na kuunganisha na bwana, tunaunganisha. Kuna chaguo la mwisho wakati sisi ni msanidi wa transbase, ambapo tunajitahidi kuhakikisha kwamba tunamwandikia bwana mara moja bila matawi yoyote ya ziada.
Kwa ujumla, ujumuishaji unamaanisha kuchukua nambari yako na kuivuta ndani ya bwana.
Nini maana ya hapa na neno "kuendelea", kile kinachoitwa kuendelea? Mazoezi yanamaanisha kuwa msanidi programu hujitahidi kuunganisha msimbo wake haraka iwezekanavyo. Hili ndio lengo lake wakati wa kufanya kazi yoyote - kupata nambari yake kuwa bwana haraka iwezekanavyo. Katika ulimwengu bora, watengenezaji wangefanya hivi kila baada ya saa chache. Hiyo ni, unachukua shida ndogo na kuiunganisha kwa bwana. Kila kitu ni kikubwa. Hivi ndivyo unavyojitahidi. Na hii lazima ifanyike kwa kuendelea. Mara tu unapofanya kitu, mara moja unaiweka ndani ya bwana.
Na msanidi programu anayetengeneza kitu anawajibika kwa kile alichofanya kuifanya ifanye kazi na sio kuvunja chochote. Hapa ndipo hadithi ya jaribio kawaida hutoka. Tunataka kufanya majaribio kadhaa kwenye ahadi yetu, kwa kuunganisha kwetu, ili kuhakikisha kuwa inafanya kazi. Na hapa ndipo Jenkins anaweza kukusaidia.
Lakini na hadithi: wacha tufanye mabadiliko madogo, wacha kazi ziwe ndogo, tufanye shida na mara moja jaribu kuiingiza kwa bwana - hakuna Jenkins atasaidia hapa. Kwa sababu Jenkins atakusaidia kufanya majaribio pekee.
Unaweza kufanya bila wao. Hii haitakuumiza hata kidogo. Kwa sababu lengo la mazoezi ni kupima mara nyingi iwezekanavyo, ili usipoteze kiasi kikubwa cha muda kwenye migogoro yoyote katika siku zijazo.
Wacha tufikirie kuwa kwa sababu fulani tuko katika 2020 bila mtandao. Na tunafanya kazi ndani. Hatuna Jenkins. Hii ni sawa. Bado unaweza kwenda mbele na kutengeneza tawi la karibu. Uliandika nambari fulani ndani yake. Tulimaliza kazi katika masaa 3-4. Tulibadilisha kuwa master, tukavuta git, na tukaunganisha tawi letu hapo. Tayari. Ikiwa unafanya hivi mara nyingi, pongezi, una Ushirikiano Unaoendelea!
Je, kuna ushahidi gani katika ulimwengu wa kisasa kwamba ni thamani ya kutumia nishati? Kwa sababu kwa ujumla ni ngumu. Ukijaribu kufanya kazi kama hii, utaelewa kuwa upangaji fulani sasa utaathiriwa, itabidi utoe wakati mwingi kwa kazi za kuoza. Kwa sababu ikiwa utafanya mwanadamu ..., basi hautaweza kukubaliana haraka na, ipasavyo, utapata shida. Hutakuwa na mazoezi tena.
Na itakuwa ghali. Haitawezekana kufanya kazi mara moja kuanzia kesho kwa kutumia Continuous Integration. Itakuchukua muda mrefu sana wote kuzoea, itakuchukua muda mrefu sana kuzoea kazi za uozo, itachukua muda mrefu sana kuzoea kufanya tena mazoezi ya uhakiki, ikiwa unayo. . Kwa sababu lengo letu ni kuyeyuka leo. Na ikiwa utafanya ukaguzi ndani ya siku tatu, basi una matatizo na Ushirikiano wa Kuendelea haufanyi kazi kwako.
Lakini je, tuna ushahidi wowote unaofaa sasa hivi unaotuambia kuwa kuwekeza katika mazoezi haya kunaleta maana?
Jambo la kwanza ambalo lilikuja akilini mwangu lilikuwa Jimbo la DevOps. Huu ni utafiti ambao wavulana wamekuwa wakifanya kwa miaka 7. Sasa wanaifanya kama shirika huru, lakini chini ya Google.
Na utafiti wao wa 2018 ulionyesha uwiano kati ya makampuni ambayo yanajaribu kutumia matawi ya muda mfupi ambayo huunganisha haraka, kuunganisha mara kwa mara, na kuwa na viashiria bora vya utendaji wa IT.
Viashiria hivi ni nini? Hizi ni vipimo 4 ambazo huchukua kutoka kwa makampuni yote katika dodoso zao: mzunguko wa kupeleka, muda wa kuongoza kwa mabadiliko, muda wa kurejesha huduma, kubadilisha kiwango cha kushindwa.
Na, kwanza, kuna uwiano huu, tunajua kwamba makampuni ambayo hupima mara kwa mara huwa na vipimo bora zaidi. Na wana mgawanyiko wa makampuni katika makundi kadhaa: haya ni makampuni ya polepole ambayo yanazalisha kitu polepole, mwigizaji wa kati, mtendaji wa juu na wasomi. Wasomi ni Netflix, Amazon, ambayo ni haraka sana, hufanya kila kitu haraka, kwa uzuri na kwa ufanisi.
Hadithi ya pili, ambayo ilitokea mwezi mmoja uliopita. Rada ya Teknolojia ina nakala nzuri kuhusu Gitflow. Gitflow ni tofauti na wengine wote kwa kuwa matawi yake ni ya muda mrefu. Kuna matawi ya kutolewa ambayo yanaishi kwa muda mrefu, na matawi ya kipengele ambayo pia yanaishi kwa muda mrefu. Zoezi hili katika Rada ya Teknolojia limehamia kwa HOLD. Kwa nini? Kwa sababu watu wanakabiliwa na maumivu ya kuunganishwa.
Ikiwa tawi lako linaishi kwa muda mrefu sana, linakwama, linaharibika, na tunaanza kutumia muda mwingi kujaribu kufanya aina fulani ya mabadiliko kwake.
Na hivi majuzi mwandishi wa Gitflow alisema kuwa ikiwa lengo lako ni Ujumuishaji Unaoendelea, ikiwa lengo lako ni kwamba unataka kusonga mara nyingi iwezekanavyo, basi Gitflow ni wazo mbaya. Aliongeza kando kwa kifungu hicho kwamba ikiwa una backend ambapo unaweza kujitahidi kwa hili, basi Gitflow ni ya juu kwako, kwa sababu Gitflow itakupunguza kasi, Gitflow itakuletea shida na ujumuishaji.
Hii haimaanishi kuwa Gitflow ni mbaya na haifai kutumiwa. Ni kwa hafla zingine. Kwa mfano, unapohitaji kuauni matoleo kadhaa ya huduma au programu, yaani, ambapo unahitaji usaidizi kwa muda mrefu.
Lakini ikiwa unazungumza na watu wanaounga mkono huduma kama hizo, utasikia maumivu mengi juu ya ukweli kwamba toleo hili lilikuwa 3.2, ambalo lilikuwa miezi 4 iliyopita, lakini marekebisho haya hayakujumuishwa ndani yake na sasa, ili kuifanya, unahitaji kufanya rundo la mabadiliko. Na sasa wamekwama tena, na sasa wamekuwa wakizunguka-zunguka kwa wiki kujaribu kutekeleza kipengele kipya.
Kama Alexander Kovalev alivyobaini kwa usahihi kwenye gumzo, uunganisho sio sawa na sababu. Hii ni kweli. Hiyo ni, hakuna muunganisho wa moja kwa moja kwamba ikiwa una Ujumuishaji Unaoendelea, basi metriki zote zitakuwa nzuri. Lakini kuna uunganisho mzuri kwamba ikiwa moja ni moja, basi uwezekano mkubwa wa mwingine pia. Sio ukweli, lakini uwezekano mkubwa. Ni uwiano tu.
Inaonekana kwamba tayari tunafanya kitu, inaonekana kwamba tayari tunaunganisha, lakini tunawezaje kuelewa kwamba bado tuna Ushirikiano wa Kuendelea, kwamba tunaunganisha mara nyingi kabisa?
Jez Humble ndiye mwandishi wa kitabu cha Handbook, Accelerate, the Continuous Delivery tovuti, na kitabu Continuous Delivery. Anatoa mtihani huu:
- Nambari ya mhandisi hufika kwa bwana kila siku.
- Kwa kila ahadi unaendesha majaribio ya kitengo.
- Jengo katika bwana lilianguka, lilirekebishwa kwa kama dakika 10.
Anashauri kutumia mtihani kama huu ili kuhakikisha una mazoezi ya kutosha.
Naona hili la pili lina utata kidogo. Hiyo ni, ikiwa unaweza kurekebisha kwa dakika 10, basi una Ushirikiano wa Kuendelea, inaonekana kuwa ya ajabu kidogo, kwa maoni yangu, lakini ina maana. Kwa nini? Kwa sababu ikiwa unafungia mara nyingi, inamaanisha kuwa mabadiliko yako ni madogo. Ikiwa mabadiliko madogo yanamaanisha kuwa jengo lako la bwana limevunjwa, basi unaweza kupata mfano haraka kwa sababu mabadiliko ni ndogo. Hapa ulikuwa na muunganisho mdogo, mistari 20-30 ndani yake ilibadilika. Na, ipasavyo, unaweza kuelewa haraka sababu ilikuwa nini, kwa sababu mabadiliko ni madogo, una eneo ndogo sana la kutafuta shida.
Na hata kama prod yetu itaanguka baada ya kuachiliwa, basi ikiwa tuna mazoezi ya Ujumuishaji Unaoendelea, ni rahisi kwetu kuchukua hatua, kwa sababu mabadiliko ni madogo. Ndiyo, hii itaathiri kupanga. Hii itaumiza. Na, pengine, jambo gumu zaidi katika mazoezi haya ni kuzoea kuvunja kazi, ambayo ni, jinsi ya kuifanya ili uweze kuchukua kitu na kuifanya kwa masaa machache na wakati huo huo kupitisha ukaguzi, ikiwa. unayo moja. Mapitio ni maumivu tofauti.
Majaribio ya vitengo ni msaidizi tu anayekusaidia kuelewa ikiwa ujumuishaji wako ulifanikiwa na ikiwa hakuna kitu kilichoharibika. Kwa maoni yangu, hii pia sio lazima kabisa, kwa sababu hii sio hatua ya mazoezi.
Huu ni utangulizi mfupi wa Ujumuishaji Unaoendelea. Hiyo ndiyo yote kuna mazoezi haya. Niko tayari kwa maswali.
Nitafupisha tena kwa ufupi:
- Ushirikiano unaoendelea sio Jenkins, sio Gitlab.
- Hii sio zana, ni mazoezi kwamba tunaunganisha nambari yetu kuwa bwana mara nyingi iwezekanavyo.
- Tunafanya hivyo ili kuepusha maumivu makubwa yanayotokea na miunganisho katika siku zijazo, yaani, tunapata maumivu kidogo sasa ili tusipate uzoefu zaidi katika siku zijazo. Hiyo ndiyo hoja nzima.
- Kwa upande kuna mawasiliano kwa njia ya kanuni, lakini mimi mara chache sana kuona hii, lakini hii pia ni nini ilikuwa iliyoundwa kwa ajili ya.
maswali
Nini cha kufanya na kazi zisizoharibika?
Kuoza. Shida ni nini? Unaweza kutoa mfano kuwa kuna kazi na haijaharibika?
Kuna kazi ambazo haziwezi kutenganishwa kutoka kwa neno "kabisa", kwa mfano, zile zinazohitaji utaalamu wa kina sana na ambazo zinaweza kutatuliwa kwa muda wa mwezi ili kufikia matokeo fulani ya utumbo.
Ikiwa ninakuelewa kwa usahihi, basi kuna kazi kubwa na ngumu, ambayo matokeo yake yataonekana tu kwa mwezi?
Ndiyo hiyo ni sahihi. Ndio, itawezekana kutathmini matokeo hakuna mapema kuliko mwezi.
Sawa. Kwa ujumla hili si tatizo. Kwa nini? Kwa sababu katika kesi hii, tunapozungumzia matawi, hatuzungumzi juu ya tawi yenye kipengele. Vipengele vinaweza kuwa kubwa na ngumu. Wanaweza kuathiri idadi kubwa ya vipengele. Na labda hatuwezi kuzifanya kabisa katika tawi moja. Hii ni sawa. Tunahitaji tu kuvunja hadithi hii. Ikiwa kipengele hakiko tayari kabisa, hii haimaanishi kuwa baadhi ya vipande vya msimbo wake haviwezi kuunganishwa. Umeongeza, sema, uhamiaji na kuna hatua kadhaa ndani ya kipengele. Wacha tuseme una hatua - fanya uhamiaji, ongeza njia mpya. Na unaweza tayari kupima mambo haya kila siku.
Sawa. Kuna maana gani basi?
Kuna maana gani kuua vitu vidogo kila siku?
Ndiyo.
Ikiwa wanavunja kitu, unaona mara moja. Una kipande kidogo ambacho kimevunja kitu, ni rahisi kwako kurekebisha. Hatua ni kwamba kuunganisha kipande kidogo sasa ni rahisi zaidi kuliko kuunganisha kitu kikubwa katika wiki chache. Na jambo la tatu ni kwamba wahandisi wengine watafanya kazi na toleo la sasa la kanuni. Wataona kwamba baadhi ya uhamaji umeongezwa hapa, na kisha njia fulani imeonekana ambayo wanaweza pia kutaka kutumia. Kila mtu ataona kinachoendelea katika msimbo wako. Ni kwa mambo haya matatu ambayo mazoezi hufanywa.
Asante, suala limefungwa!
(Oleg Soroka) Je, naweza kuongeza? Ulisema kila kitu kwa usahihi, nataka kuongeza kifungu kimoja.
Kwa hiyo.
Kwa Ushirikiano Unaoendelea, msimbo huunganishwa kwenye tawi la kawaida si wakati kipengele kiko tayari kabisa, lakini wakati jengo linaacha kuvunjika. Na unaweza kujitolea kwa usalama kwa bwana mara nyingi kwa siku unavyotaka. Kipengele cha pili ni kwamba ikiwa kwa sababu fulani huwezi kuvunja kazi ya kila mwezi katika kazi kwa angalau siku tatu, mimi ni kimya kuhusu saa tatu, basi una shida kubwa. Na ukweli kwamba huna Ushirikiano Unaoendelea ni mdogo wa matatizo haya. Hii inamaanisha kuwa una matatizo na usanifu na mazoea ya uhandisi sifuri. Kwa sababu hata kama hii ni utafiti, basi kwa hali yoyote lazima iundwe kwa namna ya dhana au mzunguko.
Tulizungumza kuhusu metriki 4 zinazotofautisha kampuni zilizofanikiwa kutoka kwa zile zilizochelewa. Bado tunapaswa kuishi ili kuona vipimo hivi 4. Ikiwa kazi yako ya wastani itachukua mwezi mmoja kukamilika, basi ningezingatia kipimo hiki kwanza. Ningeipunguza hadi siku 3 kwanza. Na baada ya hapo nilianza kufikiria kuhusu Continuous.
Je, nilikuelewa kwa usahihi kwamba unafikiri kwamba kwa ujumla hakuna maana katika kuwekeza katika mazoea ya uhandisi ikiwa kazi yoyote inachukua mwezi kukamilika?
Una Ujumuishaji Unaoendelea. Na kuna mada ambayo katika dakika 10 unaweza kurekebisha au kuirudisha nyuma. Fikiria umeitoa. Zaidi ya hayo, hata una utumaji unaoendelea, uliisambaza kwa utayarishaji na kisha ukagundua kuwa kuna kitu kilienda vibaya. Na unahitaji kuirudisha nyuma, lakini tayari umehamisha hifadhidata yako. Tayari unayo schema ya hifadhidata ya toleo linalofuata, zaidi ya hayo, pia ulikuwa na aina fulani ya chelezo, na data pia iliandikwa hapo.
Na una mbadala gani? Ukirudisha msimbo, basi hauwezi tena kufanya kazi na hifadhidata hii iliyosasishwa.
Msingi unasonga mbele tu, ndio.
Watu ambao wana mazoea duni ya uhandisi kuna uwezekano mkubwa hawajasoma kitabu kirefu kuhusu ... pia. Nini cha kufanya na chelezo? Ukirejesha kutoka kwa nakala rudufu, inamaanisha kuwa utapoteza data ambayo umekusanya wakati huo. Kwa mfano, tulifanya kazi kwa saa tatu na toleo jipya la hifadhidata, watumiaji waliojiandikisha hapo. Unakataa hifadhi rudufu ya zamani kwa sababu mpango haufanyi kazi na toleo jipya, kwa hivyo umepoteza watumiaji hawa. Na hawakuridhika, wanaapa.
Ili kujua anuwai kamili ya mazoea ambayo yanaunga mkono Ujumuishaji Unaoendelea na Uwasilishaji Unaoendelea, haitoshi tu kujifunza jinsi ya kuandika.... Kwanza, kunaweza kuwa na mengi yao, itakuwa haiwezekani. Pia kuna rundo la mazoea mengine kama Sayansi. Kuna mazoezi kama haya, GitHub aliitangaza kwa wakati mmoja. Huu ndio wakati una msimbo wa zamani na msimbo mpya unaofanya kazi kwa wakati mmoja. Huu ndio wakati unapotengeneza kipengele ambacho hakijakamilika, lakini kinaweza kurudisha thamani fulani: ama kama chaguo la kukokotoa au kama API ya Kupumzika. Unatumia nambari mpya na nambari ya zamani, na kulinganisha tofauti kati yao. Na ikiwa kuna tofauti, basi unaingia tukio hili. Kwa njia hii unajua kuwa una kipengele kipya tayari kutolewa juu ya kile cha zamani ikiwa hujawa na tofauti kati ya hizo mbili kwa muda fulani.
Kuna mamia ya mazoea kama haya. Ningependekeza kuanza na maendeleo ya transbase. Yeye sio 100% kwenye Ushirikiano Unaoendelea, lakini mazoea ni sawa, mtu hawezi kuishi vizuri bila mwingine.
Je, ulitoa uundaji wa transbase kama mfano ambapo unaweza kuona mazoea au unapendekeza watu waanze kutumia transbase debelopment?
Angalia, kwa sababu hawataweza kuitumia. Ili kuzitumia, unahitaji kusoma sana. Na wakati mtu anauliza: "Nini cha kufanya na kipengele kinachochukua mwezi, inamaanisha kwamba hajasoma juu ya maendeleo ya transbase." Nisingeipendekeza bado. Ningeshauri kuzingatia tu juu ya mada ya jinsi ya kuvunja kwa usahihi kazi kubwa kuwa ndogo. Hiki ndicho kiini cha mtengano.
Mtengano ni moja ya zana za mbunifu. Kwanza tunafanya uchambuzi, kisha mtengano, kisha usanisi, kisha ujumuishaji. Na hivi ndivyo kila kitu kinavyofanya kazi kwetu. Na bado tunahitaji kukua hadi Ushirikiano Unaoendelea kupitia mtengano. Maswali yanatokea katika hatua ya kwanza, na tayari tunazungumza juu ya hatua ya nne, i.e. mara nyingi tunafanya ujumuishaji, bora zaidi. Bado ni mapema sana kufanya hivi; itakuwa vizuri kukata monolith yako kwanza.
Unahitaji kuchora idadi ya mishale na mraba kwenye mchoro fulani. Huwezi kusema kwamba sasa nitaonyesha mchoro wa usanifu wa programu mpya na kuonyesha mraba mmoja, ndani ambayo kuna kifungo cha kijani cha programu. Kwa hali yoyote, kutakuwa na mraba zaidi na mishale. Kila mchoro nilioona ulikuwa na zaidi ya mmoja. Na mtengano, hata katika kiwango cha uwakilishi wa picha, tayari unafanyika. Kwa hiyo, mraba unaweza kufanywa kwa kujitegemea. Ikiwa sivyo, basi nina maswali makubwa kwa mbunifu.
Kuna swali kutoka kwa gumzo: "Ikiwa ukaguzi ni wa lazima na unachukua muda mrefu, labda siku moja au zaidi?"
Una matatizo na mazoezi. Ukaguzi haupaswi kudumu siku moja au zaidi. Hii ni hadithi sawa na swali lililotangulia, laini kidogo tu. Uhakiki ukiendelea kwa siku moja, basi kuna uwezekano mkubwa kwamba ukaguzi huu unaendelea na mabadiliko makubwa sana. Hii ina maana kwamba inahitaji kufanywa ndogo. Katika maendeleo ya transbase, ambayo Oleg alipendekeza, kuna hadithi inayoitwa mapitio ya kuendelea. Wazo lake ni kwamba tufanye ombi dogo kama hilo la kuvuta kwa makusudi, kwa sababu tunajitahidi kuunganisha kila mara na kidogo kwa wakati. Na kwa hivyo ombi la kuvuta hubadilisha kifupisho kimoja au mistari 10. Shukrani kwa ukaguzi huu, inachukua sisi dakika kadhaa.
Ikiwa ukaguzi unachukua siku moja au zaidi, kuna kitu kibaya. Kwanza, unaweza kuwa na shida na usanifu. Au hii ni kipande kikubwa cha msimbo, mistari 1, kwa mfano. Au usanifu wako ni ngumu sana kwamba mtu hawezi kuuelewa. Hili ni shida ya kando kidogo, lakini pia italazimika kutatuliwa. Labda hakuna haja ya ukaguzi hata kidogo. Tunahitaji kufikiria juu ya hili pia. Uhakiki ndio kitu kinachokupunguza kasi. Ina faida zake kwa ujumla, lakini unahitaji kuelewa kwa nini unafanya hivyo. Je, hii ni njia ya wewe kuwasilisha habari kwa haraka, je, hii ni njia ya wewe kuweka viwango fulani ndani au vipi? Kwa nini unahitaji hii? Kwa sababu ukaguzi unahitaji kufanywa haraka sana au kughairiwa kabisa. Ni kama maendeleo ya transbase - hadithi ni nzuri sana, lakini kwa watu waliokomaa tu.
Kuhusu vipimo 4, bado ningependekeza viondolewe ili kuelewa hii inasababisha nini. Angalia nambari, angalia picha, jinsi kila kitu kilivyo mbaya.
(Dmitry) Niko tayari kuingia kwenye mjadala kuhusu hili na wewe. Nambari na vipimo vyote ni vyema, mbinu ni nzuri. Lakini unahitaji kuelewa ikiwa biashara inaihitaji. Kuna biashara ambazo hazihitaji kasi ya aina hiyo ya mabadiliko. Ninajua kampuni ambazo mabadiliko hayawezi kufanywa kila dakika 15. Na si kwa sababu wao ni mbaya sana. Huu ni mzunguko wa maisha kama huu. Na kufanya matawi kuwa kipengele, kipengele cha kugeuza, unahitaji ujuzi wa kina.
Ni ngumu. Ikiwa unataka kusoma hadithi kuhusu kipengele cha kugeuza kwa undani zaidi, ninaipendekeza sana . Na kuna makala nzuri ya Martin Fowler kuhusu kugeuza vipengele: kuna aina gani, mizunguko ya maisha, nk. Kipengele cha kugeuza ni ngumu.
Na bado haujajibu swali: Jenkins anahitajika au la?
Jenkins haihitajiki kwa hali yoyote kweli. Kwa umakini, zana: Jenkins, Gitlab itakuletea urahisi. Utaona kwamba mkusanyiko umekusanyika au haujakusanyika. Wanaweza kukusaidia, lakini hawatakupa mazoezi. Wanaweza tu kukupa mduara - Sawa, si Sawa. Na kisha, ikiwa pia unaandika vipimo, kwa sababu ikiwa hakuna vipimo, basi ni karibu haina maana. Kwa hiyo, inahitajika kwa sababu ni rahisi zaidi, lakini kwa ujumla unaweza kuishi bila hiyo, huwezi kupoteza sana.
Hiyo ni, ikiwa una mazoea, inamaanisha kuwa hauitaji?
Hiyo ni sawa. Ninapendekeza jaribio la Jez Humble. Hapo nina mtazamo wa kutoelewana kuelekea hatua ya mwisho. Lakini kwa ujumla, ikiwa una vitu vitatu, unaunganisha mara kwa mara, unaendesha vipimo kwenye kazi kwa bwana, unarekebisha haraka ujenzi wa bwana, basi labda hauitaji kitu kingine chochote.
Wakati tunasubiri maswali kutoka kwa washiriki, nina swali. Tulikuwa tunazungumza tu juu ya nambari ya bidhaa. Je, umeitumia kwa msimbo wa miundombinu? Je, ni kanuni sawa, ina kanuni sawa na mzunguko wa maisha sawa, au kuna mizunguko ya maisha na kanuni tofauti? Kwa kawaida, kila mtu anapozungumza kuhusu Ushirikiano na Maendeleo Endelevu, kila mtu anasahau kuwa pia kuna msimbo wa miundombinu. Na hivi karibuni kumekuwa na zaidi na zaidi yake. Na sheria hizi zote zinapaswa kuletwa huko?
Sio kwamba inapaswa kuwa, itakuwa nzuri kwa sababu ingerahisisha maisha kwa njia ile ile. Mara tu tunapofanya kazi na nambari, sio na hati za bash, lakini tunayo nambari ya kawaida.
Acha, acha, hati ya bash pia ni nambari. Usiguse upendo wangu wa zamani.
Sawa, sitakanyaga kumbukumbu zako. Sipendi kibinafsi kwa bash. Inavunja mbaya na inatisha kila wakati. Na mara nyingi huvunja bila kutabirika, ndiyo sababu siipendi. Lakini sawa, wacha tuseme unayo nambari ya bash. Labda sielewi na kuna mifumo ya kawaida ya majaribio huko nje. Mimi tu si katika kujua. Na tunapata faida sawa.
Mara tu tunapofanya kazi na miundombinu kama nambari, tunapata shida zote sawa na wasanidi programu. Miezi michache iliyopita, nilikutana na hali ambapo mwenzangu alinitumia ombi la kuvuta mistari 1 kwa bash. Na unabarizi kwenye ukaguzi kwa saa 000. Matatizo sawa hutokea. Bado ni kanuni. Na bado ni ushirikiano. Tunakwama na ombi la kuvuta na tunakwama na ukweli kwamba tunasuluhisha mizozo sawa ya kuunganisha katika bash sawa, kwa mfano.
Sasa ninatazama kwa makini jambo hili zima kwenye upangaji programu mzuri zaidi wa infra. Sasa nimeleta Pulumi kwenye miundombinu. Hii ni programu katika hali yake safi. Huko ni nzuri zaidi, kwa sababu nina uwezo wote wa lugha ya programu, i.e. nilifanya mabadiliko mazuri kutoka kwa bluu na ikiwa sawa na kila kitu kiko sawa. Hiyo ni, mabadiliko yangu tayari iko kwa bwana. Kila mtu anaweza kumwona tayari. Wahandisi wengine wanajua juu yake. Tayari imeathiri kitu hapo. Walakini, haikuwezeshwa kwa miundombinu yote. Iliwashwa kwa madawati yangu ya majaribio, kwa mfano. Kwa hiyo, kujibu swali lako tena, ni muhimu. Inafanya maisha kuwa rahisi kwetu, kama wahandisi wanaofanya kazi na nambari, kwa njia sawa.
Ikiwa mtu mwingine ana maswali?
Nina swali. Ninataka kuendelea na majadiliano na Oleg. Kwa ujumla nadhani upo sahihi kwamba kazi ikichukua mwezi mmoja kukamilika basi una tatizo na usanifu una tatizo la uchambuzi, mtengano, kupanga n.k. Lakini nina hisia kwamba ukianza kujaribu kuishi kulingana na Ushirikiano wa Kuendelea, basi utaanza kurekebisha maumivu kwa kupanga, kwa sababu hautaondoka popote pengine.
(Oleg) Ndiyo, hiyo ni sawa. Zoezi hili linalinganishwa katika juhudi na mazoea mengine yoyote mazito ya kubadilisha utamaduni. Kitu ngumu zaidi kushinda ni tabia, haswa tabia mbaya. Na ikiwa ili kutekeleza mazoezi haya, mabadiliko makubwa katika tabia ya wale walio karibu nawe yanahitajika: watengenezaji, usimamizi, meneja wa uzalishaji, basi mshangao unangojea.
Kuna mshangao gani? Hebu sema ukiamua kuwa utaunganisha mara nyingi zaidi. Na una mambo mengine yanayounganishwa na ushirikiano, kwa mfano, mabaki. Na katika kampuni yako, kwa mfano, kuna sera ambayo kila artifact lazima ihesabiwe kwa namna fulani katika aina fulani ya mfumo wa hifadhi ya vizalia. Na inachukua muda. Mtu anahitaji kuteua kisanduku ambacho yeye, kama msimamizi wa toleo, amejaribu vizalia hivi vya programu ili kuhakikisha kuwa viko tayari kutolewa katika toleo la umma. Ikiwa inachukua dakika 5-10-15, lakini unafanya mpangilio mara moja kwa wiki, kisha kutumia nusu saa mara moja kwa wiki ni kodi ndogo.
Ikiwa unafanya Ujumuishaji unaoendelea mara 10 kwa siku, basi mara 10 zinahitaji kuzidishwa kwa dakika 30. Na hii inazidi muda wa kufanya kazi wa meneja huyu wa kutolewa. Anachoka tu kufanya hivyo. Kuna gharama zisizobadilika kwa mazoea fulani. Ni hayo tu.
Na unahitaji kughairi sheria hii ili usifanye tena takataka kama hizo, i.e. hautoi digrii kulingana na kitu. Unategemea kikamilifu baadhi ya majaribio ya utayari wa kiotomatiki.
Na ikiwa unahitaji uthibitisho kutoka kwa mtu, ili bosi asaini, na usiingie katika uzalishaji bila Vasya kusema kwamba anaruhusu, nk - upuuzi huu wote unapata njia ya daktari. Kwa sababu ikiwa kuna shughuli fulani zinazohusiana na ushuru, basi kila kitu kinaongezeka mara 100. Kwa hivyo, mabadiliko mara nyingi hayatasalimiwa kwa furaha na kila mtu. Kwa sababu tabia za watu ni ngumu kubadilika.
Wakati mtu anafanya kazi yake ya kawaida, anaifanya karibu bila kufikiria. Mzigo wake wa utambuzi ni sifuri. Anacheza tu na hilo, tayari ana orodha ya kuangalia katika kichwa chake, amefanya mara elfu. Na mara tu unapokuja na kumwambia: "Hebu tughairi mazoezi haya na kuanzisha mpya kuanzia Jumatatu," kwa ajili yake inakuwa mzigo wenye nguvu wa utambuzi. Na inakuja kwa kila mtu mara moja.
Kwa hivyo, jambo rahisi zaidi, ingawa sio kila mtu anayeweza kumudu anasa hii, lakini hii ndio ninafanya kila wakati, hii ndio ifuatayo. Ikiwa mradi mpya utaanza, basi kwa kawaida mazoea yote ambayo hayajajaribiwa husongwa mara moja kwenye mradi huu. Wakati mradi ni mchanga, hatuhatarishi chochote. Bado hakuna Prod, hakuna cha kuharibu. Kwa hivyo, inaweza kutumika kama mafunzo. Mbinu hii inafanya kazi. Lakini sio makampuni yote yana fursa ya kuanza miradi hiyo mara nyingi. Ingawa hii pia ni ya kushangaza kidogo, kwa sababu sasa kuna mabadiliko kamili ya dijiti, kila mtu lazima azindue majaribio ili kuendana na washindani.
Hapa unafikia hitimisho kwamba lazima kwanza uwe na ufahamu wa kile unachohitaji kufanya. Ulimwengu sio bora, na prod sio bora pia.
Ndio, mambo haya yanaunganishwa.
Biashara pia hazielewi kila wakati kuwa zinahitaji kwenda hivi.
Kuna hali ambayo hakuna mabadiliko yanayowezekana kabisa. Hii ni hali ambapo kuna shinikizo zaidi kwa timu. Timu tayari imeteketea kabisa. Yeye hana wakati wa ziada kwa majaribio yoyote. Wanafanya kazi kwenye vipengele kutoka asubuhi hadi jioni. Na usimamizi una vipengele vichache na vichache. Zaidi na zaidi inahitajika. Katika hali kama hiyo, hakuna mabadiliko yanayowezekana kabisa. Timu inaweza tu kuambiwa kuwa kesho tutafanya sawa na jana, tunahitaji tu kutengeneza vipengele zaidi. Kwa maana hii, hakuna mabadiliko ya mazoea yoyote yanawezekana. Hii ni hali ya kawaida wakati hakuna wakati wa kunoa shoka, miti inahitaji kukatwa, kwa hivyo huikata kwa shoka nyepesi. Hakuna vidokezo rahisi hapa.
(Dmitry) Nitasoma ufafanuzi kutoka kwa gumzo: "Lakini tunahitaji chanjo nyingi za majaribio katika viwango tofauti. Muda gani umetengwa kwa ajili ya vipimo? Ni ghali kidogo na inachukua muda mwingi."
(Oleg) Hii ni dhana potofu ya kawaida. Kunapaswa kuwa na vipimo vya kutosha ili kujiamini. Ushirikiano wa Kuendelea sio jambo ambalo 100% ya majaribio hufanywa kwanza na kisha tu kuanza kutumia mazoezi haya. Ushirikiano unaoendelea hupunguza mzigo wako wa utambuzi kutokana na ukweli kwamba kila mabadiliko ambayo unaona kwa macho yako ni dhahiri sana kwamba unaelewa ikiwa itavunja kitu au la, hata bila vipimo. Unaweza kujaribu hii haraka kichwani mwako kwa sababu mabadiliko ni madogo. Hata kama una wapimaji wa mwongozo pekee, ni rahisi kwao pia. Ulizunguka na kusema: "Angalia, kuna kitu kimevunjika?" Waliangalia na kusema, "Hapana, hakuna kitu kilichoharibika." Kwa sababu anayejaribu anajua wapi pa kuangalia. Una ahadi moja inayohusishwa na kipande kimoja cha msimbo. Na hii inatumiwa na tabia maalum.
Hapa, bila shaka, umepambwa.
(Dmitry) Sikubaliani hapa. Kuna mazoezi - maendeleo yanayotokana na mtihani, ambayo yatakuokoa kutoka kwa hili.
(Oleg) Kweli, sijafikia hatua hiyo bado. Udanganyifu wa kwanza ni kwamba unahitaji kuandika 100% ya vipimo au huna haja ya kufanya Ushirikiano wa Kuendelea wakati wote. Sio kweli. Haya ni mazoea mawili yanayofanana. Na hawana tegemezi moja kwa moja. Ufikiaji wako wa mtihani unapaswa kuwa bora zaidi. Inafaa - hii inamaanisha kuwa wewe mwenyewe una uhakika kuwa ubora wa bwana ambaye bwana wako alibaki baada ya ahadi hukuruhusu kubonyeza kitufe cha "Peleka" kwa ujasiri jioni ya Ijumaa ya ulevi. Je, unafanikisha hili? Kupitia mapitio, kupitia chanjo, kupitia ufuatiliaji mzuri.
Ufuatiliaji mzuri hauwezi kutofautishwa na vipimo. Ikiwa utafanya majaribio mara moja kwenye toleo la awali, basi wataangalia hati zako zote za mtumiaji mara moja na ndivyo hivyo. Na ikiwa utaziendesha kwa kitanzi kisicho na mwisho, basi huu ndio mfumo wako wa ufuatiliaji uliowekwa, ambao hujaribu kila kitu bila mwisho - ikiwa ilianguka au la. Katika kesi hii, tofauti pekee ni ikiwa inafanywa mara moja au mbili. Seti nzuri sana ya vipimo ... inayoendelea bila mwisho, huu ni ufuatiliaji. Na ufuatiliaji sahihi unapaswa kuwa kama hii.
Na kwa hiyo, jinsi gani hasa utafikia hali hii wakati unajitayarisha Ijumaa jioni na kwenda nyumbani ni swali lingine. Labda wewe ni mpuuzi jasiri.
Turudi nyuma kidogo kwenye Continuous Integration. Tulikimbilia kwenye mazoezi magumu tofauti kidogo.
Na udanganyifu wa pili ni kwamba MVP, wanasema, inahitaji kufanywa haraka, hivyo vipimo hazihitajiki huko kabisa. Si hakika kwa njia hiyo. Ukweli ni kwamba unapoandika hadithi ya mtumiaji katika MVP, unaweza kuiendeleza kwenye mpira, yaani, ulisikia kwamba kulikuwa na aina fulani ya hadithi ya mtumiaji na mara moja ukakimbia kuiandika, au unaweza kufanya kazi kwa kutumia TDD. Na kulingana na TDD, kama inavyoonyesha mazoezi, haichukui muda mrefu, i.e. vipimo ni athari ya upande. Mazoezi ya TDD sio ya kupima. Licha ya kile kinachoitwa Maendeleo ya Kuendeshwa kwa Mtihani, sio juu ya majaribio hata kidogo. Hii pia ni badala ya mbinu ya usanifu. Hii ni mbinu ya kuandika kile hasa kinachohitajika na sio kuandika kisichohitajika. Hili ni zoezi la kuangazia mrudisho unaofuata wa mawazo yako katika suala la kuunda usanifu wa programu.
Kwa hiyo, si rahisi sana kuondokana na udanganyifu huu. MVP na vipimo havipingani. Hata, badala yake, kinyume chake, ikiwa unafanya MVP kwa kutumia mazoezi ya TDD, basi utafanya vizuri zaidi na kwa kasi zaidi kuliko ikiwa unafanya bila mazoezi kabisa, lakini kwenye mpira.
Hili ni wazo lisilo wazi na ngumu sana. Unaposikia kwamba sasa nitaandika vipimo zaidi na wakati huo huo nitafanya kitu kwa kasi, inaonekana kuwa haitoshi kabisa.
(Dmitry) Watu wengi hapa, wanapoita MVP, watu ni wavivu sana kuandika kitu cha kawaida. Na haya bado ni mambo tofauti. Hakuna haja ya kugeuza MVP kuwa kitu kibaya ambacho hakifanyi kazi.
Ndiyo, ndiyo, uko sahihi.
Na kisha ghafla MVP katika prod.
Milele.
Na TDD inaonekana isiyo ya kawaida sana unaposikia kwamba unaandika majaribio na unaonekana kufanya kazi zaidi. Inaonekana ya kushangaza sana, lakini kwa kweli inageuka haraka na nzuri zaidi kwa njia hii. Unapoandika mtihani, tayari unafikiri sana katika kichwa chako kuhusu kanuni gani itaitwa na jinsi gani, pamoja na tabia gani tunayotarajia kutoka kwake. Husemi tu niliandika kazi fulani na inafanya kitu. Mwanzoni ulifikiri kwamba ana hali kama hizi, angeitwa kwa namna fulani. Unafunika hili kwa majaribio na kutokana na hili unaelewa jinsi violesura vyako vitaonekana ndani ya msimbo wako. Hii ina athari kubwa kwa usanifu. Nambari yako moja kwa moja inakuwa ya kawaida zaidi, kwa sababu kwanza unajaribu kuelewa jinsi utakavyoijaribu, na kisha kuiandika.
Kilichonitokea na TDD ni kwamba wakati fulani niliajiri mshauri wa Ruby nilipokuwa bado mtayarishaji wa programu ya Ruby. Na anasema: "Wacha tuifanye kulingana na TDD." Niliwaza: "Damn, sasa lazima niandike kitu cha ziada." Na tulikubaliana kuwa ndani ya wiki mbili nitaandika nambari zote za kufanya kazi huko Python kwa kutumia TDD. Baada ya wiki mbili, niligundua kuwa sitaki kurudi. Baada ya wiki mbili za kujaribu kutumia hii kila mahali, unagundua jinsi imekuwa rahisi kwako hata kufikiria tu. Lakini hii sio dhahiri, kwa hivyo ninapendekeza kwa kila mtu kwamba ikiwa una hisia kwamba TDD ni ngumu, hutumia wakati na sio lazima, jaribu kushikamana nayo kwa wiki mbili tu. Mbili zilinitosha.
(Dmitry) Tunaweza kupanua wazo hili kutoka kwa mtazamo wa uendeshaji wa miundombinu. Kabla ya kuzindua chochote kipya, tunafanya ufuatiliaji na kisha kuzindua. Katika kesi hii, ufuatiliaji unakuwa upimaji wa kawaida kwetu. Na kuna maendeleo kupitia ufuatiliaji. Lakini karibu kila mtu anasema kuwa ni muda mrefu, mimi ni mvivu, nilifanya rasimu ya muda. Ikiwa tumefanya ufuatiliaji wa kawaida, tunaelewa hali ya mfumo wa CI. Na mfumo wa CI una ufuatiliaji mwingi. Tunaelewa hali ya mfumo, tunaelewa kilicho ndani yake. Na wakati wa maendeleo, tunafanya tu mfumo ili ufikie hali inayotakiwa.
Mazoea haya yamejulikana kwa muda mrefu. Tulijadili hili kuhusu miaka 4 iliyopita. Lakini katika miaka 4 kivitendo hakuna kilichobadilika.
Lakini kwa maelezo haya, napendekeza kumaliza mjadala rasmi.
Video (iliyoingizwa kama kipengele cha media, lakini kwa sababu fulani haifanyi kazi):
Chanzo: mapenzi.com