DevOps amaliyotlari ishlaydi. Relizni o'rnatish vaqtini 10 barobar qisqartirganimizda bunga o'zimiz amin bo'ldik. Biz VTB da ishlatadigan FIS Profile tizimida o'rnatish endi 90 emas, 10 daqiqa davom etadi. Chiqarish muddati ikki haftadan ikki kungacha qisqardi. Amalga oshirishning doimiy kamchiliklari soni deyarli minimal darajaga kamaydi. "Qo'l mehnati" dan voz kechish va sotuvchiga qaramlikni yo'qotish uchun biz tayoqchalar bilan ishlashimiz va kutilmagan echimlarni topishimiz kerak edi. Kesish ostida biz to'liq ichki rivojlanishni qanday qurganimiz haqida batafsil hikoya.
Prolog: DevOps - bu falsafa
O'tgan yil davomida biz VTBda DevOps amaliyotlarini ichki ishlab chiqish va joriy etishni tashkil etish bo'yicha ko'p ishlarni amalga oshirdik:
- Biz 12 ta tizim uchun ichki rivojlanish jarayonlarini qurdik;
- 15 ta quvur liniyasini ishga tushirdik, ulardan to‘rttasi ishlab chiqarishga keltirildi;
- Avtomatlashtirilgan 1445 ta test stsenariysi;
- Biz ichki guruhlar tomonidan tayyorlangan bir qator nashrlarni muvaffaqiyatli amalga oshirdik.
DevSecOps amaliyotlarini ishlab chiqish va joriy qilishni tashkil etishning eng qiyinlaridan biri FIS Profile tizimi - aloqador bo'lmagan DBMSdagi chakana mahsulot protsessor bo'lib chiqdi. Shunga qaramay, biz ishlanmani qura oldik, quvur liniyasini ishga tushirdik, mahsulotga alohida chiqarilmaydigan paketlarni o'rnatdik va relizlarni qanday yig'ishni o'rgandik. Vazifa oson emas, lekin qiziqarli va amalga oshirishda aniq cheklovlarsiz edi: mana bu tizim - siz ichki rivojlanishni qurishingiz kerak. Yagona shart - CD dan samarali muhitdan oldin foydalanish.
Dastlab, amalga oshirish algoritmi oddiy va tushunarli bo'lib tuyuldi:
- Biz dastlabki rivojlanish tajribasini ishlab chiqamiz va qo'pol nuqsonlarsiz kod jamoasidan maqbul sifat darajasiga erishamiz;
- Biz imkon qadar mavjud jarayonlarga integratsiyamiz;
- Kodni aniq bosqichlar o'rtasida uzatish uchun biz quvur liniyasini kesib, uning uchlaridan birini davomiga suramiz.
Bu vaqt ichida kerakli o'lchamdagi rivojlanish guruhi ko'nikmalarni rivojlantirishi va relizlarga qo'shgan hissasini maqbul darajaga oshirishi kerak. Va bu, biz vazifani bajarilgan deb hisoblashimiz mumkin.
Bu kerakli natijaga erishish uchun energiya tejamkor yo‘ldek tuyuladi: mana DevOps, mana jamoaning ishlash ko‘rsatkichlari, mana to‘plangan tajriba... Lekin amalda biz DevOps hali ham falsafa bilan bog‘liqligini yana bir tasdiqladik. , va "gitlab jarayoniga biriktirilmagan, ansible, nexus va undan keyingi ro'yxatda."
Harakatlar rejasini yana bir bor tahlil qilib, biz o'zimizda o'ziga xos autsorsing sotuvchisini qurayotganimizni angladik. Shu sababli, yuqorida tavsiflangan algoritmga jarayonni reinjiniring qilish, shuningdek, ushbu jarayonda etakchi rolga erishish uchun butun rivojlanish yo'li bo'ylab tajribani rivojlantirish qo'shildi. Eng oson variant emas, lekin bu g'oyaviy jihatdan to'g'ri rivojlanish yo'lidir.
Uyda rivojlanish qaerdan boshlanadi?
Bu ishlash uchun eng qulay tizim emas edi. Arxitektura nuqtai nazaridan, bu bitta katta relyatsion bo'lmagan ma'lumotlar bazasi bo'lib, kerak bo'lganda chaqiriladigan va qora quti printsipi asosida ishlaydigan ko'plab alohida bajariladigan ob'ektlardan (skriptlar, protseduralar, partiyalar va boshqalar) iborat edi: u so'rov va muammolarni qabul qiladi. javob. E'tiborga loyiq boshqa qiyinchiliklarga quyidagilar kiradi:
- ekzotik til (MUMPS);
- Konsol interfeysi;
- Mashhur avtomatlashtirish vositalari va ramkalar bilan integratsiyaning yo'qligi;
- Ma'lumotlar hajmi o'nlab terabaytlarda;
- Soatiga 2 milliondan ortiq operatsiyalarni yuklash;
- Ahamiyati - biznes-tanqidiy.
Shu bilan birga, biz tomonda manba kodlari ombori yo'q edi. Umuman. Hujjatlar bor edi, lekin barcha asosiy bilim va malakalar tashqi tashkilot tomonida edi.
Biz uning xususiyatlari va past taqsimotini hisobga olgan holda tizimni ishlab chiqishni deyarli noldan o'zlashtira boshladik. 2018 yil oktyabr oyida boshlangan:
- Hujjatlarni va kod yaratish asoslarini o'rgandi;
- Biz sotuvchidan olingan rivojlanish bo'yicha qisqa kursni o'rgandik;
- Dastlabki rivojlanish ko'nikmalarini o'zlashtirgan;
- Biz yangi jamoa a'zolari uchun o'quv qo'llanmasini tuzdik;
- Biz jamoani "jangovar" rejimiga kiritishga kelishib oldik;
- Kod sifatini nazorat qilish bilan muammoni hal qildi;
- Rivojlanish uchun stend tashkil qildik.
Biz uch oy davomida tajribani rivojlantirish va tizimga sho‘ng‘ish uchun vaqt sarfladik va 2019-yil boshidan ichki rivojlanish ba’zan qiyinchilik bilan, lekin ishonchli va maqsadli ravishda porloq kelajak sari harakatini boshladi.
Repository migratsiyasi va avtotestlar
Birinchi DevOps vazifasi - bu ombor. Biz tezda kirishni ta'minlashga rozi bo'ldik, lekin bir nechta filiallar modeliga o'tish va Git Flow-ni ishlab chiqish bilan bitta magistral filiali bilan hozirgi SVN-dan maqsadli Git-ga o'tish kerak edi. Shuningdek, bizda o'z infratuzilmasiga ega bo'lgan 2 ta jamoa, shuningdek, chet elda sotuvchi jamoasining bir qismi bor. Men ikkita Gits bilan yashashim va sinxronizatsiyani ta'minlashim kerak edi. Bunday vaziyatda u ikkita yomonlikning eng kichiki edi.
Repozitariyning ko'chishi bir necha bor qoldirildi, u faqat aprel oyida frontdagi hamkasblar yordamida yakunlandi. Git Flow bilan biz hamma narsani oddiy saqlashga qaror qildik va tuzatish, ishlab chiqish va chiqarish bilan klassik sxema bo'yicha qaror qildik. Ular ustadan voz kechishga qaror qilishdi (aka prod kabi). Quyida nima uchun bu variant biz uchun maqbul bo'lganini tushuntiramiz. Ikkita jamoa uchun umumiy bo'lgan sotuvchiga tegishli tashqi ombor ishchi sifatida ishlatilgan. U jadvalga muvofiq ichki ombor bilan sinxronlashtirildi. Endi Git va Gitlab yordamida jarayonlarni avtomatlashtirish mumkin edi.
Avtotestlar masalasi hayratlanarli darajada oson hal qilindi - bizga tayyor ramka taqdim etildi. Tizimning o'ziga xos xususiyatlarini hisobga olgan holda, alohida operatsiyani chaqirish biznes jarayonining tushunarli qismi bo'lib, ayni paytda birlik testi sifatida xizmat qildi. Qolgan narsa sinov ma'lumotlarini tayyorlash va skriptlarni chaqirish va natijalarni baholashning kerakli tartibini o'rnatish edi. Operatsion statistik ma'lumotlar, jarayonlarning tanqidiyligi va mavjud regressiya metodologiyasi asosida tuzilgan stsenariylar ro'yxati to'ldirilganligi sababli, avtomatik testlar paydo bo'la boshladi. Endi biz quvurni qurishni boshlashimiz mumkin.
Bu qanday edi: avtomatlashtirishdan oldingi model
Amalga oshirish jarayonining mavjud modeli alohida hikoyadir. Har bir modifikatsiya qo'lda alohida qo'shimcha o'rnatish paketi sifatida uzatildi. Keyinchalik Jira-da qo'lda ro'yxatdan o'tish va muhitlarga qo'lda o'rnatish keldi. Alohida paketlar uchun hamma narsa aniq ko'rinardi, ammo relizni tayyorlash bilan ishlar yanada murakkablashdi.
Yig'ish mustaqil ob'ektlar bo'lgan individual etkazib berish darajasida amalga oshirildi. Har qanday o'zgarish yangi etkazib berishdir. Boshqa narsalar qatorida, asosiy relizlar tarkibining 60-70 paketlariga 10-15 ta texnik versiyalar qo'shildi - nashrga biror narsa qo'shish yoki chiqarib tashlashda olingan va relizlar tashqarisidagi sotuvlardagi o'zgarishlarni aks ettiruvchi versiyalar.
Yetkazib berishlar ichidagi ob'ektlar bir-biri bilan, ayniqsa bajariladigan kodda, bir-biri bilan o'xshash edi, bu yarmidan kamroq noyob edi. O'rnatilgan kodga ham, o'rnatilishi endigina rejalashtirilgan kodga ham ko'plab bog'liqliklar mavjud edi.
Kodning kerakli versiyasini olish uchun o'rnatish tartibiga qat'iy rioya qilish kerak edi, uning davomida ob'ektlar ko'p marta, ba'zilari 10-12 marta jismoniy qayta yozildi.
Paketlar to'plamini o'rnatgandan so'ng, sozlamalarni ishga tushirish uchun qo'lda ko'rsatmalarga amal qilishim kerak edi. Chiqarish sotuvchi tomonidan yig'ilgan va o'rnatilgan. Chiqarish tarkibi deyarli amalga oshirishdan oldin aniqlangan, bu "ajratish" paketlarini yaratishga olib keldi. Natijada, ta'minotning katta qismi o'zining "ajralish" dumlari bilan chiqarilgandan tortib to chiqarilishga o'tdi.
Endi ma'lum bo'ldiki, ushbu yondashuv bilan - chiqarish jumboqini paket darajasida yig'ish - bitta asosiy filialning amaliy ma'nosi yo'q edi. Ishlab chiqarishga o'rnatish bir yarim soatdan ikki soatgacha qo'l mehnatini talab qildi. Hech bo'lmaganda o'rnatuvchi darajasida ob'ektni qayta ishlash tartibi aniqlangani yaxshi: maydonlar va tuzilmalar ular uchun ma'lumotlar va protseduralardan oldin kiritilgan. Biroq, bu faqat alohida paketda ishladi.
Ushbu yondashuvning mantiqiy natijasi ob'ektlarning egri versiyalari, keraksiz kodlar, etishmayotgan ko'rsatmalar va ob'ektlarning hisobga olinmagan o'zaro ta'siri ko'rinishidagi majburiy o'rnatish nuqsonlari bo'lib, ular chiqarilgandan keyin qizg'in tarzda yo'q qilindi.
Birinchi yangilanishlar: montaj qilish va yetkazib berish
Avtomatlashtirish kodni ushbu yo'nalish bo'ylab quvur orqali uzatishdan boshlandi:
- Tayyor etkazib berishni saqlash joyidan oling;
- Uni maxsus muhitga o'rnating;
- Avtotestlarni o'tkazish;
- O'rnatish natijasini baholang;
- Sinov buyrug'ining yon tomonidagi quyidagi quvur liniyasiga qo'ng'iroq qiling.
Keyingi quvur liniyasi Jira-da vazifani ro'yxatdan o'tkazishi va topshiriqni bajarish vaqtiga bog'liq bo'lgan tanlangan sinov tsikllariga buyruqlar tarqatilishini kutishi kerak. Trigger - ma'lum bir manzilga etkazib berishga tayyorligi haqida xat. Bu, albatta, aniq tayoq edi, lekin men bir joydan boshlashim kerak edi. 2019 yil may oyida kodni uzatish bizning muhitlarimizni tekshirish bilan boshlandi. Jarayon boshlandi, uni munosib shaklga keltirish qoldi:
- Har bir modifikatsiya alohida filialda amalga oshiriladi, bu o'rnatish paketiga mos keladi va maqsadli asosiy filialga birlashadi;
- Quvurni ishga tushirish triggeri birlashish soʻrovi orqali asosiy filialda yangi majburiyatning paydo boʻlishi boʻlib, uni korxona jamoasining texnik xodimlari yopib qoʻyadi;
- Repozitariylar har besh daqiqada bir marta sinxronlashtiriladi;
- O'rnatish paketini yig'ish boshlanadi - sotuvchidan olingan assembler yordamida.
Shundan so'ng, kodni tekshirish va uzatish, quvurni ishga tushirish va biz tomonda yig'ish uchun allaqachon mavjud qadamlar mavjud edi.
Bu variant iyul oyida ishga tushirilgan. O'tishning qiyinchiliklari sotuvchi va oldingi chiziq o'rtasida biroz norozilik tug'dirdi, ammo keyingi bir oy ichida biz barcha qo'pol qirralarni olib tashlashga va jamoalar o'rtasida jarayonni o'rnatishga muvaffaq bo'ldik. Endi bizda majburiyat va yetkazib berish bo'yicha yig'ish bor.
Avgust oyida biz quvur liniyasidan foydalangan holda ishlab chiqarish bo'yicha alohida paketni birinchi o'rnatishni yakunlashga muvaffaq bo'ldik va sentyabr oyidan boshlab, istisnosiz, alohida chiqarilmaydigan paketlarning barcha o'rnatilishi CD asbobimiz orqali amalga oshirildi. Bundan tashqari, biz sotuvchiga qaraganda kichikroq jamoa bilan ishlab chiqarish tarkibining 40 foizida ichki vazifalar ulushiga erishdik - bu aniq muvaffaqiyat. Eng jiddiy vazifa qoldi - relizni yig'ish va o'rnatish.
Yakuniy yechim: kümülatif o'rnatish paketlari
Biz sotuvchining ko'rsatmalarini skript qilish juda avtomatlashtirish ekanligini juda yaxshi tushundik; biz jarayonning o'zini qayta ko'rib chiqishimiz kerak edi. Yechim aniq edi - kerakli versiyalarning barcha ob'ektlari bilan reliz bo'limidan kümülatif ta'minotni yig'ish.
Biz kontseptsiyani isbotlashdan boshladik: biz o'tgan dastur mazmuniga ko'ra relizlar paketini qo'lda yig'dik va uni muhitimizga o'rnatdik. Hammasi amalga oshdi, kontseptsiya hayotiy bo'lib chiqdi. Keyinchalik, biz ishga tushirish sozlamalarini skriptlash va ularni majburiyatga kiritish masalasini hal qildik. Biz yangi paket tayyorladik va uni konturni yangilash doirasida sinov muhitida sinab ko'rdik. O'rnatish muvaffaqiyatli bo'ldi, garchi amalga oshirish guruhining keng doiradagi sharhlari bilan. Lekin asosiysi shundaki, bizga yig'ilishimiz bilan noyabr oyida ishlab chiqarishga kirishish huquqi berildi.
Bir oydan ko'proq vaqt qolganida, qo'lda tanlangan materiallar vaqt tugashini aniq ko'rsatdi. Ular qurilishni reliz filialidan qilishga qaror qilishdi, lekin nima uchun uni ajratish kerak? Bizda Prod-ga o'xshash dastur yo'q va mavjud filiallar yaxshi emas - juda ko'p keraksiz kodlar mavjud. Biz zudlik bilan prod-layklarni qisqartirishimiz kerak va bu uch mingdan ortiq majburiyatdir. Qo'lda yig'ish umuman variant emas. Biz mahsulotni o'rnatish jurnalidan o'tadigan va filialga majburiyatlarni to'playdigan skriptni chizdik. Uchinchi marta u to'g'ri ishladi va "fayl bilan tugatgandan" keyin filial tayyor bo'ldi.
O'rnatish paketi uchun o'z quruvchimizni yozdik va uni bir hafta ichida tugatdik. Keyin biz o'rnatuvchini tizimning asosiy funksiyasidan o'zgartirishimiz kerak edi, chunki u ochiq manba hisoblanadi. Bir qator tekshiruvlar va o'zgartirishlardan so'ng, natija muvaffaqiyatli deb topildi. Shu bilan birga, relizning tarkibi shakllandi, uni to'g'ri o'rnatish uchun sinov sxemasini ishlab chiqarish sxemasiga moslashtirish kerak edi va buning uchun alohida skript yozildi.
Tabiiyki, birinchi o'rnatish haqida juda ko'p sharhlar bor edi, lekin umuman kod ishladi. Taxminan uchinchi o'rnatishdan keyin hamma narsa yaxshi ko'rina boshladi. Tarkibni boshqarish va ob'ektlarning versiyalarini boshqarish qo'lda rejimda alohida kuzatildi, bu ushbu bosqichda juda oqlandi.
Qo'shimcha qiyinchilik e'tiborga olinishi kerak bo'lgan ko'p sonli bo'lmagan nashrlar edi. Ammo Prod-ga o'xshash filial va Rebase bilan vazifa shaffof bo'ldi.
Birinchi marta, tez va xatosiz
Biz nashrga optimistik munosabat va turli sxemalarda o'ndan ortiq muvaffaqiyatli o'rnatish bilan yondashdik. Ammo tom ma'noda belgilangan muddatdan bir kun oldin, sotuvchi qabul qilingan tarzda o'rnatishga tayyorlash bo'yicha ishni tugatmaganligi ma'lum bo'ldi. Agar biron sababga ko'ra bizning tuzilmamiz ishlamasa, relizlar buziladi. Bundan tashqari, bizning sa'y-harakatlarimiz orqali, ayniqsa, yoqimsiz. Bizda chekinishning iloji yo'q edi. Shuning uchun biz muqobil variantlarni ko'rib chiqdik, harakat rejalarini tayyorladik va o'rnatishni boshladik.
Ajablanarlisi shundaki, 800 dan ortiq ob'ektdan iborat butun nashr birinchi marta va atigi 10 daqiqada to'g'ri boshlandi. Biz xatoliklarni izlab jurnallarni tekshirish uchun bir soat vaqt sarfladik, ammo topmadik.
Ertasi kun davomida chiqish suhbatida jimlik hukm surdi: amalga oshirish bilan bog'liq muammolar, egri versiyalar yoki "nomaqbul" kod. Bu hatto qandaydir noqulay edi. Keyinchalik, ba'zi sharhlar paydo bo'ldi, ammo boshqa tizimlar va oldingi tajriba bilan solishtirganda, ularning soni va ustuvorligi sezilarli darajada past edi.
Kümülatif ta'sirning qo'shimcha ta'siri yig'ish va sinov sifatini oshirish edi. To'liq versiyaning bir nechta o'rnatilishi tufayli, qurishdagi nuqsonlar va joylashtirish xatolari o'z vaqtida aniqlandi. To'liq reliz konfiguratsiyalarida sinov qo'shimcha o'rnatish paytida paydo bo'lmagan ob'ektlarning o'zaro ta'siridagi nuqsonlarni qo'shimcha ravishda aniqlash imkonini berdi. Bu, albatta, muvaffaqiyatli bo'ldi, ayniqsa nashrga bizning 57% hissamizni hisobga olsak.
Natijalar va xulosalar
Bir yildan kamroq vaqt ichida biz quyidagilarga erishdik:
- Ekzotik tizim yordamida to'liq huquqli ichki rivojlanishni qurish;
- Kritik sotuvchiga qaramlikni yo'q qilish;
- Juda yoqimsiz meros uchun CI/CD-ni ishga tushiring;
- Amalga oshirish jarayonlarini yangi texnik darajaga ko'tarish;
- Joylashtirish vaqtini sezilarli darajada qisqartirish;
- Amalga oshirishdagi xatolar sonini sezilarli darajada kamaytirish;
- O'zingizni rivojlanish bo'yicha yetakchi mutaxassis sifatida ishonch bilan e'lon qiling.
Albatta, ta'riflanganlarning aksariyati ahmoqona ko'rinadi, ammo bu tizimning xususiyatlari va unda mavjud bo'lgan jarayon cheklovlari. Ayni paytda o'zgarishlar IS Profile mahsulotlari va xizmatlariga (bosh hisoblar, plastik kartochkalar, omonat hisobvaraqlari, eskrov, naqd kreditlar) ta'sir ko'rsatdi, ammo potentsial yondashuv DevOps amaliyotlarini joriy etish vazifasi qo'yilgan har qanday ISga qo'llanilishi mumkin. Kümülatif modelni ko'plab etkazib berishlardan keyingi amalga oshirish (shu jumladan, chiqarilmaydiganlar) uchun xavfsiz tarzda takrorlash mumkin.
Manba: www.habr.com