ProHoster > Blogs > Administrācija > Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

ApspriedÄ«sim, kāpēc CI rÄ«ki un CI ir pilnÄ«gi atŔķirÄ«gas lietas.

Kādas sāpes ir paredzēts atrisināt CI, no kurienes radās ideja, kādi ir pēdējie apstiprinājumi, ka tas darbojas, kā saprast, ka jums ir prakse, nevis vienkārÅ”i instalēja Dženkinsu.

Ideja veidot reportāžu par Nepārtraukto integrāciju radās pirms gada, kad gāju uz intervijām un meklēju darbu. Es runāju ar 10-15 uzņēmumiem, tikai viens no viņiem spēja skaidri atbildēt, kas ir CI, un paskaidrot, kā viņi saprata, ka viņiem tā nav. Pārējie runāja nesaprotamas muļķības par Dženkinsu :) Nu mums ir Dženkinss, tas taču bÅ«vē, CI! Ziņojuma laikā es mēģināŔu izskaidrot, kas patiesÄ«bā ir nepārtrauktā integrācija un kāpēc Jenkins un lÄ«dzÄ«giem rÄ«kiem ir ļoti vāja saistÄ«ba ar to.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Tātad, kas parasti nāk prātā, dzirdot vārdu CI? Lielākā daļa cilvēku domās par Dženkinsu, Gitlab CI, Trevisu utt.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Pat ja mēs to meklēsim Google, tas mums dos Å”os rÄ«kus.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Ja esat iepazinies ar jautāŔanu, tad uzreiz pēc rÄ«ku uzskaitÄ«Å”anas viņi jums pateiks, ka CI ir tad, kad veidojat un palaižat pārbaudes saistÄ«bā ar piesaistes pieprasÄ«jumu.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Nepārtrauktā integrācija nav saistÄ«ta ar instrumentiem, nevis par komplektiem ar testiem filiālē! Nepārtrauktā integrācija ir ļoti bieža jauna koda integrācijas prakse, un tā izmantoÅ”anai nemaz nav nepiecieÅ”ams norobežot Jenkins, GitLab utt.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Pirms izdomājam, kā izskatās pilnvērtīga KI, vispirms iedziļināsimies to cilvēku kontekstā, kuri to izdomāja, un sajutīsim sāpes, kuras viņi mēģināja atrisināt.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Un viņi atrisināja sāpes, strādājot kopā kā komandai!

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Apskatīsim piemērus, ar kādām grūtībām saskaras izstrādātāji, attīstoties komandās. Šeit mums ir projekts, git galvenā filiāle un divi izstrādātāji.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Un viņi devās uz darbu, kā visi jau sen bija pieraduÅ”i. Mēs paņēmām uzdevumu lielajā lietu shēmā, izveidojām funkciju zaru un uzrakstÄ«jām kodu.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Viens pabeidza funkciju ātrāk un apvienoja to galvenajā.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Otrajam vajadzēja vairāk laika, tas vēlāk saplÅ«da un beidzās ar konfliktu. Tagad tā vietā, lai rakstÄ«tu uzņēmumam nepiecieÅ”amās funkcijas, izstrādātājs tērē savu laiku un enerÄ£iju konfliktu risināŔanai.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Jo grÅ«tāk ir apvienot savu funkciju ar kopÄ«gu meistaru, jo vairāk laika mēs tam veltām. Un es to parādÄ«ju ar diezgan vienkārÅ”u piemēru. Å is ir piemērs, kur izstrādātāji ir tikai 2. Iedomājieties, ja vienā repozitorijā raksta 10 vai 15 vai 100 cilvēki uzņēmumā. JÅ«s kļūsiet traks, lai atrisinātu visus Å”os konfliktus.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Ir nedaudz atŔķirīgs gadījums. Mums ir meistars un daži izstrādātāji, kas kaut ko dara.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Viņi izveidoja zariņu.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Viens nomira, viss bija kārtībā, izturēja uzdevumu.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Tikmēr otrais izstrādātājs nodeva savu uzdevumu. Pieņemsim, ka viņŔ to nosÅ«tÄ«ja pārskatÄ«Å”anai. Daudziem uzņēmumiem ir prakse, ko sauc par pārskatÄ«Å”anu. No vienas puses, Ŕī prakse ir laba un noderÄ«ga, no otras puses, tā mÅ«s daudzējādā ziņā bremzē. Mēs tajā neiedziļināsimies, taču Å”eit ir lielisks piemērs tam, pie kā var novest slikts pārskats. JÅ«s esat iesniedzis pārvilkÅ”anas pieprasÄ«jumu pārskatÄ«Å”anai. Izstrādātājam vairs nav ko darÄ«t. Ko viņŔ sāk darÄ«t? ViņŔ sāk uzņemties citus uzdevumus.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Šajā laikā otrais izstrādātājs darīja kaut ko citu.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Pirmais izpildīja treŔo uzdevumu.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Un pēc kāda laika viņa pārskats tika pārbaudÄ«ts, un viņŔ cenÅ”as samierināties. Tātad, kas notiek? Tas uztver milzÄ«gu skaitu konfliktu. Kāpēc? Jo, kamēr viņa atsaukÅ”anas pieprasÄ«jums karājās pārskatā, kodā daudzas lietas jau bija mainÄ«juŔās.

Papildus stāstam ar konfliktiem ir stāsts ar komunikācijām. Kamēr jÅ«su pavediens tiek pārskatÄ«ts, kamēr tas kaut ko gaida, kamēr jÅ«s ilgu laiku strādājat pie funkcijas, jÅ«s pārtraucat izsekot, kas vēl mainās jÅ«su pakalpojuma kodu bāzē. Iespējams, tas, ko mēģināt atrisināt tagad, jau tika atrisināts vakar, un varat izmantot kādu metodi un izmantot to atkārtoti. Bet jÅ«s to neredzēsit, jo vienmēr strādājat ar novecojuÅ”u filiāli. Un Ŕī novecojusi filiāle vienmēr noved pie tā, ka jums ir jāatrisina apvienoÅ”anas konflikts.

Izrādās, ja mēs strādājam kā komanda, t.i., krātuvē nemanās nevis viens cilvēks, bet 5-10 cilvēki, tad jo ilgāk mēs nepievienojam savu kodu masteram, jo ā€‹ā€‹vairāk cieÅ”am, jo ā€‹ā€‹galu galā mums vajag. kaut ko tad sapludini. Un jo vairāk mums ir konfliktu un jo vecāku versiju mēs strādājam, jo ā€‹ā€‹vairāk problēmu mums ir.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Kopā kaut ko darīt ir sāpīgi! Mēs vienmēr traucējam viens otram.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Å Ä« problēma tika pamanÄ«ta pirms vairāk nekā 20 gadiem. Es atradu pirmo pieminējumu par nepārtrauktas integrācijas praksi ekstrēmā programmÄ“Å”anā.

