Hisobotda ba'zi DevOps amaliyotlari haqida so'z boradi, ammo ishlab chiquvchi nuqtai nazaridan. Odatda, DevOps-ga qo'shilgan barcha muhandislar allaqachon bir necha yillik ma'muriy tajribaga ega. Ammo bu bu erda ishlab chiquvchi uchun joy yo'q degani emas. Ko'pincha ishlab chiquvchilar "kunning navbatdagi favqulodda muhim xatosini" tuzatish bilan band va ular DevOps maydonini tezda ko'rib chiqishga ham vaqtlari yo'q. Muallifning fikriga ko'ra, DevOps, birinchi navbatda, sog'lom fikrdir. Ikkinchidan, bu yanada samaraliroq bo'lish imkoniyatidir. Agar siz dasturchi bo'lsangiz, sog'lom fikrga ega bo'lsangiz va jamoaviy o'yinchi sifatida samaraliroq bo'lishni istasangiz, bu hisobot siz uchun.
O'zimni tanishtirsam, xonada meni tanimaydigan odamlar borligini to'liq tan olaman. Mening ismim Anton Boyko, men Microsoft Azure MVPman. MVP nima? Bu Model-View-Taqdimotchi. Model-View-Taqdimotchi aynan men.
Bundan tashqari, men hozirda Ciklumda yechim arxitektori lavozimida ishlayman. Va yaqinda men o'zimga shunday go'zal domen sotib oldim va men odatda taqdimotlarda ko'rsatadigan elektron pochtamni yangiladim. Siz menga yozishingiz mumkin: me [dog] byokoant.pro. Savollar bilan menga elektron pochta orqali murojaat qilishingiz mumkin. Men odatda ularga javob beraman. Yagona narsa shundaki, men ikkita mavzuga oid savollarni elektron pochta orqali olishni xohlamayman: siyosat va din. Siz menga elektron pochta orqali boshqa hamma narsa haqida yozishingiz mumkin. Biroz vaqt o'tadi, men javob beraman.
O'zingiz haqingizda bir necha so'z:
- Men 10 yildan beri shu sohadaman.
- Men Microsoftda ishlaganman.
- Men 2014 yilda biz asos solgan Ukraina Azure hamjamiyatining asoschisiman. Va bizda hali ham mavjud va uni rivojlantirmoqdamiz.
- Men Ukrainada o‘tkazilayotgan Azure konferensiyasi asoschisining otasi hamman.
- Men Kiyevda Global Azure Bootcampni tashkil etishga ham yordam beraman.
- Aytganimdek, men Microsoft Azure MVPman.
- Men konferentsiyalarda tez-tez gapiraman. Men konferentsiyalarda gapirishni juda yaxshi ko'raman. O'tgan yil davomida men 40 marta kontsert berishga muvaffaq bo'ldim. Agar siz Ukraina, Belorussiya, Polsha, Bolgariya, Shvetsiya, Daniya, Gollandiya, Ispaniyadan o'tsangiz yoki Evropadagi boshqa davlatni bersangiz yoki olib ketsangiz, unda bulutli mavzusi bo'lgan konferentsiyaga borganingizda, Siz meni ma'ruzachilar ro'yxatida ko'rishingiz mumkin.
- Men ham Star Trek muxlisiman.
Keling, kun tartibi haqida bir oz gaplashaylik. Bizning kun tartibimiz juda oddiy:
- Biz DevOps nima ekanligi haqida gaplashamiz. Keling, nima uchun bu muhimligini gapiraylik. Ilgari DevOps rezyumeingizga yozgan va darhol +500 dollar ish haqi olgan kalit so'z edi. Endi maoshingizga +500 dollar olish uchun, masalan, rezyumeingizga blokcheyn yozishingiz kerak.
- Va keyin, bu nima ekanligini bir oz tushunganimizda, biz DevOps amaliyotlari nima haqida gaplashamiz. Ammo umuman DevOps kontekstida emas, balki ishlab chiquvchilar uchun qiziqarli bo'lishi mumkin bo'lgan DevOps amaliyotlari haqida. Men sizga nima uchun ular sizni qiziqtirishi mumkinligini aytaman. Men sizga nima uchun buni qilish kerakligini va bu sizga kamroq og'riqni boshdan kechirishga qanday yordam berishi mumkinligini aytaman.
Ko'pchilik ko'rsatadigan an'anaviy rasm. Bu ko'plab loyihalarda sodir bo'ladi. Bu bizning dasturiy ta'minotimizni qo'llab-quvvatlaydigan ishlab chiqish va operatsion bo'limlarga ega bo'lgan payt. Va bu bo'limlar bir-biri bilan aloqa qilmaydi.
Ehtimol, agar siz DevOps va operatsion bo'limlarda buni aniq his qila olmagan bo'lsangiz, Dev va QA bo'limlari bilan o'xshashlik qilishingiz mumkin. Dasturiy ta'minotni ishlab chiqadigan odamlar bor va ishlab chiquvchilar nuqtai nazaridan yomon bo'lgan QA odamlari bor. Misol uchun, men o'z ajoyib kodimni omborga topshiraman va u erda o'tirgan bir badjahl bor, u menga bu kodni qaytarib beradi va sizning kodingiz yomon ekanligini aytadi.
Bularning barchasi odamlarning bir-biri bilan aloqa qilmasligi sababli sodir bo'ladi. Va ular tushunmovchilik devori orqali bir-birlariga ba'zi paketlarni, ba'zi ilovalarni tashlashadi va ular bilan nimadir qilishga harakat qilishadi.
Aynan shu devor DevOps madaniyati yo'q qilish uchun mo'ljallangan, ya'ni. odamlarni bir-biri bilan muloqot qilishga majburlash va hech bo'lmaganda loyihadagi turli odamlar nima qilishini va nima uchun ularning ishi muhimligini tushunish.
Va biz DevOps haqida gapirganda, kimdir sizga DevOps bu loyiha doimiy integratsiyaga ega ekanligini aytadi; kimdir DevOps, agar loyiha "infratuzilmani kod sifatida" amaliyotini amalga oshirsa, deb aytadi; kimdir DevOps-ga birinchi qadam xususiyatlarni tarmoqqa ajratish, xususiyat bayroqlari ekanligini aytadi.
Umuman olganda, bularning barchasi o'ziga xos tarzda to'g'ri. Ammo bu bizda mavjud bo'lgan yakuniy amaliyotlar. Ushbu amaliyotlarga o'tishdan oldin, loyihangizda, kompaniyangizda Dev-Ops metodologiyasini joriy etishning 3 bosqichini ko'rsatadigan ushbu slaydni ko'rib chiqishni taklif qilaman.
Ushbu slaydning ikkinchi norasmiy nomi ham bor. DevOpsning 3 mushketyori nima ekanligini bilish uchun Internetda qidirishingiz mumkin. Ehtimol, siz ushbu maqolani topishingiz mumkin. Nega 3 mushketyor? Quyida shunday deyiladi: odamlar, jarayonlar va mahsulotlar, ya'ni. PPP - Porthos, Porthos va Porthos. Mana, DevOpsning 3 mushketyorlari. Ushbu maqola nima uchun bu muhim va u nimani anglatishini batafsilroq tavsiflaydi.
DevOps madaniyatini joriy qilishni boshlaganingizda, uni quyidagi tartibda amalga oshirish juda muhimdir.
Dastlab siz odamlar bilan gaplashishingiz kerak. Va siz odamlarga bu nima ekanligini va undan qanday foyda olishlarini tushuntirishingiz kerak.
Bizning konferentsiyamiz DotNet Fest deb ataladi. Tashkilotchilar menga aytganidek, biz asosan ishlab chiquvchilar auditoriyasini bu erga taklif qildik, shuning uchun zaldagi odamlarning ko'pchiligi rivojlanish bilan shug'ullanadi deb umid qilaman.
Biz odamlar haqida gaplashamiz, ishlab chiquvchilar har kuni nima qilishni xohlashlari haqida gaplashamiz. Ular eng ko'p nimani xohlashadi? Ular yangi kod yozishni, yangi freymvorklardan foydalanishni, yangi xususiyatlarni yaratishni xohlashadi. Ishlab chiquvchilar eng kam nimani xohlashadi? Eski xatolarni tuzating. Umid qilamanki, siz men bilan rozi bo'lasiz. Ishlab chiquvchilar buni xohlashadi. Ular yangi xususiyatlarni yozishni xohlashadi, xatolarni tuzatishni xohlamaydilar.
Muayyan ishlab chiquvchi ishlab chiqaradigan xatolar soni uning qo'llari qanchalik tekis ekanligiga va dumba cho'ntagidan emas, balki yelkasidan qanchalik o'sishiga bog'liq. Ammo, shunga qaramay, bizda katta loyiha bo'lsa, ba'zida hamma narsani kuzatib bo'lmaydi, shuning uchun bizga yanada barqaror va sifatli kod yozishga yordam beradigan ba'zi yondashuvlardan foydalanish yaxshi bo'lar edi.
QA ko'proq nimani xohlaydi? Ular zalda bor yoki yo'qligini bilmayman. Men QAni xohlayman deb aytishim qiyin, chunki men hech qachon bunday bo'lmaganman. Yigitlarga esa xafa bo'lmang, men hech qachon bunday qilmayman deb aytishadi. Lekin ularning ishini ma'nosiz va befoyda deb bilganim uchun emas, balki o'zimni bu ishni samarali bajara oladigan odam deb hisoblamaganim uchun men buni qilishga urinmayman ham. Ammo men tushunganimdek, QA eng yoqmaydigan narsa ertalab ishlaydi, doimiy ravishda qandaydir regressiya testlarini o'tkazadi, ular 3 sprint oldin ishlab chiquvchilarga xabar bergan xatolarga qadam qo'yadi va shunday deyishadi: "Siz qachon bo'lasiz? , Janob D Artanyan, bu xatoni tuzating. Va janob d'Artagnan unga javob beradi: "Ha, ha, ha, men buni allaqachon tuzatdim." Va qanday qilib men bitta xatoni tuzatdim va yo'lda 5 ta qildim.
Ishlab chiqarishda ushbu yechimni qo'llab-quvvatlaydigan odamlar, barcha oddiy odamlar barga borganlarida, har juma kuni serverni qayta ishga tushirishga majbur bo'lmasliklari uchun ushbu yechim xatosiz ishlashini xohlashadi. Ishlab chiquvchilar juma kuni ishga tushirildi, administratorlar shanbagacha o'tirib, ushbu joylashtirishni o'rnatishga va tuzatishga harakat qilishadi.
Va odamlarga ular bir xil muammolarni hal qilishga qaratilganligini tushuntirsangiz, jarayonlarni rasmiylashtirishga o'tishingiz mumkin. Bu juda muhim. Nega? Chunki biz "rasmiylashtirish" deganda, sizning jarayonlaringiz hech bo'lmaganda salfetkada qanday sodir bo'lishini tasvirlab berishingiz muhimdir. Agar siz, masalan, QA muhitiga yoki ishlab chiqarish muhitiga joylashtirsangiz, u har doim shu tartibda sodir bo'lishini tushunishingiz kerak; bu bosqichlarda biz, masalan, avtomatik birlik testlari va UI testlarini o'tkazamiz. Joylashtirishdan so'ng biz joylashtirish yaxshi yoki yomon o'tganligini tekshiramiz. Ammo sizda allaqachon ishlab chiqarishga o'rnatilganda qayta-qayta takrorlanishi kerak bo'lgan harakatlarning aniq ro'yxati mavjud.
Va faqat sizning jarayonlaringiz rasmiylashtirilganda, siz ushbu jarayonlarni avtomatlashtirishga yordam beradigan mahsulotlarni tanlashni boshlaysiz.
Afsuski, men buni tez-tez teskari holatda ko'raman. Kimdir "DevOps" so'zini eshitishi bilanoq, ular darhol Jenkins-ni o'rnatishni taklif qilishadi, chunki ular Jenkins-ni o'rnatishi bilanoq DevOps-ga ega bo'lishlariga ishonishadi. Ular Jenkinsni o'rnatdilar, Jenkins veb-saytidagi "Qanday qilish kerak" maqolalarini o'qib chiqdilar, jarayonlarni "Qanday qilish kerak" maqolalariga kiritishga harakat qilishdi, keyin odamlarning oldiga kelib, kitobda buni shunday qilish kerakligi aytilgan, deb aytishdi, shuning uchun biz buni shunday qilamiz.
Jenkins yomon vosita emas. Men buni hech qanday tarzda aytmoqchi emasman. Ammo bu mahsulotlardan faqat bittasi. Va qaysi mahsulotdan foydalanish sizning oxirgi qaroringiz bo'lishi kerak va hech qanday holatda birinchi bo'lmaydi. Sizning mahsulotingiz madaniyat va yondashuvlarni amalga oshirish bilan boshqarilmasligi kerak. Buni tushunish juda muhim, shuning uchun men ushbu slaydga ko'p vaqt sarflayman va bularning barchasini uzoq vaqt davomida tushuntiraman.
Keling, umuman DevOps amaliyotlari haqida gapiraylik. Ular nima? Farqi nimada? Ularni qanday qilib sinab ko'rish kerak? Nima uchun ular muhim?
Siz eshitgan birinchi amaliyot doimiy integratsiya deb ataladi. Ehtimol, loyihada kimdir doimiy integratsiyaga (CI) ega.
Eng katta muammo shundaki, men ko'pincha odamdan: "Sizda loyihada CI bormi?" va u: "Ha" deydi, men nima qilayotganini so'rasam, u menga avtomatlashtirish jarayonini mutlaqo tasvirlab beradi. Bu mutlaqo to'g'ri emas.
Aslida, CI amaliyoti shunchaki turli odamlar yozadigan kodni bitta kod bazasiga birlashtirishga qaratilgan. Ana xolos.
CI bilan bir qatorda, odatda, yo'lda boshqa amaliyotlar mavjud - doimiy joylashtirish, relizlarni boshqarish, ammo biz bu haqda keyinroq gaplashamiz.
CIning o'zi bizga turli xil odamlar kod yozishini va bu kod doimiy ravishda bitta kod bazasiga birlashtirilishi kerakligini aytadi.
Bu bizga nima beradi va nima uchun bu muhim? Agar bizda DotNet bo'lsa, bu yaxshi, bu kompilyatsiya qilingan til, biz dasturimizni kompilyatsiya qilishimiz mumkin. Agar u kompilyatsiya qilsa, bu allaqachon yaxshi belgidir. Bu hali hech narsani anglatmaydi, lekin bu hech bo'lmaganda kompilyatsiya qilishimiz mumkin bo'lgan birinchi yaxshi belgidir.
Keyin biz ba'zi testlarni o'tkazishimiz mumkin, bu ham alohida amaliyotdir. Sinovlarning barchasi yashil rangda - bu ikkinchi yaxshi belgidir. Ammo yana, bu hech narsani anglatmaydi.
Lekin nega buni qilgan bo'lardingiz? Bugun men gaplashadigan barcha amaliyotlar taxminan bir xil qiymatga ega, ya'ni taxminan bir xil foyda keltiradi va taxminan bir xil tarzda o'lchanadi.
Birinchidan, bu sizga etkazib berishni tezlashtirishga imkon beradi. Bu sizga etkazib berishni tezlashtirishga qanday imkon beradi? Kod bazasiga yangi o'zgarishlar kiritganimizda, biz darhol ushbu kod bilan biror narsa qilishga harakat qilishimiz mumkin. Payshanba kelishini kutmaymiz, chunki payshanba kuni biz uni QA Environmentga chiqaramiz, biz buni shu yerda va shu yerda qilamiz.
Men sizga hayotimdagi bitta qayg'uli voqeani aytib beraman. Bu ancha oldin, men hali yosh va kelishgan paytlarim edi. Endi men allaqachon yosh, chiroyli va aqlli va kamtarman. Bir muncha vaqt oldin men loyihada edim. Bizda 30 ga yaqin dasturchilardan iborat katta jamoa bor edi. Va bizda taxminan 10 yil davomida ishlab chiqilgan katta, katta Enterprise loyihasi bor edi. Va bizning turli filiallarimiz bor edi. Omborda bizda ishlab chiquvchilar yuradigan filialimiz bor edi. Va ishlab chiqarilgan kod versiyasini ko'rsatadigan filial mavjud edi.
Ishlab chiqarish filiali ishlab chiquvchilar uchun mavjud bo'lgan filialdan 3 oy orqada edi. Bu nimani anglatadi? Bu shuni anglatadiki, menda ishlab chiquvchilarning aybi bilan ishlab chiqarishga ketadigan xatolik paydo bo'lishi bilanoq, ular bunga ruxsat bergani uchun va QA aybi bilan, ular ko'rib chiqishganligi sababli, demak, agar men ishlab chiqarish uchun tuzatish vazifasi, keyin men 3 oy oldin kodim o'zgarishlarimni orqaga qaytarishim kerak. Men 3 oy oldin bo'lgan narsalarni eslab, u erda tuzatishga harakat qilishim kerak.
Agar siz hali bunday tajribaga ega bo'lmasangiz, uni uy loyihangizda sinab ko'rishingiz mumkin. Asosiysi, uni tijoratda sinab ko'rmang. Bir necha qator kod yozing, ularni olti oy davomida unuting va keyin qaytib keling va bu kod satrlari nima haqida ekanligini va ularni qanday tuzatish yoki optimallashtirish mumkinligini tezda tushuntirishga harakat qiling. Bu juda hayajonli tajriba.
Agar bizda uzluksiz integratsiya amaliyoti mavjud bo'lsa, bu bizga kodimni yozganimdan so'ng darhol shu yerda va hozirda bir qator avtomatlashtirilgan vositalar yordamida tekshirish imkonini beradi. Bu menga to'liq rasmni bermasligi mumkin, ammo shunga qaramay, u hech bo'lmaganda ba'zi xavflarni olib tashlaydi. Va agar biron bir potentsial xato bo'lsa, men bu haqda hoziroq, ya'ni bir necha daqiqada bilib olaman. Men 3 oyni orqaga qaytarishim shart emas. Men faqat 2 daqiqa orqaga qaytishim kerak. Yaxshi qahva mashinasi 2 daqiqada qahva tayyorlashga ham vaqt topa olmaydi, shuning uchun bu juda zo'r.
Bu har bir loyihada vaqti-vaqti bilan takrorlanishi mumkin bo'lgan qiymatga ega, ya'ni. faqat siz uni o'rnatganingiz emas. Siz amaliyotni o'zi ham takrorlashingiz mumkin va loyihaga kiritilgan har bir yangi o'zgarish uchun CI o'zi takrorlanadi. Bu sizga resurslarni optimallashtirish imkonini beradi, chunki sizning jamoangiz yanada samarali ishlaydi. Endi siz 3 oy oldin ishlagan kodingizdan xatolik paydo bo'ladigan vaziyatga ega bo'lmaysiz. Siz o'tirganingizda va birinchi ikki soatni o'sha paytda nima bo'lganini tushunishga va biror narsani tuzatishni boshlashdan oldin kontekstning mohiyatini o'rganishga sarflaganingizda endi kontekstni o'zgartira olmaysiz.
Ushbu amaliyotning muvaffaqiyati yoki muvaffaqiyatsizligini qanday o'lchashimiz mumkin? Agar siz katta xo'jayinga CI loyihasida amalga oshirganimiz haqida hisobot bersangiz, u blah blah bla eshitadi. Biz buni amalga oshirdik, OK, lekin nima uchun, bu bizga nima olib keldi, biz uni qanday o'lchaymiz, qanchalik to'g'ri yoki noto'g'ri amalga oshirmoqdamiz?
Birinchisi, CI tufayli biz ko'proq va tez-tez joylashtirishimiz mumkin, chunki bizning kodimiz barqarorroq. Xuddi shu tarzda, xatoni topish uchun vaqtimiz qisqartiriladi va bu xatoni tuzatish vaqti aynan shu erda va hozir tizimdan bizning kodimizda nima noto'g'ri ekanligi haqida javob olganimiz uchun qisqaradi.
Bizda mavjud bo'lgan yana bir amaliyot - bu Avtomatlashtirishni sinovdan o'tkazish amaliyoti bo'lib, u ko'pincha CI amaliyoti bilan birga keladi. Ular qo'l qovushtirib yurishadi.
Bu erda nimani tushunish muhim? Bizning testlarimiz boshqacha ekanligini tushunish muhimdir. Va har bir avtomatlashtirilgan test o'z muammolarini hal qilishga qaratilgan. Bizda, masalan, modulni alohida sinab ko'rish imkonini beruvchi birlik testlari mavjud, ya'ni. Vakuumda qanday ishlaydi? Bu yaxshi.
Shuningdek, bizda turli modullarning bir-biri bilan qanday integratsiyalashuvini tushunishga imkon beruvchi integratsiya testlari mavjud. Bu ham yaxshi.
Bizda foydalanuvchi interfeysi bilan ishlash mijoz tomonidan qo'yilgan ma'lum talablarga qanchalik mos kelishini tekshirish imkonini beruvchi UI avtomatlashtirish testlariga ega bo'lishimiz mumkin.
Siz o'tkazadigan maxsus testlar ularni qanchalik tez-tez bajarishingizga ta'sir qilishi mumkin. Birlik testlari odatda qisqa va kichik yoziladi. Va ular muntazam ravishda ishga tushirilishi mumkin.
Agar biz UI avtomatlashtirish testlari haqida gapiradigan bo'lsak, sizning loyihangiz kichik bo'lsa yaxshi bo'ladi. UI avtomatlashtirish testlari biroz vaqt talab qilishi mumkin. Lekin odatda UI avtomatlashtirish testi katta loyihada bir necha soat davom etadigan narsadir. Va bir necha soat bo'lsa yaxshi bo'ladi. Bitta narsa shundaki, ularni har bir qurilish uchun ishlatishning ma'nosi yo'q. Ularni tunda ishlatish mantiqan. Ertalab hamma ishga kelganida: testerlar ham, ishlab chiquvchilar ham biz tunda UI avtotestini o'tkazganimiz va bu natijalarga erishganimiz haqida qandaydir xabar olishdi. Va bu erda, mahsulotingiz ba'zi talablarga javob berishini tekshiradigan serverning bir soatlik ishi o'sha QA muhandisining bir soatlik ishidan ancha arzon bo'ladi, hatto u oziq-ovqat va rahmat uchun ishlaydigan kichik QA muhandisi bo'lsa ham. Shunga qaramay, mashinaning bir soat ishlashi arzonroq bo'ladi. Shuning uchun unga sarmoya kiritish mantiqan.
Men ustida ishlayotgan yana bir loyiham bor. Ushbu loyihada ikki haftalik sprintlar o'tkazdik. Loyiha katta edi, moliya sektori uchun muhim edi va xatolikka yo'l qo'yib bo'lmaydi. Va ikki haftalik sprintdan so'ng, rivojlanish tsikli yana 4 hafta davom etgan sinov jarayoniga o'tdi. Fojia ko'lamini tasavvur qilishga harakat qiling. Biz ikki hafta davomida kod yozamiz, so'ng uni ala CodeFreeze qilamiz, dasturning yangi versiyasiga to'playmiz va testerlarga tarqatamiz. Sinovchilar uni yana 4 hafta davomida sinab ko'rishadi, ya'ni. Ular buni sinab ko'rayotganda, biz ular uchun yana ikkita versiyani tayyorlashga vaqtimiz bor. Bu haqiqatan ham achinarli holat.
Va biz ularga, agar siz samaraliroq bo'lishni istasangiz, avtomatlashtirilgan test amaliyotlarini qo'llash mantiqiy ekanligini aytdik, chunki aynan shu yerda sizni xafa qiladigan narsa shu.
Uzluksiz joylashtirishni mashq qiling. Ajoyib, siz qurilishni tugatdingiz. Bu allaqachon yaxshi. Sizning kodingiz tuzilgan. Endi bu tuzilmani ba'zi muhitda joylashtirish yaxshi bo'lardi. Aytaylik, ishlab chiquvchilar uchun muhitda.
Nima uchun bu muhim? Birinchidan, siz joylashtirish jarayonining o'zi bilan qanchalik muvaffaqiyatli ekanligingizni ko'rishingiz mumkin. Men shunga o'xshash loyihalarni uchratdim: "Ilovaning yangi versiyasini qanday o'rnatasiz?", deb so'raganimda, bolalar menga: "Biz uni yig'amiz va zip arxiviga joylashtiramiz. Biz uni adminga pochta orqali yuboramiz. Administrator bu arxivni yuklab oladi va kengaytiradi. Va butun ofis server yangi versiyani olishi uchun ibodat qilishni boshlaydi.
Keling, oddiy narsadan boshlaylik. Masalan, ular CSS-ni arxivga qo'yishni unutishdi yoki java-skript fayl nomidagi hashtagni o'zgartirishni unutishdi. Va biz serverga so'rov yuborganimizda, brauzer allaqachon ushbu java-skript fayliga ega deb o'ylaydi va uni yuklab olmaslikka qaror qiladi. Va eski versiya bor edi, nimadir etishmayotgan edi. Umuman olganda, ko'plab muammolar bo'lishi mumkin. Shu sababli, Uzluksiz joylashtirish amaliyoti sizga hech bo'lmaganda toza mos yozuvlar tasvirini olib, uni butunlay toza yangi muhitga yuklaganingizda nima bo'lishini sinab ko'rish imkonini beradi. Bu qaerga olib kelishini ko'rishingiz mumkin.
Bundan tashqari, kodni bir-biringizga integratsiyalashganingizda, ya'ni. buyruq o'rtasida, bu sizga UIda qanday ko'rinishini ham ko'rish imkonini beradi.
Ko'p vanil java-skriptidan foydalanilganda yuzaga keladigan muammolardan biri shundaki, ikkita dasturchi bir xil nomdagi o'zgaruvchini deraza ob'ektida shoshilinch ravishda e'lon qilgan. Va keyin, omadingizga qarab. Kimning java-skript fayli ikkinchi o'chirilgan bo'lsa, ikkinchisining o'zgarishlarini qayta yozadi. Bu ham juda hayajonli. Siz kirasiz: bir narsa bir kishi uchun ishlaydi, boshqasi boshqasi uchun ishlamaydi. Va bularning barchasi ishlab chiqarishda paydo bo'lganda "ajoyib".
Bizda mavjud bo'lgan keyingi amaliyot - bu Avtomatik tiklash amaliyoti, ya'ni dasturning oldingi versiyasiga qaytish.
Nima uchun bu ishlab chiquvchilar uchun muhim? Olis, olis 90-yillarni, kompyuterlar katta, dasturlar esa kichik bo‘lgan paytlarni eslayotganlar hamon bor. Va veb-ishlab chiqishning yagona yo'li PHP orqali edi. Bu PHP yomon til emas, garchi shunday bo'lsa ham.
Ammo muammo boshqacha edi. Biz PHP saytimizning yangi versiyasini o'rnatganimizda, uni qanday joylashtirdik? Ko'pincha biz Far Manager yoki boshqa narsalarni ochdik. Va bu fayllarni FTP-ga yukladi. Va biz birdan bizda kichik, kichik xatolik borligini angladik, masalan, nuqta-vergul qo'yishni unutib qo'ydik yoki ma'lumotlar bazasi uchun parolni o'zgartirishni unutib qo'ydik va ma'lumotlar bazasi uchun parol mavjud, bu mahalliy xostda. Va biz tezda FTP ga ulanishga va fayllarni o'sha erda tahrirlashga qaror qildik. Bu shunchaki olov! Bu 90-yillarda mashhur bo'lgan narsa.
Ammo, agar siz taqvimga qaramagan bo'lsangiz, 90-yillar deyarli 30 yil oldin edi. Endi hamma narsa biroz boshqacha sodir bo'lmoqda. Va fojia ko'lamini tasavvur qilishga harakat qiling: "Biz ishlab chiqarishga jo'natdik, lekin u erda nimadir noto'g'ri ketdi. Mana sizning FTP login va parolingiz, ishlab chiqarishga ulaning va u yerda tezda tuzating.” Agar siz Chak Norris bo'lsangiz, bu ishlaydi. Agar yo'q bo'lsa, bitta xatoni tuzatsangiz, yana 10 ta xatoga yo'l qo'yish xavfi tug'iladi.Mana shuning uchun oldingi versiyaga qaytish amaliyoti sizga ko'p narsaga erishish imkonini beradi.
Agar biror joyda biron bir yomon narsa yuzaga kelgan bo'lsa ham, bu yomon, lekin halokatli emas. Oldingi versiyaga qaytishingiz mumkin. Agar ushbu terminologiyada uni idrok etish osonroq bo'lsa, uni zaxira deb nomlang. Siz avvalgi versiyaga qaytishingiz mumkin va foydalanuvchilar hali ham mahsulotingiz bilan ishlashlari mumkin bo'ladi va sizda yetarli bufer vaqtingiz bo'ladi. Siz tinchgina, shoshilmasdan, bularning barchasini olib, mahalliy darajada sinab ko'rishingiz, tuzatishingiz va keyin yangi versiyani yuklashingiz mumkin. Buni qilish haqiqatan ham mantiqiy.
Keling, qandaydir tarzda oldingi ikkita amaliyotni birlashtirishga harakat qilaylik. Biz Release Management deb nomlangan uchinchisini olamiz.
Klassik shaklda Uzluksiz joylashtirish haqida gapirganda, biz ombordan biron bir filialdan kod olib, uni kompilyatsiya qilishimiz va joylashtirishimiz kerakligini aytamiz. Bizda bir xil muhit bo'lsa yaxshi. Agar bizda bir nechta muhit mavjud bo'lsa, bu biz kodni har safar, hatto bir xil majburiyatdan ham tortib olishimiz kerakligini anglatadi. Biz uni har safar chiqaramiz, har safar quramiz va yangi muhitga joylashtiramiz. Birinchidan, bu vaqt, chunki agar sizda katta loyiha bo'lsa va 90-yillardan kelgan bo'lsa, unda bir necha soat davom etishi mumkin.
Bundan tashqari, yana bir qayg'u bor. Qurganingizda, hatto bir xil mashinada ham, siz bir xil manbalarni qurasiz, lekin siz hali ham ushbu mashinaning oxirgi qurish paytida bo'lgani kabi bir xil holatda ekanligiga kafolat bera olmaysiz.
Aytaylik, kimdir kelib DotNet-ni siz uchun yangiladi yoki aksincha, kimdir biror narsani o'chirishga qaror qildi. Va keyin sizda kognitiv dissonans borki, biz ikki hafta oldin ushbu majburiyatdan keyin biz qurilishni qurayotgan edik va hamma narsa yaxshi edi, lekin hozir biz qurmoqchi bo'lgan o'sha mashina, o'sha majburiyat, o'sha kod kabi ko'rinadi, lekin u ishlamayapti. . Siz bu bilan uzoq vaqt shug'ullanasiz va buni aniqlab olishingiz haqiqat emas. Hech bo'lmasa, asabingizni juda buzasiz.
Shu sababli, Relizlarni boshqarish amaliyoti artefakt ombori yoki galereya yoki kutubxona deb ataladigan qo'shimcha abstraksiyani joriy qilishni taklif qiladi. Siz uni xohlaganingizcha chaqirishingiz mumkin.
Asosiy g'oya shundan iboratki, bizda qandaydir majburiyat bo'lishi bilanoq, aytaylik, biz turli muhitlarga joylashtirishga tayyor bo'lgan filialda, biz ushbu majburiyatdan ilovalar va ushbu dastur uchun kerak bo'lgan hamma narsani yig'amiz, biz uni to'playmiz. zip arxiviga o'tkazing va uni ishonchli xotiraga saqlang. Va bu xotiradan biz istalgan vaqtda ushbu zip arxivini olishimiz mumkin.
Keyin biz uni olib, avtomatik ravishda ishlab chiqaruvchi muhitga joylashtiramiz. Biz u erda poyga qilamiz va agar hamma narsa yaxshi bo'lsa, biz sahnaga chiqamiz. Agar hamma narsa yaxshi bo'lsa, biz bir xil arxivni ishlab chiqarishga joylashtiramiz, bir xil ikkilik fayllar, aynan bir marta tuzilgan.
Bundan tashqari, bizda bunday galereya mavjud bo'lsa, u avvalgi versiyaga qaytish haqida gapirganda oxirgi slaydda ko'rib chiqilgan xavflarni hal qilishga yordam beradi. Agar siz tasodifan biror narsani notoʻgʻri oʻrnatgan boʻlsangiz, har doim ushbu galereyadan istalgan boshqa oldingi versiyani olib, uni shu muhitlarga oʻchirib tashlashingiz mumkin. Bu, agar biror narsa noto'g'ri bo'lsa, oldingi versiyaga osongina qaytish imkonini beradi.
Yana bir ajoyib amaliyot bor. Siz va men barchamiz tushunamizki, biz ilovalarimizni avvalgi versiyaga qaytarganimizda, bu bizga avvalgi versiyaning infratuzilmasi ham kerakligini anglatishi mumkin.
Virtual infratuzilma haqida gapirganda, ko'pchilik buni administratorlar o'rnatgan narsa deb o'ylashadi. Va agar sizga, aytaylik, ilovangizning yangi versiyasini sinab ko'rmoqchi bo'lgan yangi serverni olish kerak bo'lsa, administratorlar yoki devoplarga chipta yozishingiz kerak. Buning uchun devops 3 hafta vaqt oladi. Va 3 haftadan so'ng ular sizga biz siz uchun bitta yadroli, ikki gigabayt operativ xotira va DotNetsiz Windows serveriga ega virtual mashina o'rnatganimizni aytishadi. Siz aytasiz: "Ammo men DotNetni xohlardim." Ular: "Yaxshi, 3 haftadan keyin qaytib keling."
Maqsad shundaki, Infratuzilmani Kodeks amaliyoti sifatida ishlatish orqali siz virtual infratuzilmangizga boshqa resurs sifatida qarashingiz mumkin.
Ehtimol, sizlardan birortangiz DotNet-da ilovalar ishlab chiqayotgan bo'lsangiz, Entity Framework deb nomlangan kutubxona haqida eshitgan bo'lishingiz mumkin. Siz hatto Entity Framework Microsoft faol ravishda ilgari surayotgan yondashuvlardan biri ekanligini eshitgan bo'lishingiz mumkin. Ma'lumotlar bazasi bilan ishlash uchun bu Code First deb nomlangan yondashuv. Bu sizning ma'lumotlar bazasi qanday ko'rinishini xohlayotganingizni kodda tasvirlab berganingizda. Va keyin siz dasturni joylashtirasiz. U ma'lumotlar bazasiga ulanadi, qaysi jadvallar bor va qaysi jadvallar yo'qligini o'zi aniqlaydi va sizga kerak bo'lgan hamma narsani yaratadi.
Infratuzilmangiz bilan ham xuddi shunday qilishingiz mumkin. Loyiha uchun ma'lumotlar bazasi kerakmi yoki loyiha uchun Windows server kerakmi o'rtasida farq yo'q. Bu shunchaki resurs. Va siz ushbu resursni yaratishni avtomatlashtirishingiz mumkin, siz ushbu resursning konfiguratsiyasini avtomatlashtirishingiz mumkin. Shunga ko'ra, har safar qandaydir yangi kontseptsiyani, qandaydir yangi yondashuvni sinab ko'rmoqchi bo'lganingizda, devops-ga chipta yozishingiz shart emas, shunchaki o'zingiz uchun ajratilgan infratuzilmani tayyor shablonlardan, tayyor skriptlardan o'rnatishingiz va uni amalga oshirishingiz mumkin. u erda barcha tajribalaringiz. Siz buni o'chirib tashlashingiz, ba'zi natijalarni olishingiz va bu haqda qo'shimcha xabar berishingiz mumkin.
Mavjud va ayni paytda muhim bo'lgan, lekin kam odam foydalanadigan keyingi amaliyot bu Ilovalar samaradorligini monitoring qilishdir.
Ilova ishlashi monitoringi haqida faqat bitta narsani aytmoqchi edim. Ushbu amaliyotda eng muhimi nima? Ilovaning ishlashini monitoring qilish kvartirani ta'mirlash bilan bir xil bo'ladi. Bu yakuniy holat emas, bu jarayon. Siz buni muntazam ravishda qilishingiz kerak.
Yaxshi ma'noda, deyarli har bir tuzilmada Ilovalar samaradorligi monitoringini o'tkazish yaxshi bo'lar edi, garchi siz tushunganingizdek, bu har doim ham mumkin emas. Lekin, hech bo'lmaganda, har bir nashr uchun amalga oshirilishi kerak.
Nima uchun bu muhim? Chunki agar siz to'satdan ishlashning pasayishiga duch kelsangiz, unda nima uchun aniq tushunishingiz kerak. Agar sizning jamoangiz, aytaylik, ikki haftalik sprintlarga ega bo'lsa, unda kamida ikki haftada bir marta ilovangizni aniq belgilangan protsessor, operativ xotira, disklar va boshqalarga ega bo'lgan alohida serverga joylashtirishingiz kerak. Va bir xil ishlash testlarini o'tkazing. . Natijani olasiz. Oldingi sprintdan qanday o'zgarganini ko'ring.
Va agar siz pasayish bir joyda keskin tushib ketganini bilsangiz, bu so'nggi ikki hafta ichida sodir bo'lgan o'zgarishlar tufayli sodir bo'lganligini anglatadi. Bu sizga muammoni tezroq aniqlash va tuzatish imkonini beradi. Va yana, bu taxminan bir xil ko'rsatkichlar bo'lib, siz buni qanchalik muvaffaqiyatli bajarganingizni o'lchashingiz mumkin.
Keyingi amaliyotimiz Konfiguratsiyani boshqarish amaliyotidir. Buni jiddiy qabul qiladiganlar juda kam. Lekin menga ishoning, bu aslida juda jiddiy narsa.
Yaqinda kulgili bir voqea bor edi. Yigitlar oldimga kelib: “Bizga arizamizning xavfsizlik tekshiruvini o‘tkazishga yordam bering”, deyishdi. Biz uzoq vaqt birga kodni ko'rib chiqdik, ular menga dastur haqida gapirib berishdi, diagrammalar chizishdi. Va ortiqcha yoki minus hamma narsa mantiqiy, tushunarli, xavfsiz edi, lekin bitta LEKIN bor edi! Ularning manba boshqaruvida konfiguratsiya fayllari, shu jumladan IP ma'lumotlar bazasi bilan ishlab chiqarilgan, ushbu ma'lumotlar bazalariga ulanish uchun login va parollar va boshqalar mavjud edi.
Va men aytaman: "Bolalar, siz ishlab chiqarish muhitingizni xavfsizlik devori bilan yopdingiz, lekin sizda ishlab chiqarish ma'lumotlar bazasi uchun login va parol to'g'ridan-to'g'ri manba boshqaruvida mavjudligi va har qanday ishlab chiquvchi uni o'qiy olishi allaqachon katta xavfsizlik xavfi hisoblanadi. . Va sizning arizangiz kod nuqtai nazaridan qanchalik xavfsiz bo'lishidan qat'i nazar, agar siz uni manba nazoratida qoldirsangiz, siz hech qachon hech qanday tekshiruvdan o'tolmaysiz. Men bu haqda gapiryapman.
Konfiguratsiyani boshqarish. Turli muhitlarda bizda turli xil konfiguratsiyalar bo'lishi mumkin. Misol uchun, bizda QA, demo, ishlab chiqarish muhiti va boshqalar uchun ma'lumotlar bazalari uchun turli xil login va parollar bo'lishi mumkin.
Ushbu konfiguratsiyani avtomatlashtirish ham mumkin. U har doim dasturning o'zidan alohida bo'lishi kerak. Nega? Ilovani bir marta yaratganingiz uchun va undan keyin SQL serveriga falon IP yoki falon IP orqali ulanganligingiz ilovaga ahamiyat bermaydi, u xuddi shunday ishlashi kerak. Shuning uchun, agar siz to'satdan sizlardan biringiz hali ham koddagi ulanish satrini qattiq kodlashtirayotgan bo'lsa, esda tutingki, agar siz men bilan bir loyihada o'zingizni topsangiz, men sizni topaman va jazolayman. Bu har doim alohida konfiguratsiyaga joylashtiriladi, masalan, web.config.
Va bu konfiguratsiya allaqachon alohida boshqariladi, ya'ni ishlab chiquvchi va administrator bir xonaga kelib o'tirishi mumkin bo'lgan payt. Va ishlab chiquvchi shunday deyishi mumkin: “Mana, mening ilovamning ikkiliklari. Ular ishlaydi. Ilova ishlashi uchun ma'lumotlar bazasi kerak. Bu erda ikkilik faylning yonida fayl mavjud. Ushbu faylda ushbu maydon login uchun javobgardir, bu parol uchun, bu IP uchun. Uni istalgan joyda joylashtiring." Va bu admin uchun oddiy va tushunarli. U ushbu konfiguratsiyani boshqarish orqali uni haqiqatan ham istalgan joyda joylashtirishi mumkin.
Va men gaplashmoqchi bo'lgan oxirgi amaliyot - bu bulutlar bilan juda bog'liq bo'lgan amaliyot. Va agar siz bulutda ishlasangiz, u maksimal effekt beradi. Bu sizning muhitingizni avtomatik ravishda olib tashlash.
Bilaman, bu anjumanda men ishlayotgan jamoalardan bir nechta odam bor. Men ishlaydigan barcha jamoalar bilan biz ushbu amaliyotdan foydalanamiz.
Nega? Albatta, agar har bir ishlab chiquvchida 24/7 ishlaydigan virtual mashina bo'lsa, juda yaxshi bo'lardi. Lekin, ehtimol, bu siz uchun yangilikdir, ehtimol siz e'tibor bermadingiz, lekin ishlab chiquvchining o'zi 24/7 ishlamaydi. Ishlab chiquvchi odatda kuniga 8 soat ishlaydi. Ishga erta kelsa ham, u katta tushlik qiladi, shu vaqt ichida u sport zaliga boradi. Ishlab chiquvchi ushbu resurslardan foydalanganda kuniga 12 soat bo'lsin. Qonunchiligimizga ko‘ra, haftada 5 kundan 7 tasi ish kuni hisoblanadi.
Shunga ko'ra, ish kunlarida bu mashina 24 soat ishlamasligi kerak, faqat 12 soat, dam olish kunlari esa bu mashina umuman ishlamasligi kerak. Hammasi juda oddiydek tuyuladi, lekin bu erda nima deyish muhim? Ushbu oddiy amaliyotni ushbu asosiy jadvalda amalga oshirish orqali u sizga ushbu muhitlarni saqlash xarajatlarini 70% ga kamaytirishga imkon beradi, ya'ni siz o'zingizning ishlab chiqaruvchingiz, QA, demo, atrof-muhit narxini oldingiz va uni 3 ga bo'ldingiz.
Savol shundaki, qolgan pulni nima qilish kerak? Misol uchun, ishlab chiquvchilar ReSharper-ni sotib olishlari kerak, agar ular hali yo'q bo'lsa. Yoki kokteyl ziyofat qiling. Agar siz ilgari ishlab chiqaruvchi va QA o'tlagan bitta muhitga ega bo'lsangiz va tamom bo'lsa, endi siz izolyatsiya qilinadigan 3 xil muhitni yaratishingiz mumkin va odamlar bir-biriga xalaqit bermaydi.
Uzluksiz ishlash o'lchovi bilan slaydga kelsak, loyihada ma'lumotlar bazasida 1 ta yozuv mavjud bo'lsa, ikki oydan keyin bir million bo'lsa, unumdorlikni qanday taqqoslashimiz mumkin? Nima uchun va samaradorlikni o'lchash nimani anglatishini qanday tushunish mumkin?
Bu yaxshi savol, chunki siz har doim bir xil manbalarda ishlashni o'lchashingiz kerak. Ya'ni, siz yangi kodni chiqarasiz, yangi kodda ishlashni o'lchaysiz. Masalan, siz turli xil ishlash stsenariylarini sinab ko'rishingiz kerak, deylik, 1 foydalanuvchi va ma'lumotlar bazasi hajmi 000 gigabayt bo'lgan engil yukda dastur qanday ishlashini sinab ko'rmoqchisiz. Siz uni o'lchadingiz va raqamlarni oldingiz. Keyinchalik biz boshqa stsenariyni olamiz. Masalan, 5 foydalanuvchi, ma'lumotlar bazasi hajmi 5 terabayt. Biz natijalarni oldik va ularni esladik.
Bu erda nima muhim? Bu erda muhim narsa shundaki, stsenariyga, ma'lumotlar hajmiga, bir vaqtning o'zida foydalanuvchilar soniga va hokazolarga qarab, siz ma'lum cheklovlarga duch kelishingiz mumkin. Masalan, tarmoq kartasining chegarasiga yoki qattiq diskning chegarasiga yoki protsessor imkoniyatlari chegarasiga. Bu siz tushunishingiz uchun muhim bo'lgan narsa. Turli stsenariylarda siz ma'lum chegaralarga duch kelasiz. Va siz ularni urganingizda raqamlarni tushunishingiz kerak.
Biz maxsus sinov muhitida ishlashni o'lchash haqida gapiramizmi? Ya'ni, bu ishlab chiqarish emasmi?
Ha, bu ishlab chiqarish emas, bu sinov muhiti bo'lib, uni avvalgi o'lchovlar bilan taqqoslashingiz uchun har doim bir xil bo'ladi.
Tushundim rahmat!
Agar savollar bo'lmasa, biz tugatamiz deb o'ylayman. Rahmat!
Manba: www.habr.com