Keling, nima uchun CI vositalari va CI butunlay boshqacha narsalar ekanligini muhokama qilaylik.
CI qanday og'riqni hal qilishga mo'ljallangan, bu g'oya qaerdan paydo bo'ldi, u ishlayotganligi haqidagi so'nggi tasdiqlar qanday, sizda Jenkinsni o'rnatmagan, amaliyotingiz borligini qanday tushunish mumkin.
Uzluksiz integratsiya haqida hisobot tayyorlash g'oyasi bir yil oldin, men intervyu olish va ish qidirayotganimda paydo bo'lgan. Men 10-15 ta kompaniya bilan suhbatlashdim, ulardan faqat bittasi CI nima ekanligini aniq javob bera oldi va ularda bu yo'qligini qanday tushunishganini tushuntira oldi. Qolganlari Jenkins haqida tushunarsiz bema'ni gaplarni gapirishdi :) Xo'sh, bizda Jenkins bor, u quradi, CI! Hisobot davomida men uzluksiz integratsiya nima ekanligini va nima uchun Jenkins va shunga o'xshash vositalarning bu bilan juda zaif aloqasi borligini tushuntirishga harakat qilaman.
Xo'sh, CI so'zini eshitganingizda odatda nima xayolingizga keladi? Ko'pchilik Jenkins, Gitlab CI, Travis va boshqalar haqida o'ylaydi.
Agar biz uni Google orqali qidirsak ham, u bizga ushbu vositalarni beradi.
Agar siz so'rashni yaxshi bilsangiz, asboblar ro'yxatini kiritganingizdan so'ng, ular sizga CI bu siz topshiriq uchun Pull Request-da testlarni qurish va ishga tushirish ekanligini aytadilar.
Uzluksiz integratsiya - bu asboblar haqida emas, filialdagi testlar bilan yig'ilishlar haqida emas! Uzluksiz integratsiya - bu yangi kodni tez-tez integratsiyalash amaliyotidir va uni ishlatish uchun Jenkins, GitLab va boshqalarni to'sib qo'yish shart emas.
To'liq huquqli CI qanday ko'rinishini aniqlashdan oldin, keling, avval uni o'ylab topgan odamlar kontekstiga sho'ng'ib olaylik va ular hal qilmoqchi bo'lgan og'riqni his qilaylik.
Va ular bir jamoa bo'lib ishlashning azobini hal qilishdi!
Keling, ishlab chiquvchilar jamoalarda rivojlanishda duch keladigan qiyinchiliklarga misollarni ko'rib chiqaylik. Bu erda bizda loyiha, git-dagi asosiy filial va ikkita dasturchi bor.
Va ular hamma uzoq vaqtdan beri o'rganib qolganidek ishga kirishdi. Biz narsalarning katta sxemasida vazifa oldik, xususiyat bo'limi yaratdik va kodni yozdik.
Biri funksiyani tezroq tugatdi va uni masterga birlashtirdi.
Ikkinchisiga ko'proq vaqt kerak edi, u keyinroq birlashdi va nizo bilan yakunlandi. Endi, ishlab chiquvchi biznesga kerak bo'lgan xususiyatlarni yozish o'rniga, o'z vaqtini va kuchini nizolarni hal qilish uchun sarflaydi.
Sizning xususiyatingizni umumiy usta bilan birlashtirish qanchalik qiyin bo'lsa, biz unga ko'proq vaqt sarflaymiz. Va men buni juda oddiy misol bilan ko'rsatdim. Bu bor-yoʻgʻi 2 ta dasturchi boʻlgan misol. Tasavvur qiling-a, kompaniyadagi 10 yoki 15 yoki 100 kishi bitta omborga yozishadi. Siz bu mojarolarning barchasini hal qilish uchun aqldan ozasiz.
Biroz boshqacha holat bor. Bizda usta va ba'zi ishlab chiquvchilar nimadir qilishadi.
Ular novdani yaratdilar.
Biri vafot etdi, hamma narsa yaxshi edi, u topshiriqni topshirdi.
Ikkinchi ishlab chiquvchi esa o'z vazifasini topshirdi. Aytaylik, u uni tekshirish uchun yubordi. Ko'pgina kompaniyalar ko'rib chiqish deb ataladigan amaliyotga ega. Bir tomondan, bu amaliyot yaxshi va foydali bo'lsa, boshqa tomondan, bizni ko'p jihatdan sekinlashtiradi. Biz bunga kirmaymiz, lekin bu erda yomon sharh hikoyasi nimaga olib kelishi mumkinligi haqida ajoyib misol. Siz ko‘rib chiqish uchun tortib olish so‘rovini yubordingiz. Ishlab chiquvchi uchun boshqa hech narsa yo'q. U nima qilishni boshlaydi? U boshqa vazifalarni bajarishni boshlaydi.
Bu vaqt ichida ikkinchi ishlab chiquvchi yana bir narsa qildi.
Birinchisi uchinchi vazifani bajardi.
Va bir muncha vaqt o'tgach, uning sharhi sinovdan o'tkazildi va u murosaga kelishga harakat qilmoqda. Xo'sh, nima bo'lyapti? Bu juda ko'p sonli nizolarni ushlaydi. Nega? Chunki uning tortishish so'rovi ko'rib chiqilayotganda, kodda ko'p narsa o'zgargan edi.
Qarama-qarshilikli hikoyadan tashqari, aloqalar bilan bog'liq hikoya ham mavjud. Sizning ipingiz ko'rib chiqilayotganda, u nimanidir kutayotganda, siz uzoq vaqt davomida biror xususiyat ustida ishlayotganingizda, xizmatingiz kod bazasida yana nima o'zgarib borayotganini kuzatishni to'xtatasiz. Ehtimol, siz hozir hal qilmoqchi bo'lgan narsa kechagina hal qilingan va siz qandaydir usulni qo'llashingiz va uni qayta ishlatishingiz mumkin. Lekin siz buni ko'rmaysiz, chunki siz doimo eskirgan filial bilan ishlaysiz. Va bu eskirgan filial har doim birlashma mojarosini hal qilishingizga olib keladi.
Ma'lum bo'lishicha, agar biz bir jamoa bo'lib ishlasak, ya'ni omborda bir odam emas, balki 5-10 kishi aylanib yursa, biz kodimizni ustaga qancha vaqt qo'shmasak, shunchalik ko'p azob chekamiz, chunki oxir-oqibat bizga kerak bo'ladi. biror narsa keyin uni birlashtiring. Va bizda qanchalik ko'p mojarolar bo'lsa va biz qanchalik eski versiya bilan ishlasak, bizda shunchalik ko'p muammolar mavjud.
Birgalikda nimadir qilish og'riqli! Biz har doim bir-birimizga to'sqinlik qilamiz.
Bu muammo 20 yildan ko'proq vaqt oldin sezilgan. Ekstremal dasturlashda uzluksiz integratsiya amaliyoti haqida birinchi eslatmani topdim.
Ekstremal dasturlash birinchi tezkor ramka hisoblanadi. Sahifa 96 yilda paydo bo'lgan. Va g'oya dasturlash amaliyoti, rejalashtirish va boshqa narsalardan foydalanish edi, shunda ishlab chiqish imkon qadar moslashuvchan bo'ladi, shunda biz mijozlarimizning har qanday o'zgarishlari yoki talablariga tezda javob bera olamiz. Va ular 24 yil oldin, agar siz biron bir narsani juda uzoq vaqt va chetda qilsangiz, siz bunga ko'proq vaqt sarflaysiz, chunki sizda nizolar borligi bilan duch kelishdi.
Endi biz "Uzluksiz integratsiya" iborasini alohida tahlil qilamiz. Agar biz uni to'g'ridan-to'g'ri tarjima qilsak, biz doimiy integratsiyaga erishamiz. Ammo uning qanchalik uzluksiz ekanligi unchalik aniq emas, u juda uzluksiz. Ammo uning qanchalik integratsiyalashuvi ham unchalik aniq emas.
Va shuning uchun men hozir sizga Ekstremal dasturlashdan iqtiboslar beraman. Va ikkala so'zni alohida tahlil qilamiz.
Integratsiya - Yuqorida aytib o'tganimdek, biz har bir muhandis kodning eng so'nggi versiyasi bilan ishlashini ta'minlashga intilamiz, shunda u o'z kodini imkon qadar tez-tez umumiy filialga qo'shishga intiladi, bu kichik filiallardir. Chunki agar ular katta bo'lsa, biz bir hafta davomida birlashma mojarolariga osongina yopishib olamiz. Bu, ayniqsa, bizda palapartishlik kabi uzoq rivojlanish tsikliga ega bo'lsak, to'g'ri bo'ladi, bu erda ishlab chiquvchi bir oy davomida ba'zi ulkan xususiyatlarni kesish uchun ketgan. Va u juda uzoq vaqt integratsiya bosqichida qolib ketadi.
Integratsiya - bu bizning filialimizni olib, uni usta bilan birlashtirganimizda, biz uni birlashtiramiz. Biz transbase ishlab chiquvchisi bo'lganimizda, biz hech qanday qo'shimcha filiallarsiz darhol masterga yozishni ta'minlashga intilamiz.
Umuman olganda, integratsiya kodingizni olib, uni masterga sudrab olishni anglatadi.
Bu yerda “uzluksiz” so‘zi nimani anglatadi, davomiylik nima deyiladi? Amaliyot shuni ko'rsatadiki, ishlab chiquvchi o'z kodini iloji boricha tezroq birlashtirishga intiladi. Bu har qanday vazifani bajarishda uning maqsadi - o'z kodini masterga imkon qadar tezroq kiritish. Ideal dunyoda ishlab chiquvchilar buni bir necha soatda amalga oshiradilar. Ya'ni, siz kichik muammoni olib, uni masterga birlashtirasiz. Hammasi ajoyib. Bu siz harakat qilayotgan narsadir. Va bu doimiy ravishda amalga oshirilishi kerak. Biror narsa qilishingiz bilan darhol uni ustaga qo'yasiz.
Va biror narsani yaratgan ishlab chiquvchi uni ishlashi va hech narsani buzmasligi uchun qilgan ishlari uchun javobgardir. Bu erda odatda sinov hikoyasi chiqadi. Uning ishlashiga ishonch hosil qilish uchun biz majburiyatimiz, birlashmamiz bo'yicha ba'zi sinovlarni o'tkazmoqchimiz. Va bu erda Jenkins sizga yordam berishi mumkin.
Ammo hikoyalar bilan: o'zgarishlarni kichik qilaylik, vazifalar kichik bo'lsin, muammo yarataylik va darhol uni qandaydir tarzda usta ichiga kiritishga harakat qilaylik - bu erda hech qanday Jenkins yordam bermaydi. Chunki Jenkins sizga faqat testlarni o'tkazishda yordam beradi.
Siz ularsiz qila olasiz. Bu sizga umuman zarar keltirmaydi. Chunki amaliyotning maqsadi kelajakda har qanday nizolarga katta vaqtni sarflamaslik uchun imkon qadar tez-tez o'lchashdir.
Tasavvur qilaylik, negadir biz 2020 yilda internetsiz qoldik. Va biz mahalliy darajada ishlaymiz. Bizda Jenkins yo'q. Bu odatiy. Siz hali ham davom etib, mahalliy filialni yaratishingiz mumkin. Siz unga qandaydir kod yozdingiz. Biz vazifani 3-4 soat ichida bajardik. Biz masterga o'tdik, git pull qildik va u erda filialimizni birlashtirdik. Tayyor. Agar buni tez-tez qilsangiz, tabriklaymiz, sizda doimiy integratsiya mavjud!
Zamonaviy dunyoda energiya sarflashga arziydigan qanday dalillar mavjud? Chunki bu umuman qiyin. Agar siz shunday ishlashga harakat qilsangiz, endi ba'zi rejalashtirish ta'sir qilishini tushunasiz, vazifalarni parchalash uchun ko'proq vaqt ajratishingiz kerak bo'ladi. Chunki agar siz odamni... qilsangiz, unda siz tezda kelisha olmaysiz va shunga mos ravishda muammoga duch kelasiz. Siz endi amaliyotga ega bo'lmaysiz.
Va bu qimmat bo'ladi. Ertadan boshlab uzluksiz integratsiyadan foydalangan holda darhol ishlash mumkin bo'lmaydi. Hammangizga ko'nikish uchun juda ko'p vaqt kerak bo'ladi, topshiriqlarni qismlarga ajratishga ko'nikish uchun juda ko'p vaqt kerak bo'ladi, agar sizda bo'lsa, ko'rib chiqish amaliyotini qayta bajarishga ko'nikish uchun juda uzoq vaqt kerak bo'ladi. . Chunki bizning maqsadimiz bugun uning erishi. Va agar siz uch kun ichida ko'rib chiqsangiz, unda muammolaringiz bor va Uzluksiz integratsiya siz uchun ishlamayapti.
Ammo hozir bizda ushbu amaliyotga sarmoya kiritish mantiqiy ekanligini ko'rsatadigan tegishli dalillar bormi?
Xayolimga kelgan birinchi narsa bu DevOps holati edi. Bu yigitlar 7 yildan beri olib borgan tadqiqot. Endi ular buni mustaqil tashkilot sifatida qilishadi, lekin Google ostida.
Va ularning 2018 yildagi tadqiqoti tez integratsiyalashgan, tez-tez integratsiyalashgan va IT samaradorligi ko'rsatkichlariga ega bo'lgan qisqa muddatli filiallardan foydalanishga harakat qiladigan kompaniyalar o'rtasidagi bog'liqlikni ko'rsatdi.
Bu ko'rsatkichlar nima? Bular o'zlarining so'rovnomalarida barcha kompaniyalardan oladigan 4 ta ko'rsatkich: joylashtirish chastotasi, o'zgartirishlar uchun etkazib berish vaqti, xizmatni tiklash vaqti, o'zgarishlarning muvaffaqiyatsizlik darajasi.
Va, birinchidan, bu bog'liqlik bor, biz tez-tez o'lchaydigan kompaniyalar ancha yaxshi ko'rsatkichlarga ega ekanligini bilamiz. Va ularda kompaniyalarning bir nechta toifalarga bo'linishi mavjud: bular asta-sekin, o'rta darajadagi, yuqori ko'rsatkichli va elita ishlab chiqaradigan sekin kompaniyalar. Elita - Netflix, Amazon, ular juda tez, hamma narsani tez, chiroyli va samarali bajaradilar.
Bir oy oldin sodir bo'lgan ikkinchi voqea. Technology Radar-da Gitflow haqida ajoyib maqola bor. Gitflow shoxlari uzoq umr ko'rishi bilan boshqalardan farq qiladi. Uzoq vaqt davomida yashaydigan reliz filiallari va uzoq vaqt yashaydigan novdalar mavjud. Texnologiya Radaridagi ushbu amaliyot HOLD rejimiga o'tkazildi. Nega? Chunki odamlar integratsiya azobiga duch kelishadi.
Agar sizning filialingiz juda uzoq vaqt yashasa, u tiqilib qoladi, chiriydi va biz unga qandaydir o'zgartirish kiritishga ko'proq vaqt sarflashni boshlaymiz.
Va yaqinda Gitflow muallifi, agar sizning maqsadingiz Uzluksiz integratsiya bo'lsa, agar sizning maqsadingiz iloji boricha tez-tez aylanishni xohlasangiz, Gitflow yomon fikr ekanligini aytdi. U maqolaga alohida qo'shimcha qildiki, agar sizda bunga intilish mumkin bo'lgan backend bo'lsa, unda Gitflow siz uchun ortiqcha, chunki Gitflow sizni sekinlashtiradi, Gitflow siz uchun integratsiya bilan bog'liq muammolarni keltirib chiqaradi.
Bu Gitflow yomon va uni ishlatmaslik kerak degani emas. Bu boshqa holatlar uchun. Misol uchun, xizmat yoki dasturning bir nechta versiyalarini qo'llab-quvvatlash kerak bo'lganda, ya'ni uzoq vaqt davomida qo'llab-quvvatlash kerak bo'lgan joyda.
Ammo bunday xizmatlarni qo'llab-quvvatlaydigan odamlar bilan gaplashsangiz, ushbu versiya 3.2 bo'lganligi haqida juda ko'p og'riqlarni eshitasiz, bu 4 oy oldin edi, lekin bu tuzatish unga kiritilmagan va hozir uni amalga oshirish uchun, bir qator o'zgarishlar qilishingiz kerak. Va endi ular yana tiqilib qolishdi va endi ular bir hafta davomida yangi xususiyatni amalga oshirishga harakat qilishdi.
Suhbatda Aleksandr Kovalyov to'g'ri ta'kidlaganidek, korrelyatsiya sabab bo'lish bilan bir xil emas. Bu shunday. Ya'ni, agar sizda doimiy integratsiya mavjud bo'lsa, unda barcha ko'rsatkichlar ajoyib bo'ladi, degan to'g'ridan-to'g'ri aloqa yo'q. Ammo ijobiy bog'liqlik mavjud, agar biri bitta bo'lsa, ikkinchisi ham bo'lishi mumkin. Fakt emas, lekin katta ehtimol. Bu shunchaki korrelyatsiya.
Aftidan, biz allaqachon biror narsa qilyapmiz, biz allaqachon birlashayotganga o'xshaymiz, lekin bizda hali ham doimiy integratsiya mavjudligini, biz tez-tez birlashayotganimizni qanday tushunish mumkin?
Jez Humble qo'llanma, Accelerate, Continuous Delivery veb-sayti va Continuous Delivery kitobining muallifi. U ushbu testni taklif qiladi:
- Muhandisning kodi har kuni ustaga etib boradi.
- Har bir majburiyat uchun siz birlik testlarini o'tkazasiz.
- Ustadagi qurilish tushib ketdi, u taxminan 10 daqiqada tuzatildi.
U etarli darajada amaliyotga ega ekanligingizga ishonch hosil qilish uchun bu kabi testdan foydalanishni taklif qiladi.
Men ikkinchisini biroz munozarali deb bilaman. Ya'ni, agar siz uni 10 daqiqada tuzatsangiz, u holda sizda Uzluksiz integratsiya mavjud, menimcha, bu biroz g'alati tuyuladi, lekin bu mantiqiy. Nega? Chunki siz tez-tez muzlab qolsangiz, bu sizning o'zgarishlaringiz kichik ekanligini anglatadi. Kichkina o'zgarish sizning asosiy tuzilmangiz buzilganligini bildirsa, unda siz tezda misol topishingiz mumkin, chunki o'zgarish kichik. Bu erda sizda kichik birlashma bor edi, undagi 20-30 qator o'zgardi. Va shunga ko'ra, sabab nima ekanligini tezda tushunishingiz mumkin, chunki o'zgarishlar kichik, sizda muammoni qidirish uchun juda kichik maydon mavjud.
Chiqarilgandan keyin mahsulotimiz parchalanib ketgan bo'lsa ham, agar bizda doimiy integratsiya amaliyotiga ega bo'lsak, harakat qilish biz uchun ancha oson bo'ladi, chunki o'zgarishlar juda kichik. Ha, bu rejalashtirishga ta'sir qiladi. Bu zarar keltiradi. Va, ehtimol, bu amaliyotda eng qiyin narsa - bu vazifalarni taqsimlashga odatlanish, ya'ni buni qanday qilish kerak, shunda siz biror narsani olib, bir necha soat ichida bajara olasiz va shu bilan birga ko'rib chiqishdan o'tasiz. sizda bor. Ko'rib chiqish alohida og'riqdir.
Birlik testlari integratsiya muvaffaqiyatli bo'lganligini va hech narsa buzilmaganligini tushunishga yordam beradigan yordamchidir. Menimcha, bu ham mutlaqo majburiy emas, chunki bu amaliyot nuqtasi emas.
Bu uzluksiz integratsiyaga qisqacha kirish. Bu amaliyotda hamma narsa bor. Men savollarga tayyorman.
Men yana qisqacha xulosa qilaman:
- Uzluksiz integratsiya Jenkins emas, bu Gitlab emas.
- Bu vosita emas, biz kodimizni iloji boricha tez-tez masterga birlashtiramiz.
- Biz buni kelajakda birlashishlar bilan yuzaga keladigan katta og'riqni oldini olish uchun qilamiz, ya'ni kelajakda ko'proq boshdan kechirmaslik uchun hozir biroz og'riqni boshdan kechiramiz. Hamma gap shunda.
- Yon tomonda kod orqali aloqa mavjud, lekin men buni kamdan-kam ko'raman, lekin bu ham u uchun mo'ljallangan.
Sizning savollaringiz
Buzilmagan vazifalar bilan nima qilish kerak?
Parchalanish. Muammo nimada? Bir misol keltira olasizmi, vazifa bor va u parchalanmagan?
"To'liq" so'zidan ajratib bo'lmaydigan vazifalar mavjud, masalan, juda chuqur tajriba talab qiladigan va qandaydir hazm bo'ladigan natijaga erishish uchun bir oy davomida hal qilinishi mumkin bo'lgan vazifalar.
Agar sizni to'g'ri tushunsam, unda qandaydir katta va murakkab vazifa bor, uning natijasi faqat bir oy ichida ko'rinadi?
Ha hammasi to'g'ri. Ha, natijani bir oydan oldin baholash mumkin bo'ladi.
Yaxshi. Umuman olganda, bu muammo emas. Nega? Chunki bu o‘rinda novdalar haqida gap ketganda, o‘ziga xos xususiyatga ega bo‘lgan novdalar haqida gap ketmaydi. Xususiyatlari katta va murakkab bo'lishi mumkin. Ular ko'p sonli komponentlarga ta'sir qilishi mumkin. Va, ehtimol, biz ularni bitta filialda to'liq bajara olmaymiz. Bu odatiy. Biz faqat bu hikoyani buzishimiz kerak. Agar xususiyat to'liq tayyor bo'lmasa, bu uning kodining ba'zi qismlarini birlashtirib bo'lmaydi degani emas. Siz, aytaylik, migratsiyani qo'shdingiz va bu xususiyat ichida ba'zi bosqichlar mavjud. Aytaylik, sizda bosqich bor - migratsiya qiling, yangi usul qo'shing. Va siz allaqachon bu narsalarni har kuni o'lchashingiz mumkin.
Yaxshi. Unda nima gap?
Har kuni mayda narsalarni o'ldirishdan nima foyda?
Ha.
Agar ular biror narsani sindirishsa, uni darhol ko'rasiz. Sizda biror narsani sindirgan kichik bo'lak bor, uni tuzatish siz uchun osonroq. Gap shundaki, hozir kichik bo'lakni birlashtirish bir necha hafta ichida katta narsani birlashtirishdan ko'ra osonroqdir. Uchinchi nuqta shundaki, boshqa muhandislar kodning joriy versiyasi bilan ishlaydi. Ular bu erda ba'zi migratsiyalar qo'shilganligini va keyin ular ham foydalanishni xohlashlari mumkin bo'lgan usul paydo bo'lganini ko'radilar. Sizning kodingizda nima sodir bo'layotganini hamma ko'radi. Amaliyot shu uch narsa uchun amalga oshiriladi.
Rahmat, masala yopildi!
(Oleg Soroka) Qo'shishim mumkinmi? Siz hamma narsani to'g'ri aytdingiz, men faqat bitta iborani qo'shmoqchiman.
Zimmasiga olmoqda
Uzluksiz integratsiya bilan kod xususiyat to'liq tayyor bo'lganda emas, balki tuzilish uzilishni to'xtatganda umumiy filialga birlashtiriladi. Va siz kuniga bir necha marta xohlaganingizcha o'zlashtirishga ishonch hosil qilishingiz mumkin. Ikkinchi jihat shundaki, agar siz biron sababga ko'ra oylik topshiriqni kamida uch kun davomida vazifalarga ajrata olmasangiz, men taxminan uch soat jim turaman, demak sizda juda katta muammo bor. Va sizda Uzluksiz integratsiya yo'qligi bu muammolarning eng kichikidir. Bu sizning arxitektura va nol muhandislik amaliyotlari bilan bog'liq muammolaringiz borligini anglatadi. Chunki bu tadqiqot bo'lsa ham, har qanday holatda ham u gipoteza yoki tsikl shaklida shakllantirilishi kerak.
Muvaffaqiyatli kompaniyalarni ortda qolgan kompaniyalardan ajratib turadigan 4 ta ko'rsatkich haqida gaplashdik. Ushbu 4 ko'rsatkichni ko'rish uchun biz hali ham yashashimiz kerak. Agar sizning o'rtacha vazifangizni bajarish uchun bir oy kerak bo'lsa, men birinchi navbatda ushbu ko'rsatkichga e'tibor qarataman. Avval uni 3 kunga tushirardim. Va shundan keyin men Continous haqida o'ylay boshladim.
Men sizni to'g'ri tushundimmi, agar biron bir vazifani bajarish uchun bir oy kerak bo'lsa, umuman muhandislik amaliyotiga sarmoya kiritishning ma'nosi yo'q deb o'ylaysizmi?
Sizda doimiy integratsiya mavjud. Va shunday mavzu borki, 10 daqiqada siz tuzatishni tuzatishingiz yoki uni orqaga qaytarishingiz mumkin. Tasavvur qiling-a, siz uni aylantirdingiz. Bundan tashqari, sizda uzluksiz tarqatish ham bor, siz uni ishlab chiqarish uchun chiqardingiz va shundan keyingina nimadir noto'g'ri ketganini payqadingiz. Va siz uni orqaga qaytarishingiz kerak, lekin siz allaqachon ma'lumotlar bazasini ko'chirgansiz. Sizda keyingi versiyaning ma'lumotlar bazasi sxemasi allaqachon mavjud, bundan tashqari sizda qandaydir zaxira nusxasi ham bor edi va ma'lumotlar ham u erda yozilgan.
Va qanday alternativangiz bor? Agar siz kodni orqaga qaytarsangiz, u endi ushbu yangilangan ma'lumotlar bazasi bilan ishlay olmaydi.
Baza faqat oldinga siljiydi, ha.
Kam muhandislik amaliyotiga ega bo'lgan odamlar, ehtimol, ... haqida qalin kitobni o'qimagan. Zaxira bilan nima qilish kerak? Agar siz zaxiradan tiklasangiz, bu o'sha paytda to'plangan ma'lumotlarni yo'qotishingizni anglatadi. Misol uchun, biz uch soat davomida ma'lumotlar bazasining yangi versiyasi bilan ishladik, u erda ro'yxatdan o'tgan foydalanuvchilar. Siz eski zaxira nusxasini rad qilasiz, chunki sxema yangi versiya bilan ishlamaydi, shuning uchun siz ushbu foydalanuvchilarni yo'qotdingiz. Va ular norozi, ular qasam ichishadi.
Uzluksiz integratsiya va uzluksiz yetkazib berishni qo'llab-quvvatlaydigan to'liq amaliyotlarni o'zlashtirish uchun faqat yozishni o'rganish kifoya emas.... Birinchidan, ular juda ko'p bo'lishi mumkin, bu amaliy bo'lmaydi. Bundan tashqari, Scientific kabi bir qancha boshqa amaliyotlar mavjud. Bunday amaliyot bor, GitHub uni bir vaqtning o'zida ommalashgan. Bu sizda bir vaqtning o'zida eski va yangi kod mavjud bo'lganda. Bu siz tugallanmagan xususiyatni yaratganingizda, lekin u ba'zi qiymatlarni qaytarishi mumkin: funksiya sifatida yoki Rest API sifatida. Siz yangi kodni ham, eski kodni ham bajarasiz va ular orasidagi farqni solishtirasiz. Va agar farq bo'lsa, siz ushbu hodisani qayd etasiz. Shunday qilib, sizda ma'lum vaqt davomida ikkalasi o'rtasida tafovut bo'lmagan bo'lsa, sizda eskisining ustiga chiqishga tayyor yangi xususiyat borligini bilasiz.
Bunday amaliyotlar yuzlab mavjud. Transbase ishlab chiqishdan boshlashni taklif qilaman. U uzluksiz integratsiyada 100% emas, lekin amaliyotlar bir xil, biri ikkinchisisiz yaxshi yashay olmaydi.
Amaliyotlarni ko'rishingiz mumkin bo'lgan transbase rivojlanishini misol sifatida keltirdingizmi yoki odamlarga transbase developmentdan foydalanishni taklif qilasizmi?
Qarang, chunki ular undan foydalana olmaydi. Ulardan foydalanish uchun siz ko'p o'qishingiz kerak. Biror kishi: "Bir oy davom etadigan xususiyat bilan nima qilish kerak", deb so'raganda, u transbase rivojlanishi haqida o'qimaganligini anglatadi. Men buni hozircha tavsiya qilmayman. Men faqat katta vazifalarni kichikroqlarga qanday qilib to'g'ri me'moriy ravishda ajratish mavzusiga e'tibor qaratishni maslahat beraman. Bu parchalanishning mohiyati.
Parchalanish arxitektorning vositalaridan biridir. Biz avval tahlil qilamiz, keyin parchalaymiz, keyin sintez qilamiz, keyin integratsiya qilamiz. Va biz uchun hamma narsa shunday ishlaydi. Va biz hali ham parchalanish orqali Uzluksiz integratsiyaga o'tishimiz kerak. Birinchi bosqichda savollar tug'iladi va biz allaqachon to'rtinchi bosqich haqida gapiramiz, ya'ni integratsiyani qanchalik tez-tez amalga oshirsak, shuncha yaxshi bo'ladi. Buni qilish uchun hali erta, birinchi navbatda monolitingizni kesib tashlasangiz yaxshi bo'lardi.
Ba'zi diagrammada bir nechta o'qlar va kvadratlarni chizishingiz kerak. Endi men yangi ilovaning arxitektura diagrammasini ko'rsataman va bitta kvadratni ko'rsataman, deb ayta olmaysiz, uning ichida ilova uchun yashil tugma mavjud. Har holda, ko'proq kvadratchalar va o'qlar bo'ladi. Men ko'rgan har bir diagrammada bir nechtasi bor edi. Va parchalanish, hatto grafik tasvir darajasida ham allaqachon sodir bo'lmoqda. Shuning uchun kvadratchalar mustaqil bo'lishi mumkin. Agar yo'q bo'lsa, unda me'morga katta savollarim bor.
Suhbatda savol bor: "Agar ko'rib chiqish majburiy bo'lsa va uzoq vaqt talab qilsa, ehtimol bir kun yoki undan ko'proq vaqt kerakmi?"
Amaliyotda muammolaringiz bor. Ko'rib chiqish bir kun yoki undan ko'proq davom etmasligi kerak. Bu avvalgi savol bilan bir xil, faqat biroz yumshoqroq. Agar ko'rib chiqish bir kun davom etsa, bu ko'rib chiqish juda katta o'zgarishlarga olib keladi. Bu uni kichikroq qilish kerakligini anglatadi. Oleg tavsiya qilgan transbase rivojlanishida uzluksiz ko'rib chiqish deb nomlangan hikoya mavjud. Uning g'oyasi shundan iboratki, biz ataylab bunday kichik tortishish so'rovini qilamiz, chunki biz doimo va bir vaqtning o'zida birlashishga intilamiz. Shunday qilib, tortish so'rovi bitta abstraktsiyani yoki 10 qatorni o'zgartiradi. Ushbu sharh tufayli bizga bir necha daqiqa vaqt ketadi.
Agar ko'rib chiqish bir kun yoki undan ko'proq vaqt talab qilsa, biror narsa noto'g'ri. Birinchidan, siz arxitektura bilan bog'liq muammolarga duch kelishingiz mumkin. Yoki bu katta kod qismi, masalan, 1 qator. Yoki sizning arxitekturangiz shunchalik murakkabki, odam buni tushunolmaydi. Bu biroz yonma-yon muammo, lekin uni ham hal qilish kerak bo'ladi. Ehtimol, ko'rib chiqish umuman kerak emas. Bu haqda ham o'ylashimiz kerak. Ko'rib chiqish sizni sekinlashtiradigan narsadir. Umuman olganda, uning afzalliklari bor, lekin nima uchun buni qilayotganingizni tushunishingiz kerak. Bu sizga ma'lumotni tezda etkazishning bir usulimi, bu sizning ichki standartlarni belgilashingiz uchunmi yoki nima? Nega bu sizga kerak? Chunki ko'rib chiqish juda tez amalga oshirilishi yoki butunlay bekor qilinishi kerak. Bu transbase deploymentga o'xshaydi - hikoya juda chiroyli, lekin faqat etuk yigitlar uchun.
4 ta ko'rsatkichga kelsak, bu nimaga olib kelishini tushunish uchun ularni olib tashlashni maslahat beraman. Raqamlarga qarang, rasmga qarang, hamma narsa qanchalik yomon.
(Dmitriy) Men siz bilan bu haqda munozaraga kirishishga tayyorman. Raqamlar va ko'rsatkichlar hammasi ajoyib, amaliyotlar ajoyib. Lekin siz biznesga kerak yoki yo'qligini tushunishingiz kerak. Bunday o'zgarishlar tezligiga muhtoj bo'lmagan korxonalar mavjud. Men har 15 daqiqada o'zgartirish kiritib bo'lmaydigan kompaniyalarni bilaman. Va ular juda yomon bo'lgani uchun emas. Bu shunday hayot aylanishi. Va shoxlarni o'zgartirish xususiyatiga ega qilish uchun sizga chuqur bilim kerak.
Bu qiyin. Agar siz o'zgartirish funksiyasi haqidagi hikoyani batafsil o'qishni istasangiz, men buni juda tavsiya qilaman . Va Martin Faulerning o'tish funksiyalari haqida ajoyib maqolasi bor: qanday turlar bor, hayot davrlari va boshqalar. O'zgartirish funksiyasi murakkab.
Va siz hali ham savolga javob bermadingiz: "Jenkins kerakmi yoki yo'qmi?"
Jenkins har qanday holatda ham kerak emas. Jiddiy ravishda, asboblar: Jenkins, Gitlab sizga qulaylik keltiradi. Siz yig'ish yig'ilgan yoki yig'ilmaganligini ko'rasiz. Ular sizga yordam berishlari mumkin, lekin ular sizga amaliyot bermaydilar. Ular sizga faqat doira berishlari mumkin - OK, OK emas. Va keyin, agar siz ham testlarni yozsangiz, chunki testlar bo'lmasa, bu deyarli ma'nosiz. Shuning uchun, bu qulayroq bo'lgani uchun kerak, lekin umuman olganda, siz usiz yashashingiz mumkin, siz ko'p narsani yo'qotmaysiz.
Ya'ni, agar sizda amaliyotlar mavjud bo'lsa, bu sizga kerak emasligini anglatadimi?
Hammasi to'g'ri. Men Jez Humble testini tavsiya qilaman. U erda men oxirgi nuqtaga nisbatan noaniq munosabatdaman. Ammo, umuman olganda, agar sizda uchta narsa bo'lsa, siz doimiy ravishda birlashasiz, masterda topshiriqlar bo'yicha testlarni o'tkazasiz, masterdagi qurilishni tezda tuzatasiz, keyin sizga boshqa hech narsa kerak emas.
Ishtirokchilarning savollarini kutayotganimizda, menda bir savol bor. Biz faqat mahsulot kodi haqida gapirgan edik. Uni infratuzilma kodi uchun ishlatganmisiz? Bu bir xil kodmi, bir xil printsiplar va bir xil hayot aylanishiga egami yoki turli xil hayot tsikllari va tamoyillari bormi? Odatda, hamma uzluksiz integratsiya va rivojlanish haqida gapirganda, hamma ham infratuzilma kodi borligini unutadi. Va so'nggi paytlarda u tobora ko'payib bormoqda. Va bu qoidalarning barchasini u erga olib kelish kerakmi?
Hatto shunday bo'lishi kerak emas, bu juda yaxshi bo'lardi, chunki u xuddi shu tarzda hayotni osonlashtiradi. Bash skriptlari bilan emas, balki kod bilan ishlashimiz bilanoq, bizda oddiy kod mavjud.
To'xtating, to'xtating, bash skripti ham koddir. Mening eski sevgimga tegmang.
Mayli, men sizning xotiralaringizni oyoq osti qilmayman. Menda bashni yoqtirmaslik bor. Har doim xunuk va qo'rqinchli buziladi. Va u ko'pincha oldindan aytib bo'lmaydigan tarzda buziladi, shuning uchun men buni yoqtirmayman. Lekin mayli, sizda bash kodi bor deylik. Ehtimol, men haqiqatan ham tushunmayapman va u erda oddiy sinov tizimlari mavjud. Men shunchaki bilmayman. Va biz bir xil imtiyozlarga ega bo'lamiz.
Infratuzilma bilan kod sifatida ishlaganimizdan so'ng, biz ishlab chiquvchilar bilan bir xil muammolarga duch kelamiz. Bir necha oy oldin, men bir hamkasbim menga bash-da 1 satr uchun tortishish so'rovini yuborgan vaziyatga duch keldim. Va siz 000 soat davomida ko'rib chiqasiz. Xuddi shu muammolar paydo bo'ladi. Bu hali ham kod. Va bu hali ham hamkorlik. Biz tortishish so'roviga yopishib qolamiz va biz, masalan, bir xil birlashma mojarolarini bir xil bashda hal qilayotganimiz bilan qotib qolamiz.
Men hozir eng go'zal infra-dasturlash bo'yicha hamma narsani juda faol ko'rib chiqyapman. Men endi Pulumini infratuzilmaga olib keldim. Bu sof shaklda dasturlashdir. Bu erda bu yanada yoqimli, chunki menda dasturlash tilining barcha imkoniyatlari bor, ya'ni men bir xil ifs bilan ko'kdan chiroyli almashtirishni qildim va hammasi yaxshi. Ya'ni, mening o'zgarishim allaqachon ustada. Uni hamma allaqachon ko'rishi mumkin. Boshqa muhandislar bu haqda bilishadi. Bu allaqachon biror narsaga ta'sir qilgan. Biroq, u barcha infratuzilmalar uchun yoqilmagan. Bu, masalan, mening sinov skameykalarim uchun yoqilgan. Shuning uchun, sizning savolingizga yana javob berish kerak. Bu xuddi shu tarzda kod bilan ishlaydigan muhandislar uchun hayotimizni osonlashtiradi.
Agar kimdir boshqa savollarga ega bo'lsa?
Menda sovol bor. Men Oleg bilan munozarani davom ettirmoqchiman. Umuman olganda, menimcha, siz haqsiz, agar biron bir vazifani bajarish uchun bir oy kerak bo'lsa, sizda arxitektura muammosi bor, sizda tahlil, parchalanish, rejalashtirish va boshqalar bilan bog'liq muammolar bor. Uzluksiz integratsiyaga ko'ra yashashga harakat qilsangiz, unda siz rejalashtirish bilan og'riqni to'g'irlashni boshlaysiz, chunki siz undan boshqa joyda qochib qutula olmaysiz.
(Oleg) Ha, shunday. Ushbu amaliyotni madaniyatni o'zgartiruvchi boshqa har qanday jiddiy amaliyot bilan solishtirish mumkin. Eng qiyin narsa - bu odatlar, ayniqsa yomon odatlar. Va agar ushbu amaliyotni amalga oshirish uchun atrofingizdagilarning odatlarida jiddiy o'zgarishlar talab qilinsa: ishlab chiquvchilar, menejment, ishlab chiqarish menejeri, keyin sizni kutilmagan hodisalar kutmoqda.
Qanday kutilmagan hodisalar bo'lishi mumkin? Aytaylik, siz tez-tez integratsiyalashishga qaror qildingiz. Va sizda integratsiya bilan bog'liq boshqa narsalar bor, masalan, artefaktlar. Va sizning kompaniyangizda, masalan, har bir artefakt qandaydir tarzda artefaktni saqlash tizimida hisobga olinishi kerak bo'lgan siyosat mavjud. Va bu biroz vaqt talab etadi. Biror kishi reliz menejeri sifatida ushbu artefaktning ishlab chiqarishga tayyorligini tekshirish uchun sinovdan o'tkazgan katakchani belgilashi kerak. Agar 5-10-15 daqiqa davom etsa, lekin siz haftada bir marta tartibni qilsangiz, haftada bir marta yarim soat sarflash kichik soliq hisoblanadi.
Agar siz kuniga 10 marta uzluksiz integratsiya qilsangiz, unda 10 marta 30 daqiqaga ko'paytirilishi kerak. Va bu reliz menejerining ish vaqti miqdoridan oshadi. U shunchaki qilishdan charchaydi. Ba'zi amaliyotlar uchun qat'iy xarajatlar mavjud. Va tamom.
Va endi bunday axlatni qilmaslik uchun siz ushbu qoidani bekor qilishingiz kerak, ya'ni biror narsaga mos keladigan darajani qo'lda belgilamaysiz. Siz butunlay avtomatlashtirilgan tayyorlik testlariga tayanasiz.
Va agar sizga kimdandir dalil kerak bo'lsa, xo'jayin imzo qo'yishi uchun va siz Vasya ruxsat bermaganini aytmasdan ishlab chiqarishga kirmasangiz va hokazo - bularning barchasi bema'nilik amaliyotchining yo'liga tushadi. Chunki soliq bilan bog'liq ba'zi faoliyatlar mavjud bo'lsa, unda hamma narsa 100 barobar ortadi. Shuning uchun, siljish ko'pincha hamma tomonidan quvonch bilan kutib olinmaydi. Chunki odamlarning odatlarini o'zgartirish qiyin.
Odam odatdagi ishini qilsa, u deyarli o'ylamasdan qiladi. Uning kognitiv yuki nolga teng. U shunchaki u bilan o'ynaydi, uning boshida allaqachon nazorat ro'yxati bor, u buni ming marta qilgan. Va siz kelib, unga: "Keling, bu amaliyotni bekor qilaylik va dushanbadan boshlab yangisini joriy qilaylik", desangiz, u uchun bu kuchli kognitiv yukga aylanadi. Va bu bir vaqtning o'zida hammaga keladi.
Shuning uchun, eng oddiy narsa, garchi hamma ham bunday hashamatga ega bo'lmasa-da, lekin men har doim shunday qilaman, bu quyidagicha. Agar yangi loyiha boshlansa, odatda barcha sinovdan o'tmagan amaliyotlar darhol ushbu loyihaga kiritiladi. Loyiha yosh bo'lsa-da, biz hech narsani xavf ostiga qo'ymaymiz. Hali hech qanday Prod yo'q, yo'q qiladigan hech narsa yo'q. Shuning uchun u mashg'ulot sifatida ishlatilishi mumkin. Bu yondashuv ishlaydi. Ammo hamma kompaniyalar ham bunday loyihalarni tez-tez boshlash imkoniga ega emas. Garchi bu ham biroz g'alati bo'lsa-da, chunki hozirda to'liq raqamli transformatsiya bor, har bir kishi raqobatchilardan ortda qolish uchun tajribalarni boshlashi kerak.
Bu erda siz birinchi navbatda nima qilish kerakligini tushunishingiz kerak degan xulosaga keldingiz. Dunyo ideal emas, mahsulot ham ideal emas.
Ha, bu narsalar bir-biri bilan bog'liq.
Korxonalar ham har doim ham bu yo'ldan borishlari kerakligini tushunmaydilar.
Hech qanday o'zgarish umuman mumkin bo'lmagan vaziyat mavjud. Bu jamoada bosim ko'proq bo'lgan vaziyat. Jamoa allaqachon ancha yonib ketgan. Uning hech qanday tajriba uchun bo'sh vaqti yo'q. Ular ertalabdan kechgacha funksiyalar ustida ishlaydi. Va boshqaruv kamroq va kamroq xususiyatlarga ega. Ko'proq va ko'proq talab qilinadi. Bunday vaziyatda hech qanday o'zgarishlar bo'lishi mumkin emas. Jamoaga shuni aytish mumkinki, ertaga biz kechagidek qilamiz, faqat biroz ko'proq xususiyatlarni qilishimiz kerak. Shu ma'noda, hech qanday amaliyotga o'tish mumkin emas. Bu klassik holat boltani keskinlashtirish uchun vaqt yo'q, daraxtlarni kesish kerak, shuning uchun ular uni zerikarli bolta bilan kesishadi. Bu erda oddiy maslahatlar yo'q.
(Dmitriy) Men suhbatdan tushuntirishni o'qiyman: "Ammo bizga turli darajadagi testlarni qamrab olish kerak. Sinovlarga qancha vaqt ajratiladi? Bu biroz qimmat va ko'p vaqtni oladi."
(Oleg) Bu klassik noto'g'ri tushuncha. Ishonchli bo'lishingiz uchun etarli testlar bo'lishi kerak. Uzluksiz integratsiya birinchi navbatda 100% sinovlar o'tkaziladigan narsa emas va shundan keyingina siz ushbu amaliyotni qo'llashni boshlaysiz. Uzluksiz integratsiya sizning kognitiv yukingizni kamaytiradi, chunki siz ko'zingiz bilan ko'rgan har bir o'zgarishlar shunchalik ravshanki, siz hatto sinovlarsiz ham biror narsani buzadimi yoki yo'qmi tushunasiz. Buni tezda boshingizda sinab ko'rishingiz mumkin, chunki o'zgarishlar kichik. Agar sizda faqat qo'lda testerlar bo'lsa ham, ular uchun ham osonroq. Siz tashqariga chiqdingiz va dedingiz: "Mana, biror narsa buzilganmi?" Ular tekshirib: "Yo'q, hech narsa buzilmagan", deyishdi. Chunki sinovchi qayerga qarashni biladi. Sizda bitta kod bilan bog'langan bitta majburiyat bor. Va bu o'ziga xos xatti-harakatlar bilan foydalaniladi.
Bu erda siz, albatta, bezatilgansiz.
(Dmitriy) Men bu erda rozi emasman. Amaliyot mavjud - test asosida ishlab chiqish, bu sizni bundan qutqaradi.
(Oleg) Xo'sh, men hali bu nuqtaga etib bormadim. Birinchi illyuziya shundan iboratki, siz testlarning 100 foizini yozishingiz kerak yoki doimiy integratsiyani umuman bajarishingiz shart emas. Bu yolg'on. Bu ikkita parallel amaliyotdir. Va ular bevosita bog'liq emas. Sizning test qamrovingiz optimal bo'lishi kerak. Optimal - bu sizning xo'jayiningiz majburiyatdan keyin qolgan usta sifati sizga juma kuni kechqurun mast holda "O'rnatish" tugmasini ishonch bilan bosish imkonini berishiga ishonchingiz komil ekanligini anglatadi. Bunga qanday erishasiz? Ko'rib chiqish orqali, qamrab olish orqali, yaxshi monitoring orqali.
Yaxshi monitoringni testlardan ajratib bo'lmaydi. Agar siz testlarni bir marta preprodda o'tkazsangiz, ular barcha foydalanuvchi skriptlaringizni bir marta tekshiradilar va tamom. Va agar siz ularni cheksiz tsiklda ishlatsangiz, bu sizning o'rnatilgan monitoring tizimingiz bo'lib, u hamma narsani cheksiz sinovdan o'tkazadi - u qulaganmi yoki yo'qmi. Bunday holda, farq faqat bir yoki ikki marta amalga oshiriladi. Juda yaxshi testlar to'plami... cheksiz ishlaydi, bu monitoring. Va to'g'ri monitoring shunday bo'lishi kerak.
Shuning uchun, juma kuni kechqurun tayyorlanib, uyga qaytganingizda, bu holatga qanday erishishingiz boshqa savol. Balki siz shunchaki dadil ahmoqdirsiz.
Keling, Uzluksiz integratsiyaga biroz qaytaylik. Biz biroz boshqacha murakkab amaliyotga qochib ketdik.
Va ikkinchi illyuziya shundaki, MVP, ular aytishlaricha, tezda bajarilishi kerak, shuning uchun u erda testlar umuman kerak emas. Albatta, bunday emas. Gap shundaki, siz MVP-da foydalanuvchi hikoyasini yozganingizda, uni to'pda ishlab chiqishingiz mumkin, ya'ni siz qandaydir foydalanuvchi hikoyasi borligini eshitdingiz va darhol uni kodlash uchun yugurdingiz yoki TDD yordamida ishlashingiz mumkin. Va TDDga ko'ra, amaliyot shuni ko'rsatadiki, u ko'proq vaqt talab qilmaydi, ya'ni testlar yon ta'sirdir. TDD amaliyoti sinovdan iborat emas. Sinovga asoslangan rivojlanish deb ataladigan narsaga qaramay, bu umuman testlar haqida emas. Bu, shuningdek, me'moriy yondashuv. Bu kerak bo'lgan narsani yozmaslik va kerak bo'lmagan narsani yozish uchun yondashuv. Bu ilova arxitekturasini yaratish nuqtai nazaridan fikrlashning keyingi iteratsiyasiga e'tibor berish amaliyotidir.
Shuning uchun, bu illyuziyalardan xalos bo'lish unchalik oson emas. MVP va testlar bir-biriga zid emas. Hatto, aksincha, agar siz MVPni TDD amaliyotidan foydalangan holda qilsangiz, unda siz buni umuman mashq qilmasdan, balki to'pda qilganingizdan ko'ra yaxshiroq va tezroq bajarasiz.
Bu juda noaniq va murakkab fikr. Endi men ko'proq testlar yozaman va shu bilan birga tezroq nimadir qilaman, deb eshitganingizda, bu mutlaqo etarli emasdek tuyuladi.
(Dmitriy) Bu erda ko'p odamlar MVP deb atashganda, odamlar oddiy narsalarni yozishga juda dangasa. Va bu hali ham boshqa narsalar. MVP ni ishlamaydigan yomon narsaga aylantirishning hojati yo'q.
Ha, ha, siz haqsiz.
Va keyin to'satdan mahsulotdagi MVP.
Abadiy.
Testlar yozayotganingizni va ko'proq ish qilayotganingizni eshitganingizda TDD juda g'alati eshitiladi. Bu juda g'alati tuyuladi, lekin aslida bu tarzda tezroq va chiroyli bo'lib chiqadi. Sinovni yozayotganda, qanday kod va qanday chaqirilishi, shuningdek, undan qanday xatti-harakatlar kutilishi haqida allaqachon boshingizda ko'p o'ylaysiz. Siz shunchaki biron bir funktsiyani yozganimni aytmaysiz va u biror narsa qiladi. Avvaliga uning falon sharoiti bor, falon yo‘l bilan chaqiriladi, deb o‘ylagansiz. Siz buni testlar bilan qamrab olasiz va shundan siz interfeyslaringiz kodingiz ichida qanday ko'rinishini tushunasiz. Bu arxitekturaga katta ta'sir ko'rsatadi. Sizning kodingiz avtomatik ravishda modulliroq bo'ladi, chunki siz avval uni qanday sinab ko'rishingizni tushunishga harakat qilasiz va shundan keyingina uni yozasiz.
TDD bilan men bilan nima sodir bo'ldi, men hali Ruby dasturchisi bo'lganimda Ruby murabbiyini yollaganman. Va u: "Keling, buni TDD bo'yicha qilaylik", deydi. Men o'yladim: "Jin ursin, endi men qo'shimcha narsa yozishim kerak". Va biz ikki hafta ichida TDD yordamida Pythonda barcha ishchi kodni yozishga kelishib oldik. Ikki hafta o'tgach, men qaytib ketishni xohlamasligimni angladim. Ikki hafta davomida buni hamma joyda qo'llashga urinib ko'rganingizdan so'ng, siz hatto o'ylash qanchalik oson bo'lganini tushunasiz. Ammo bu aniq emas, shuning uchun men hammaga maslahat beraman, agar sizda TDD qiyin, ko'p vaqt talab qiladigan va keraksiz deb o'ylasangiz, uni atigi ikki hafta ushlab turishga harakat qiling. Menga ikkitasi etarli edi.
(Dmitriy) Biz bu fikrni infratuzilma faoliyati nuqtai nazaridan kengaytirishimiz mumkin. Yangi narsalarni ishga tushirishdan oldin biz monitoring qilamiz va keyin ishga tushiramiz. Bunday holda, monitoring biz uchun odatiy sinovga aylanadi. Va monitoring orqali rivojlanish bor. Ammo deyarli hamma aytadiki, bu uzoq, men dangasaman, men vaqtinchalik qoralama qildim. Agar biz oddiy monitoringni amalga oshirgan bo'lsak, biz CI tizimining holatini tushunamiz. Va CI tizimi juda ko'p monitoringga ega. Biz tizimning holatini tushunamiz, uning ichida nima borligini tushunamiz. Rivojlanish jarayonida esa, biz shunchaki tizimni kerakli holatga keltirish uchun qilamiz.
Ushbu amaliyotlar uzoq vaqtdan beri ma'lum. Biz bu haqda 4 yil oldin muhokama qilganmiz. Ammo 4 yil ichida deyarli hech narsa o'zgarmadi.
Ammo bu eslatmada men rasmiy muhokamani tugatishni taklif qilaman.
Video (media elementi sifatida kiritilgan, lekin ba'zi sabablarga ko'ra ishlamaydi):
Manba: www.habr.com