Extreme Programming ir pirmā elastÄ«gā sistēma. Lapa parādÄ«jās 96. gadā. Un bija doma izmantot kaut kādu programmÄ“Å”anas praksi, plānoÅ”anu un citas lietas, lai izstrāde bÅ«tu pēc iespējas elastÄ«gāka, lai mēs varētu ātri reaģēt uz jebkurām izmaiņām vai prasÄ«bām no mÅ«su klientu puses. Un viņi sāka saskarties ar to pirms 24 gadiem, ka, ja tu kaut ko dari ļoti ilgi un malā, tad tu tam velti vairāk laika, jo tev ir konflikti.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Tagad mēs atseviŔķi analizēsim frāzi ā€œNepārtraukta integrācijaā€. Ja mēs to tulkojam tieÅ”i, mēs iegÅ«stam nepārtrauktu integrāciju. Bet tas, cik tas ir nepārtraukts, nav Ä«sti skaidrs; tas ir ļoti pārtraukts. Bet tas, cik liela ir integrācija, arÄ« nav ļoti acÄ«mredzams.

Un tāpēc es jums tagad piedāvāju citātus no Extreme Programming. Un mēs analizēsim abus vārdus atseviŔķi.

Integrācija - Kā jau teicu, mēs cenÅ”amies nodroÅ”ināt, lai katrs inženieris strādātu ar jaunāko koda versiju, lai viņŔ censtos pēc iespējas biežāk pievienot savu kodu kopējai filiālei, lai tie bÅ«tu mazi zari. Jo, ja tie ir lieli, tad mēs varam viegli iestrēgt ar saplÅ«Å”anas konfliktiem uz nedēļu. Tas jo Ä«paÅ”i attiecas uz gadÄ«jumiem, kad mums ir garÅ” izstrādes cikls, piemēram, Å«denskritums, kur izstrādātājs devās prom uz mēnesi, lai izgrieztu kādu milzÄ«gu funkciju. Un viņŔ ļoti ilgi bÅ«s iestrēdzis integrācijas stadijā.

Integrācija ir tad, kad mēs paņemam savu filiāli un integrējam to ar meistaru, mēs to sapludinām. Ja mēs esam transbase izstrādātāji, mēs cenÅ”amies nodroÅ”ināt, ka mēs nekavējoties rakstām meistaram bez papildu atzarojumiem.

Kopumā integrācija nozÄ«mē koda paņemÅ”anu un ievilkÅ”anu galvenajā ierÄ«cē.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Kas Å”eit ir domāts ar vārdu ā€œnepārtrauktsā€, ko sauc par nepārtrauktÄ«bu? Prakse nozÄ«mē, ka izstrādātājs cenÅ”as pēc iespējas ātrāk integrēt savu kodu. Tas ir viņa mērÄ·is, veicot jebkuru uzdevumu - pēc iespējas ātrāk iegÅ«t savu kodu master. Ideālā pasaulē izstrādātāji to darÄ«tu ik pēc dažām stundām. Tas ir, jÅ«s ņemat nelielu problēmu un sapludināt to meistarā. Viss ir lieliski. Tas ir tas, uz ko jÅ«s tiecaties. Un tas ir jādara nepārtraukti. TiklÄ«dz tu kaut ko dari, tu to uzreiz ieliec meistarā.

Un izstrādātājs, kurÅ” kaut ko ražo, ir atbildÄ«gs par to, ko viņŔ darÄ«ja, lai tas izdotos un neko nesabojātu. Å eit parasti iznāk testa stāsts. Mēs vēlamies veikt dažus mÅ«su saistÄ«bu un sapludināŔanas testus, lai pārliecinātos, ka tas darbojas. Un Å”eit Dženkinss var jums palÄ«dzēt.

Bet ar stāstiem: padarÄ«sim izmaiņas mazas, ļausim uzdevumiem bÅ«t maziem, radÄ«sim problēmu un nekavējoties mēģināsim to kaut kā iegult meistarā - neviens Dženkinss Å”eit nepalÄ«dzēs. Jo Dženkinss tikai palÄ«dzēs jums veikt testus.

Jūs varat iztikt bez tiem. Tas jums nemaz nekaitēs. Jo prakses mērķis ir mērīt pēc iespējas biežāk, lai turpmāk netērētu milzīgu laiku kādiem konfliktiem.

Iedomāsimies, ka nez kāpēc esam 2020. gadā bez interneta. Un mēs strādājam uz vietas. Mums nav Dženkinsa. Tas ir labi. JÅ«s joprojām varat doties uz priekÅ”u un izveidot vietējo filiāli. JÅ«s tajā ierakstÄ«jāt kādu kodu. Uzdevumu paveicām 3-4 stundās. Mēs pārgājām uz master, veicām git pull un apvienojām savu filiāli tur. Gatavs. Ja jÅ«s to darāt bieži, apsveicam, jums ir nepārtraukta integrācija!

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Kādi pierādÄ«jumi mÅ«sdienu pasaulē ir, ka ir vērts tērēt enerÄ£iju? Jo kopumā ir grÅ«ti. Ja mēģināsit Ŕādi strādāt, sapratÄ«sit, ka tagad tiks ietekmēta kāda plānoÅ”ana, vairāk laika bÅ«s jāvelta uzdevumu sadalÄ«Å”anai. Jo, ja tu darÄ«si vÄ«rieti..., tad nespēsi ātri samierināties un attiecÄ«gi iekulties nepatikÅ”anās. Jums vairs nebÅ«s prakses.

Un tas bÅ«s dārgi. No rÄ«tdienas nebÅ«s iespējams strādāt uzreiz, izmantojot nepārtraukto integrāciju. Jums visiem bÅ«s nepiecieÅ”ams ļoti ilgs laiks, lai pierastu pie tā, jums bÅ«s nepiecieÅ”ams ļoti ilgs laiks, lai pierastu pie uzdevumu sadalÄ«Å”anas, bÅ«s nepiecieÅ”ams ļoti ilgs laiks, lai pierastu pie pārskatÄ«Å”anas prakses atkārtotas veikÅ”anas, ja jums tāda ir . Jo mÅ«su mērÄ·is ir, lai tas Å”odien izkÅ«st. Un, ja veicat pārskatÄ«Å”anu trÄ«s dienu laikā, jums ir problēmas un nepārtraukta integrācija jums nedarbojas.

Bet vai mums Å”obrÄ«d ir kādi bÅ«tiski pierādÄ«jumi, kas liecina, ka ir jēga ieguldÄ«t Å”ajā praksē?

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Pirmā lieta, kas man ienāca prātā, bija DevOps stāvoklis. Å is ir pētÄ«jums, ko puiÅ”i veic jau 7 gadus. Tagad viņi to dara kā neatkarÄ«ga organizācija, bet zem Google.

Un viņu 2018. gada pētÄ«jums parādÄ«ja korelāciju starp uzņēmumiem, kas cenÅ”as izmantot Ä«slaicÄ«gas filiāles, kas ātri integrējas, bieži integrējas un kurām ir labāki IT veiktspējas rādÄ«tāji.

Kādi ir Å”ie rādÄ«tāji? Å ie ir 4 rādÄ«tāji, ko viņi izmanto no visiem uzņēmumiem savās anketās: izvietoÅ”anas biežums, izmaiņu izpildes laiks, pakalpojuma atjaunoÅ”anas laiks, izmaiņu kļūmju lÄ«menis.

Un, pirmkārt, pastāv Ŕī korelācija, mēs zinām, ka uzņēmumiem, kas veic mērÄ«jumus, ir daudz labāki rādÄ«tāji. Un viņiem ir uzņēmumu iedalÄ«jums vairākās kategorijās: tie ir lēni uzņēmumi, kas ražo kaut ko lēni, ar vidēju veiktspēju, ar augstu veiktspēju un elite. Elite ir Netflix, Amazon, kas ir super ātri, dara visu ātri, skaisti un efektÄ«vi.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Otrs stāsts, kas notika tikai pirms mēneÅ”a. TehnoloÄ£iju radaram ir lielisks raksts par Gitflow. Gitflow atŔķiras no visiem citiem ar to, ka tā zari ir ilgmūžīgi. Ir izlaiduma zari, kas dzÄ«vo ilgu laiku, un ir zari, kas arÄ« dzÄ«vo ilgu laiku. Å Ä« prakse TehnoloÄ£iju radarā ir pārcelta uz HOLD. Kāpēc? Jo cilvēki saskaras ar integrācijas sāpēm.

Ja jÅ«su zars dzÄ«vo ļoti ilgu laiku, tas iestrēgst, sapuvis, un mēs sākam pavadÄ«t vairāk laika, cenÅ”oties veikt kaut kādas izmaiņas tajā.

Un nesen Gitflow autors teica, ka, ja jÅ«su mērÄ·is ir nepārtraukta integrācija, ja jÅ«su mērÄ·is ir tas, ka vēlaties ritināt cik bieži vien iespējams, tad Gitflow ir slikta ideja. ViņŔ rakstam atseviŔķi piebilda, ka, ja tev ir aizmugure, kur uz Å”o var tiekties, tad Gitflow tev ir lieks, jo Gitflow tevi bremzēs, Gitflow radÄ«s problēmas ar integrāciju.

Tas nenozÄ«mē, ka Gitflow ir slikta un to nevajadzētu izmantot. Tas ir citiem gadÄ«jumiem. Piemēram, ja jums ir jāatbalsta vairākas pakalpojuma vai lietojumprogrammas versijas, t.i., ja jums ir nepiecieÅ”ams atbalsts ilgu laiku.

Bet, ja jÅ«s runājat ar cilvēkiem, kas atbalsta Ŕādus pakalpojumus, jÅ«s dzirdēsiet daudz sāpju par to, ka Ŕī versija bija 3.2, kas bija pirms 4 mēneÅ”iem, bet Å”is labojums tajā nebija iekļauts un tagad, lai to izveidotu, jums ir jāveic vairākas izmaiņas. Un tagad viņi atkal ir iestrēguÅ”i, un tagad viņi jau nedēļu ir nerimstÄ«juÅ”ies, mēģinot ieviest kādu jaunu funkciju.

Kā tērzÄ“Å”anā pareizi atzÄ«mēja Aleksandrs Kovaļovs, korelācija nav tas pats, kas cēloņsakarÄ«ba. Tā ir patiesÄ«ba. Tas nozÄ«mē, ka nav tieÅ”as saiknes, ka, ja jums ir nepārtraukta integrācija, tad visi rādÄ«tāji bÅ«s lieliski. Bet ir pozitÄ«va korelācija, ka, ja viens ir viens, tad visticamāk arÄ« otrs. Nav fakts, bet visticamāk. Tā ir tikai korelācija.

Nepārtraukta integrācija kā prakse, nevis Dženkinss. Andrejs Aleksandrovs

Å Ä·iet, ka mēs jau kaut ko darām, Ŕķiet, ka mēs jau saplÅ«stam, bet kā saprast, ka mums joprojām ir Nepārtraukta integrācija, ka mēs diezgan bieži apvienojamies?

Jez Humble ir rokasgrāmatas, Accelerate, nepārtrauktās piegādes vietnes un grāmatas Continuous Delivery autors. ViņŔ piedāvā Å”o testu:

  • Inženiera kods katru dienu nokļūst pie meistara.
  • Par katru apņemÅ”anos jÅ«s veicat vienÄ«bu testus.
  • BÅ«ve meistarā nokrita, tika salabots apmēram 10 minÅ«tēs.

ViņŔ iesaka izmantot Ŕādu testu, lai pārliecinātos, ka jums ir pietiekami daudz prakses.

Pēdējais man Ŕķiet nedaudz pretrunÄ«gs. Tas ir, ja jÅ«s varat to salabot 10 minÅ«tēs, tad jums ir nepārtraukta integrācija, tas, manuprāt, izklausās nedaudz dÄ«vaini, bet tam ir jēga. Kāpēc? Jo, ja jÅ«s bieži sasalst, tas nozÄ«mē, ka jÅ«su izmaiņas ir nelielas. Ja nelielas izmaiņas nozÄ«mē, ka jÅ«su galvenā konstrukcija ir bojāta, varat ātri atrast piemēru, jo izmaiņas ir nelielas. Å eit jums bija neliela sapludināŔana, tajā mainÄ«jās 20-30 rindiņas. Un, attiecÄ«gi, jÅ«s varat ātri saprast, kas bija iemesls, jo izmaiņas ir niecÄ«gas, jums ir ļoti mazs apgabals, kur meklēt problēmu.

Un pat tad, ja mÅ«su produkts pēc izlaiÅ”anas sabrÅ«k, tad, ja mums ir nepārtrauktas integrācijas prakse, mums ir daudz vieglāk rÄ«koties, jo izmaiņas ir niecÄ«gas. Jā, tas ietekmēs plānoÅ”anu. Tas sāpēs. Un, iespējams, visgrÅ«tākais Å”ajā praksē ir pierast pie uzdevumu sadalÄ«Å”anas, tas ir, kā to izdarÄ«t tā, lai jÅ«s varētu kaut ko paņemt un izdarÄ«t dažu stundu laikā un tajā paŔā laikā iziet apskatu, ja tev tāds ir. PārskatÄ«Å”ana ir atseviŔķa sāpe.

Vienības testi ir tikai palīgs, kas palīdz saprast, vai integrācija bija veiksmīga un vai nekas nav bojāts. Manuprāt, tas arī nav pilnīgi obligāts, jo tas nav prakses jēga.

Šis ir īss ievads nepārtrauktai integrācijai. Tas ir viss, kas attiecas uz Ŕo praksi. Esmu gatavs uzdot jautājumus.

Es vēlreiz Ä«si apkopoÅ”u:

  • Nepārtraukta integrācija nav Jenkins, tā nav Gitlab.
  • Tas nav rÄ«ks, tā ir prakse, ka mēs pēc iespējas biežāk sapludinām savu kodu galvenajā.
  • Mēs to darām, lai nākotnē izvairÄ«tos no milzÄ«gajām sāpēm, kas rodas saplÅ«Å”anas rezultātā, tas ir, mēs piedzÄ«vojam nelielas sāpes tagad, lai nepiedzÄ«votu vairāk nākotnē. Tā ir visa bÅ«tÄ«ba.
  • Sānos ir saziņa caur kodu, bet es to redzu ļoti reti, bet arÄ« tas ir paredzēts tam.

jautājumi

Ko darīt ar nesadalītiem uzdevumiem?

Sadalās. Kāda ir problēma? Vai varat sniegt piemēru, ka ir uzdevums un tas nav sadalīts?

Ir uzdevumi, kurus nevar atdalÄ«t no vārda ā€œpilnÄ«giā€, piemēram, tādi, kuriem nepiecieÅ”amas ļoti dziļas zināŔanas un kurus faktiski var atrisināt mēneÅ”a laikā, lai sasniegtu kādu sagremojamu rezultātu.

Ja pareizi saprotu, tad ir kāds liels un sarežģīts uzdevums, kura rezultāts bÅ«s redzams tikai pēc mēneÅ”a?

Jā, tieÅ”i tā. Jā, rezultātu varēs novērtēt ne ātrāk kā pēc mēneÅ”a.

Labi. Kopumā tā nav problēma. Kāpēc? Jo Å”ajā gadÄ«jumā, kad mēs runājam par zariem, mēs nerunājam par zaru ar pazÄ«mi. Funkcijas var bÅ«t lielas un sarežģītas. Tie var ietekmēt lielu skaitu komponentu. Un, iespējams, mēs nevaram tos veikt pilnÄ«bā vienā nozarē. Tas ir labi. Mums vienkārÅ”i jāizjauc Å”is stāsts. Ja lÄ«dzeklis nav pilnÄ«bā gatavs, tas nenozÄ«mē, ka dažas tā koda daļas nevar sapludināt. JÅ«s pievienojāt, piemēram, migrāciju, un funkcijai ir daži posmi. Pieņemsim, ka jums ir posms ā€” veiciet migrāciju, pievienojiet jaunu metodi. Un Ŕīs lietas jau var mērÄ«t katru dienu.

Labi. Kāda tad jēga?

Kāda jēga katru dienu nogalināt mazas lietas?

Jā.

Ja viņi kaut ko salauž, jÅ«s to uzreiz redzat. Jums ir mazs gabals, kas kaut ko ir salauzis, jums ir vieglāk to salabot. Lieta ir tāda, ka sapludināt nelielu gabalu tagad ir daudz vieglāk nekā sapludināt kaut ko lielu dažu nedēļu laikā. Un treÅ”ais punkts ir tas, ka citi inženieri strādās ar paÅ”reizējo koda versiju. Viņi redzēs, ka Å”eit ir pievienotas dažas migrācijas, un pēc tam ir parādÄ«jusies kāda metode, kuru viņi arÄ« vēlas izmantot. Ikviens redzēs, kas notiek jÅ«su kodā. TieÅ”i Ŕīm trim lietām tiek veikta prakse.

Paldies, jautājums ir slēgts!

(Oļegs Soroka) Vai drīkstu piebilst? Jūs visu pateicāt pareizi, es tikai vēlos pievienot vienu frāzi.

Š¢Š°Šŗ.

Izmantojot nepārtraukto integrāciju, kods tiek sapludināts kopējā atzarā nevis tad, kad lÄ«dzeklis ir pilnÄ«bā gatavs, bet gan tad, kad bÅ«vējums pārstāj bojāties. Un jÅ«s varat droÅ”i apņemties apgÅ«t tik reižu dienā, cik vēlaties. Otrs aspekts ir tāds, ka, ja kaut kādu iemeslu dēļ nevarat sadalÄ«t ikmēneÅ”a uzdevumu uzdevumos vismaz trÄ«s dienas, es klusēju apmēram trÄ«s stundas, tad jums ir milzÄ«ga problēma. Un fakts, ka jums nav nepārtrauktas integrācijas, ir mazākā no Ŕīm problēmām. Tas nozÄ«mē, ka jums ir problēmas ar arhitektÅ«ru un nulles inženiertehnisko praksi. Jo pat ja tas ir pētÄ«jums, tad jebkurā gadÄ«jumā tas ir jāformulē hipotēžu vai cikla veidā.

Mēs runājām par 4 rādÄ«tājiem, kas atŔķir veiksmÄ«gus uzņēmumus no atpalikuÅ”iem. Mums vēl ir jādzÄ«vo, lai redzētu Å”os 4 rādÄ«tājus. Ja jÅ«su vidējā uzdevuma izpilde prasa mēnesi, es vispirms pievērsÄ«Å”os Å”im rādÄ«tājam. Vispirms es to samazinātu lÄ«dz 3 dienām. Un pēc tam es sāku domāt par Continuous.

Vai es pareizi sapratu, ka jūs domājat, ka vispār nav jēgas investēt inženiertehniskajās praksēs, ja kāda uzdevuma izpilde prasa mēnesi?

Jums ir nepārtraukta integrācija. Un ir tāda tēma, ka 10 minÅ«tēs var vai nu labot labojumu, vai atvilkt. Iedomājieties, ka esat to izrullējis. Turklāt jums pat ir nepārtraukta izvietoÅ”ana, jÅ«s to izlaidāt uz prod un tikai tad pamanÄ«jāt, ka kaut kas nogāja greizi. Un jums tas ir jāatgriež, bet jÅ«s jau esat migrējis savu datu bāzi. Tev jau ir nākamās versijas datu bāzes shēma, turklāt tev bija arÄ« kaut kāds dublējums, un tur arÄ« tika ierakstÄ«ti dati.

Un kāda jums ir alternatÄ«va? Ja atcelsit kodu, tas vairs nevarēs darboties ar Å”o atjaunināto datu bāzi.

Bāze virzās tikai uz priekŔu, jā.

Cilvēki, kuriem ir slikta inženieru prakse, visticamāk, arÄ« nav lasÄ«juÅ”i biezo grāmatu par.... Ko darÄ«t ar dublējumu? Ja atjaunojat no dublējuma, tas nozÄ«mē, ka jÅ«s zaudējat tajā brÄ«dÄ« uzkrātos datus. Piemēram, trÄ«s stundas strādājām ar jauno datu bāzes versiju, tur reÄ£istrējās lietotāji. JÅ«s atsakāties no vecā dublējuma, jo shēma nedarbojas ar jauno versiju, tāpēc esat pazaudējis Å”os lietotājus. Un viņi ir neapmierināti, viņi zvēr.

Lai apgÅ«tu visu prakÅ”u klāstu, kas atbalsta nepārtrauktu integrāciju un nepārtrauktu piegādi, nepietiek tikai iemācÄ«ties rakstÄ«t.... Pirmkārt, to var bÅ«t daudz, tas bÅ«s nepraktiski. Turklāt ir virkne citu prakÅ”u, piemēram, zinātniskā. Ir tāda prakse, GitHub to savulaik popularizēja. Tas ir tad, kad vienlaikus darbojas gan vecais kods, gan jaunais kods. Tas ir tad, kad izveidojat nepabeigtu lÄ«dzekli, bet tas var atgriezt kādu vērtÄ«bu: vai nu kā funkcija, vai kā Rest API. JÅ«s izpildāt gan jauno kodu, gan veco kodu un salÄ«dziniet atŔķirÄ«bu starp tiem. Un, ja ir atŔķirÄ«ba, tad jÅ«s reÄ£istrējat Å”o notikumu. Tādā veidā jÅ«s zināt, ka jums ir jauna funkcija, kas ir gatava izvērÅ”anai papildus vecajai, ja noteiktu laiku nav bijuÅ”as atŔķirÄ«bas starp tām.

Ir simtiem Ŕādu prakÅ”u. Es ieteiktu sākt ar transbāzes izstrādi. Viņa nav 100% uz Nepārtrauktas integrācijas, bet prakse ir tāda pati, viens nevar dzÄ«vot bez otra.

Vai jūs minējāt transbāzes izstrādi kā piemēru, kur var redzēt praksi, vai arī ieteicāt cilvēkiem sākt izmantot transbāzes attīstību?

Paskatieties, jo viņi to nevarēs izmantot. Lai tos izmantotu, jums ir daudz jālasa. Un, kad cilvēks jautā: "Ko darÄ«t ar funkciju, kas aizņem mēnesi, tas nozÄ«mē, ka viņŔ nav lasÄ«jis par transbāzes izstrādi." Es to vēl neieteiktu. Es ieteiktu koncentrēties tikai uz tēmu, kā pareizi arhitektoniski sadalÄ«t lielus uzdevumus mazākos. Tāda ir sadalÄ«Å”anās bÅ«tÄ«ba.

DekompozÄ«cija ir viens no arhitekta instrumentiem. Vispirms veicam analÄ«zi, tad sadalÄ«Å”anu, tad sintēzi, tad integrāciju. Un tā mums viss izdodas. Un mums joprojām ir jāizaug lÄ«dz nepārtrauktai integrācijai sadalÄ«Å”anās ceļā. Jautājumi rodas pirmajā posmā, un mēs jau runājam par ceturto posmu, t.i., jo biežāk mēs veiksim integrāciju, jo labāk. Vēl ir pāragri to darÄ«t; bÅ«tu jauki vispirms nogriezt savu monolÄ«tu.

Uz kādas diagrammas ir jāuzzÄ«mē vairākas bultiņas un kvadrāti. Nevarētu teikt, ka tagad es parādÄ«Å”u jaunas lietojumprogrammas arhitektÅ«ras shēmu un parādÄ«Å”u vienu kvadrātu, kura iekÅ”pusē ir zaļa lietojumprogrammas poga. Jebkurā gadÄ«jumā bÅ«s vairāk kvadrātu un bultu. Katrā diagrammā, ko es redzēju, bija vairāk nekā viena. Un sadalÄ«Å”anās pat grafiskā attēlojuma lÄ«menÄ« jau notiek. Tāpēc kvadrātus var padarÄ«t neatkarÄ«gus. Ja nē, tad man ir lieli jautājumi arhitektam.

TērzÄ“Å”anā ir jautājums: "Ja pārskatÄ«Å”ana ir obligāta un prasa ilgu laiku, varbÅ«t dienu vai vairāk?"

Jums ir problēmas ar praksi. PārskatÄ«Å”ana nedrÄ«kst ilgt vienu dienu vai ilgāk. Å is ir tas pats stāsts par iepriekŔējo jautājumu, tikai nedaudz mÄ«kstāks. Ja pārskatÄ«Å”ana turpinās vienu dienu, tad, visticamāk, Å”ajā pārskatā notiek kādas ļoti lielas izmaiņas. Tas nozÄ«mē, ka tas ir jāsamazina. Transbase izstrādē, ko Oļegs ieteica, ir stāsts, ko sauc par nepārtrauktu pārskatÄ«Å”anu. Viņas ideja ir tāda, ka mēs ar nolÅ«ku izdarām tik mazu pievilkÅ”anas pieprasÄ«jumu, jo mēs cenÅ”amies pastāvÄ«gi un nedaudz apvienoties. Tādējādi izvilkÅ”anas pieprasÄ«jums maina vienu abstrakciju vai 10 rindiņas. Pateicoties Å”im pārskatam, tas aizņem dažas minÅ«tes.

Ja pārskatÄ«Å”ana ilgst dienu vai vairāk, kaut kas nav kārtÄ«bā. Pirmkārt, jums var bÅ«t dažas problēmas ar arhitektÅ«ru. Vai arÄ« tas ir liels koda fragments, piemēram, 1 rindiņas. Vai arÄ« jÅ«su arhitektÅ«ra ir tik sarežģīta, ka cilvēks to nevar saprast. Å Ä« ir nedaudz sānu problēma, taču tā arÄ« bÅ«s jāatrisina. VarbÅ«t pārskats vispār nav vajadzÄ«gs. Mums arÄ« par to ir jādomā. PārskatÄ«Å”ana ir lieta, kas jÅ«s bremzē. Kopumā tam ir savas priekÅ”rocÄ«bas, taču jums ir jāsaprot, kāpēc jÅ«s to darāt. Vai tas ir veids, kā jÅ«s varat ātri nodot informāciju, vai tas ir veids, kā iekŔēji noteikt dažus standartus vai kā? Kāpēc jums tas ir vajadzÄ«gs? Jo pārskatÄ«Å”ana ir jāveic vai nu ļoti ātri, vai arÄ« jāatceļ pavisam. Tas ir kā transbase deveploment - stāsts ir ļoti skaists, bet tikai nobrieduÅ”iem puiÅ”iem.

Attiecībā uz četriem rādītājiem es tomēr ieteiktu tos noņemt, lai saprastu, pie kā tas noved. Paskaties uz skaitļiem, paskaties uz bildi, cik viss ir slikti.

(Dmitrijs) Esmu gatavs ar jums uzsākt diskusiju par Å”o tēmu. Skaitļi un rādÄ«tāji ir lieliski, prakse ir lieliska. Bet jums ir jāsaprot, vai uzņēmumam tas ir vajadzÄ«gs. Ir uzņēmumi, kuriem Ŕāds pārmaiņu ātrums nav vajadzÄ«gs. Zinu uzņēmumus, kuros izmaiņas nevar veikt ik pēc 15 minÅ«tēm. Un ne tāpēc, ka viņi ir tik slikti. Tas ir tāds dzÄ«ves cikls. Un, lai izveidotu filiāļu funkciju, pārslēgÅ”anas funkciju, jums ir nepiecieÅ”amas dziļas zināŔanas.

Tas ir sarežģīti. Ja vēlaties sÄ«kāk izlasÄ«t stāstu par pārslēgÅ”anas funkciju, es to ļoti iesaku https://trunkbaseddevelopment.com/. Un ir brÄ«niŔķīgs Martin Fowler raksts par pārslēgÅ”anas funkcijām: kādi veidi ir, dzÄ«ves cikli utt. PārslēgÅ”anas funkcija ir sarežģīta.

Un jūs joprojām neesat atbildējis uz jautājumu: "Vai Dženkinss ir vajadzīgs vai nē?"

Dženkinss nekādā gadÄ«jumā nav vajadzÄ«gs. Tomēr nopietni, rÄ«ki: Jenkins, Gitlab nodroÅ”inās jums ērtÄ«bas. JÅ«s redzēsiet, vai montāža ir samontēta vai nav salikta. Viņi var jums palÄ«dzēt, bet nedos jums praksi. Viņi var jums pieŔķirt tikai loku ā€” Ok, nevis Ok. Un tad, ja raksti arÄ« kontroldarbus, jo ja kontroldarbu nav, tad gandrÄ«z bezjēdzÄ«gi. Tāpēc tas ir vajadzÄ«gs, jo tas ir ērtāk, bet kopumā jÅ«s varat dzÄ«vot bez tā, jÅ«s daudz nezaudēsit.

Tas ir, ja jums ir prakse, vai tas nozīmē, ka jums tas nav vajadzīgs?

Pareizi. Es iesaku Jez Humble testu. Tur man ir ambivalenta attieksme pret pēdējo punktu. Bet kopumā, ja jums ir trīs lietas, jūs pastāvīgi sapludināt, izpildāt commit testus galvenajā versijā, ātri salabojat būvējumu galvenajā versijā, tad, iespējams, jums nekas cits nav vajadzīgs.

Kamēr gaidām dalÄ«bnieku jautājumus, man ir jautājums. Mēs tikai runājām par produkta kodu. Vai esat to izmantojis infrastruktÅ«ras kodam? Vai tas ir viens un tas pats kods, vai tam ir vienādi principi un viens un tas pats dzÄ«ves cikls, vai arÄ« pastāv dažādi dzÄ«ves cikli un principi? Parasti, kad visi runā par nepārtrauktu integrāciju un attÄ«stÄ«bu, visi aizmirst, ka ir arÄ« infrastruktÅ«ras kods. Un pēdējā laikā to kļūst arvien vairāk. Un vai visi Å”ie noteikumi ir jānes tur?

Pat ne tā vajadzētu būt, tas būtu lieliski, jo tas tāpat atvieglotu dzīvi. Tiklīdz mēs strādājam ar kodu, nevis ar bash skriptiem, bet mums ir normāls kods.

Stop, stop, bash skripts arī ir kods. Neaiztiec manu veco mīlestību.

Labi, es nemidÄ«Å”u tavas atmiņas. Man personÄ«gi nepatÄ«k bash. Tas visu laiku saplÄ«st neglÄ«ti un biedējoÅ”i. Un tas bieži saplÄ«st neparedzami, tāpēc man tas nepatÄ«k. Bet labi, pieņemsim, ka jums ir bash kods. VarbÅ«t es tieŔām nesaprotu, un tur ir normālas testÄ“Å”anas sistēmas. Es vienkārÅ”i nezinu. Un mēs saņemam tādas paÅ”as priekÅ”rocÄ«bas.

TiklÄ«dz mēs strādājam ar infrastruktÅ«ru kā kodu, mēs saņemam visas tās paÅ”as problēmas kā izstrādātāji. Pirms dažiem mēneÅ”iem es saskāros ar situāciju, kad kolēģis man nosÅ«tÄ«ja 1 rindiņu izvilkÅ”anas pieprasÄ«jumu bash. Un jÅ«s pavadāt apskatu 000 stundas. Rodas tādas paÅ”as problēmas. Tas joprojām ir kods. Un tā joprojām ir sadarbÄ«ba. Mēs iestrēgstam ar vilkÅ”anas pieprasÄ«jumu, un mēs iestrēgstamies ar to, ka mēs, piemēram, risinām tos paÅ”us sapludināŔanas konfliktus vienā un tajā paŔā bash.

Es tagad ļoti aktÄ«vi skatos uz Å”o visu par skaistāko infra programmÄ“Å”anu. Pulumi tagad esmu ievedis infrastruktÅ«rā. Tā ir programmÄ“Å”ana tās tÄ«rākajā formā. Tur tas ir vēl jaukāk, jo man ir visas programmÄ“Å”anas valodas iespējas, t.i., es uztaisÄ«ju skaistu slēdzi no zila gaisa ar tiem paÅ”iem ifs un viss ir kārtÄ«bā. Tas ir, mana maiņa jau ir meistarā. Viņu jau visi var redzēt. Citi inženieri par to zina. Tas jau tur kaut ko ir ietekmējis. Tomēr tas nebija iespējots visām infrastruktÅ«rām. Tā ieslēdzās, piemēram, maniem testu stendiem. Tāpēc, lai vēlreiz atbildētu uz jÅ«su jautājumu, tas ir nepiecieÅ”ams. Tas padara dzÄ«vi vieglāku mums, inženieriem, kas strādā ar kodu, tādā paŔā veidā.

Ja vēl kādam ir jautājumi?

Man ir jautājums. Es gribu turpināt diskusiju ar Oļegu. Kopumā es domāju, ka jums ir taisnÄ«ba, ka, ja uzdevuma izpilde prasa mēnesi, tad jums ir problēmas ar arhitektÅ«ru, jums ir problēmas ar analÄ«zi, sadalÄ«Å”anu, plānoÅ”anu utt. Bet man ir sajÅ«ta, ka, ja jÅ«s sākat mēģinot dzÄ«vot saskaņā ar Nepārtraukto integrāciju, tad sāksi labot sāpes ar plānoÅ”anu, jo nekur citur no tās netiksi.

(Oļegs) Jā, tieÅ”i tā. Å Ä« prakse ir salÄ«dzināma ar jebkuru citu nopietnu kultÅ«ru mainoÅ”u praksi. VisgrÅ«tāk ir pārvarēt ieradumus, Ä«paÅ”i sliktos ieradumus. Un, ja Ŕīs prakses Ä«stenoÅ”anai ir nepiecieÅ”amas nopietnas apkārtējo cilvēku paradumu maiņa: izstrādātāji, vadÄ«ba, ražoÅ”anas vadÄ«tājs, tad jÅ«s gaida pārsteigumi.

Kādi varētu bÅ«t pārsteigumi? Pieņemsim, ka jÅ«s nolemjat, ka integrēsities biežāk. Un jums ir dažas citas lietas, kas saistÄ«tas ar integrāciju, piemēram, artefakti. Un jÅ«su uzņēmumā, piemēram, ir politika, ka katrs artefakts ir kaut kādā veidā jāuzskaita kaut kādā artefaktu glabāŔanas sistēmā. Un tas aizņem kādu laiku. Personai ir jāatzÄ«mē izvēles rÅ«tiņa, ka viņŔ kā izlaiÅ”anas pārvaldnieks ir pārbaudÄ«jis Å”o artefaktu, lai nodroÅ”inātu, ka tas ir gatavs izlaiÅ”anai ražoÅ”anā. Ja tas aizņem 5-10-15 minÅ«tes, bet maketÄ“Å”anu veicat reizi nedēļā, tad tērēt pusstundu reizi nedēļā ir mazs nodoklis.

Ja jÅ«s veicat nepārtrauktu integrāciju 10 reizes dienā, tad 10 reizes jāreizina ar 30 minÅ«tēm. Un tas pārsniedz Ŕī izlaiduma pārvaldnieka darba laiku. Viņam vienkārÅ”i apnÄ«k to darÄ«t. Dažām praksēm ir fiksētas izmaksas. Tas ir viss.

Un jums ir vai nu jāatceļ Å”is noteikums, lai jÅ«s vairs nedarÄ«tu Ŕādu atkritumu, t.i., jÅ«s manuāli nepieŔķirat grādu, lai kaut kam atbilstu. JÅ«s pilnÄ«bā paļaujaties uz kādu automatizētu gatavÄ«bas pārbaužu komplektu.

Un, ja jums ir nepiecieÅ”ams pierādÄ«jums no kāda, lai priekÅ”nieks to parakstÄ«tu, un jÅ«s neiekļūtu ražoÅ”anā, ja Vasja nesaka, ka viņŔ to atļauj utt. - visas Ŕīs muļķības traucē praktizētājam. Jo, ja ir kādas darbÄ«bas, kas saistÄ«tas ar nodokli, tad viss palielinās 100 reizes. Tāpēc maiņu nereti visi sagaidÄ«s ar prieku. Jo cilvēku paradumus ir grÅ«ti mainÄ«t.

Kad cilvēks dara savu ierasto darbu, viņŔ to dara gandrÄ«z nedomājot. Viņas kognitÄ«vā slodze ir nulle. ViņŔ vienkārÅ”i spēlējas ar to, viņam jau ir kontrolsaraksts galvā, viņŔ to ir izdarÄ«jis tÅ«kstoÅ” reižu. Un, tiklÄ«dz jÅ«s atnākat un sakāt viņam: ā€œAtcelsim Å”o praksi un ieviesÄ«sim jaunu, sākot no pirmdienasā€, viņam tā kļūst par spēcÄ«gu izziņas slodzi. Un tas nāk visiem uzreiz.

Tāpēc vienkārŔākā lieta, lai gan ne visi var atļauties Å”o greznÄ«bu, bet tas ir tas, ko es vienmēr daru, tas ir sekojoÅ”s. Ja sākas jauns projekts, tad parasti visas nepārbaudÄ«tās prakses uzreiz tiek saspiestas Å”ajā projektā. Kamēr projekts ir jauns, mēs Ä«sti neriskējam ar neko. Prod vēl nav, nav ko iznÄ«cināt. Tāpēc to var izmantot kā apmācÄ«bu. Å Ä« pieeja darbojas. Taču ne visiem uzņēmumiem ir iespēja bieži uzsākt Ŕādus projektus. Lai gan arÄ« tas ir nedaudz dÄ«vaini, jo tagad notiek pilnÄ«ga digitālā transformācija, ikvienam ir jāuzsāk eksperimenti, lai neatpaliktu no konkurentiem.

Šeit jūs nonākat pie secinājuma, ka vispirms ir jāsaprot, kas jums jādara. Pasaule nav ideāla, un prod arī nav ideāls.

Jā, Ŕīs lietas ir savstarpēji saistÄ«tas.

Arī uzņēmumi ne vienmēr saprot, ka viņiem tas ir jāiet.

Ir situācija, kurā izmaiņas vispār nav iespējamas. Å Ä« ir situācija, kad uz komandu ir lielāks spiediens. Komanda jau ir diezgan izdegusi. Viņai nav brÄ«va laika nekādiem eksperimentiem. Viņi strādā pie funkcijām no rÄ«ta lÄ«dz vakaram. Un pārvaldÄ«bai ir arvien mazāk funkciju. NepiecieÅ”ams arvien vairāk. Šādā situācijā nekādas izmaiņas vispār nav iespējamas. Komandai var pateikt tikai to, ka rÄ«t darÄ«sim to paÅ”u, ko vakar, tikai vajag uztaisÄ«t nedaudz vairāk funkciju. Å ajā ziņā pāreja uz jebkuru praksi nav iespējama. Å Ä« ir klasiska situācija, kad nav laika asināt cirvi, koki jācērt, tāpēc cirta ar blāvu cirvi. Å eit nav vienkārÅ”u padomu.

(Dmitrijs) Es nolasÄ«Å”u paskaidrojumu no tērzÄ“Å”anas: ā€œBet mums ir nepiecieÅ”ams daudz testu dažādos lÄ«meņos. Cik daudz laika tiek atvēlēts testiem? Tas ir nedaudz dārgi un aizņem daudz laika. ā€

(Oļegs) Tas ir klasisks nepareizs priekÅ”stats. Pārbaudēm vajadzētu bÅ«t pietiekami daudz, lai jÅ«s bÅ«tu pārliecināti. Nepārtraukta integrācija nav tāda lieta, kur vispirms tiek veikti 100% testu un tikai tad sāc pielietot Å”o praksi. Nepārtraukta integrācija samazina jÅ«su kognitÄ«vo slodzi, jo katra no izmaiņām, ko redzat ar acÄ«m, ir tik acÄ«mredzama, ka pat bez pārbaudēm jÅ«s saprotat, vai tā kaut ko sabojās vai nē. To var ātri pārbaudÄ«t savā galvā, jo izmaiņas ir nelielas. Pat ja jums ir tikai manuāli testētāji, arÄ« viņiem tas ir vieglāk. JÅ«s izskrējāt un teicāt: "Redzi, vai kaut kas ir salÅ«zis?" Viņi pārbaudÄ«ja un teica: "Nē, nekas nav salauzts." Jo testētājs zina, kur meklēt. Jums ir viena apņemÅ”anās, kas saistÄ«ta ar vienu koda daļu. Un to izmanto Ä«paÅ”a uzvedÄ«ba.

Šeit jūs, protams, izpuŔķojat.

(Dmitrijs) Es Ŕeit nepiekrītu. Pastāv prakse - testu vadīta izstrāde, kas jūs no tā pasargās.

(Oļegs) Nu, es vēl neesmu sasniedzis to punktu. Pirmā ilÅ«zija ir tāda, ka jums ir jāraksta 100% testu vai arÄ« jums vispār nav jāveic nepārtraukta integrācija. Tā nav patiesÄ«ba. Tās ir divas paralēlas prakses. Un tie nav tieÅ”i atkarÄ«gi. JÅ«su testa pārklājumam jābÅ«t optimālam. Optimāli - tas nozÄ«mē, ka jÅ«s pats esat pārliecināts, ka meistara kvalitāte, kurā jÅ«su meistars palika pēc apņemÅ”anās, ļauj pārliecinoÅ”i nospiest pogu ā€œIzvietotā€ dzērumā piektdienas vakarā. Kā jÅ«s to panākat? Izmantojot pārskatÄ«Å”anu, pārklājumu, labu uzraudzÄ«bu.

Labu uzraudzÄ«bu nevar atŔķirt no testiem. Ja vienreiz palaižat testus ar preprod, tie vienreiz pārbauda visus jÅ«su lietotāja skriptus, un viss. Un, ja jÅ«s tos palaižat bezgalÄ«gā cilpā, tad Ŕī ir jÅ«su izvietotā uzraudzÄ«bas sistēma, kas bezgalÄ«gi pārbauda visu ā€” vai tā ir avarējusi vai nē. Å ajā gadÄ«jumā vienÄ«gā atŔķirÄ«ba ir, vai tas tiek darÄ«ts vienu vai divas reizes. Ä»oti labs testu komplekts... darbojas bezgalÄ«gi, tā ir uzraudzÄ«ba. Un pareizai uzraudzÄ«bai vajadzētu bÅ«t Ŕādai.

Un tāpēc, kā tieÅ”i tu sasniegsi Å”o stāvokli, kad piektdienas vakarā sataisÄ«sies un dosies mājās, ir cits jautājums. VarbÅ«t jÅ«s vienkārÅ”i esat drosmÄ«gs Å”vacis.

Nedaudz atgriezÄ«simies pie nepārtrauktas integrācijas. Mēs aizbēgām uz nedaudz atŔķirÄ«gu sarežģītu praksi.

Un otra ilÅ«zija ir tāda, ka MVP, viņi saka, ir jādara ātri, tāpēc testi tur nemaz nav vajadzÄ«gi. Noteikti ne tādā veidā. Fakts ir tāds, ka, rakstot lietotāja stāstu MVP, varat to izstrādāt uz bumbas, tas ir, jÅ«s dzirdējāt, ka ir kāds lietotāja stāsts, un nekavējoties skrējāt to kodēt, vai arÄ« varat strādāt, izmantojot TDD. Un saskaņā ar TDD, kā liecina prakse, tas neaizņem vairāk laika, t.i., testi ir blakusparādÄ«ba. TDD prakse nav saistÄ«ta ar testÄ“Å”anu. Neraugoties uz to, ko sauc par testu virzÄ«tu attÄ«stÄ«bu, tas vispār nav par testiem. Tā arÄ« drÄ«zāk ir arhitektoniska pieeja. Å Ä« ir pieeja rakstÄ«t tieÅ”i to, kas ir vajadzÄ«gs, un nerakstÄ«t to, kas nav vajadzÄ«gs. Å Ä« ir prakse koncentrēties uz nākamo jÅ«su domāŔanas atkārtojumu saistÄ«bā ar lietojumprogrammas arhitektÅ«ras izveidi.

Tāpēc atbrÄ«voties no Ŕīm ilÅ«zijām nav tik vienkārÅ”i. MVP un testi nav pretrunā viens otram. Pat, drÄ«zāk, tieÅ”i otrādi, ja jÅ«s veicat MVP, izmantojot TDD praksi, tad jÅ«s to izdarÄ«sit labāk un ātrāk nekā tad, ja darÄ«sit to vispār bez prakses, bet uz bumbas.

Šī ir ļoti nepārprotama un sarežģīta ideja. Kad dzirdi, ka tagad rakstīŔu vairāk kontroldarbus un pie reizes kaut ko izdarīŔu ātrāk, izklausās absolūti neadekvāti.

(Dmitrijs) Daudzi Å”eit, kad viņi sauc par MVP, ir pārāk slinki, lai uzrakstÄ«tu kaut ko normālu. Un tās joprojām ir dažādas lietas. Nav nepiecieÅ”ams pārvērst MVP par sliktu lietu, kas nedarbojas.

Jā, jā, tev taisnība.

Un tad pēkŔņi MVP prod.

Uz visiem laikiem.

Un TDD izklausās ļoti neparasti, kad dzirdat, ka rakstāt testus un, Ŕķiet, darāt vairāk darba. Izklausās ļoti dÄ«vaini, bet patiesÄ«bā Ŕādi sanāk ātrāk un glÄ«tāk. Rakstot testu, tu jau savā galvā daudz domā par to, kāds kods tiks izsaukts un kā, kā arÄ« kādu uzvedÄ«bu no tā sagaidām. JÅ«s vienkārÅ”i nesakiet, ka es uzrakstÄ«ju kādu funkciju, un tā kaut ko dara. Sākumā tu domāji, ka viņai ir tādi un tādi nosacÄ«jumi, viņa tiks aicināta tā un tā. JÅ«s to pārklājat ar testiem, un no tā jÅ«s saprotat, kā saskarnes izskatÄ«sies jÅ«su kodā. Tam ir milzÄ«ga ietekme uz arhitektÅ«ru. JÅ«su kods automātiski kļūst modulārāks, jo vispirms mēģināt saprast, kā jÅ«s to pārbaudÄ«sit, un tikai pēc tam rakstÄ«t.

Ar TDD ar mani notika tas, ka kādā brÄ«dÄ« es nolÄ«gu Ruby mentoru, kad vēl biju Ruby programmētājs. Un viņŔ saka: "DarÄ«sim to saskaņā ar TDD." Es domāju: "SasodÄ«ts, tagad man ir jāuzraksta kaut kas papildus." Un mēs vienojāmies, ka divu nedēļu laikā es uzrakstÄ«Å”u visu darba kodu Python, izmantojot TDD. Pēc divām nedēļām es sapratu, ka nevēlos atgriezties. Pēc divām nedēļām, mēģinot to pielietot visur, jÅ«s saprotat, cik daudz vieglāk jums ir kļuvis pat vienkārÅ”i domāt. Bet tas nav acÄ«mredzami, tāpēc iesaku ikvienam, ja jums ir sajÅ«ta, ka TDD ir grÅ«ts, laikietilpÄ«gs un nevajadzÄ«gs, mēģiniet to pieturēties tikai divas nedēļas. Man pietika ar diviem.

(Dmitrijs) Mēs varam paplaÅ”ināt Å”o ideju no infrastruktÅ«ras darbÄ«bas viedokļa. Pirms sākam kaut ko jaunu, mēs veicam pārraudzÄ«bu un pēc tam palaižam. Å ajā gadÄ«jumā uzraudzÄ«ba mums kļūst par parastu pārbaudi. Un ar monitoringu notiek attÄ«stÄ«ba. Bet gandrÄ«z visi saka, ka tas ir garÅ”, es esmu slinks, es izveidoju pagaidu melnrakstu. Ja esam veikuÅ”i normālu uzraudzÄ«bu, mēs saprotam CI sistēmas stāvokli. Un CI sistēmai ir daudz uzraudzÄ«bas. Mēs saprotam sistēmas stāvokli, saprotam, kas tajā atrodas. Un izstrādes laikā mēs tikai veidojam sistēmu, lai tā sasniegtu vēlamo stāvokli.

Šīs metodes ir zināmas jau ilgu laiku. Mēs to apspriedām apmēram pirms 4 gadiem. Bet 4 gadu laikā praktiski nekas nav mainījies.

Bet Ŕajā sakarā es ierosinu beigt oficiālo diskusiju.

Video (ievietots kā multivides elements, bet kaut kādu iemeslu dēļ nedarbojas):

https://youtu.be/zZ3qXVN3Oic

Avots: www.habr.com

Pievieno komentāru