Mikroservis arxitekturasini rivojlantirish bilan bog'liq loyihalarda CI/CD yoqimli imkoniyat toifasidan shoshilinch zarurat toifasiga o'tadi. Avtomatlashtirilgan test uzluksiz integratsiyaning ajralmas qismi bo'lib, unga malakali yondashuv jamoaga oila va do'stlar bilan ko'plab yoqimli kechalarni taqdim etishi mumkin. Aks holda, loyiha hech qachon tugamaslik xavfini tug'diradi.
Soxta ob'ektlar bilan birlik testlari bilan butun mikroservis kodini qamrab olish mumkin, ammo bu muammoni qisman hal qiladi va ko'plab savollar va qiyinchiliklarni qoldiradi, ayniqsa ma'lumotlar bilan ishlashni sinab ko'rishda. Har doimgidek, eng dolzarb bo'lganlar relyatsion ma'lumotlar bazasida ma'lumotlarning muvofiqligini tekshirish, bulut xizmatlari bilan ishlashni sinovdan o'tkazish va soxta ob'ektlarni yozishda noto'g'ri taxminlar qilishdir.
Bularning barchasini va yana bir oz narsani Docker konteynerida butun mikroservisni sinab ko'rish orqali hal qilish mumkin. Sinovlarning haqiqiyligini ta'minlashning shubhasiz afzalligi shundaki, ishlab chiqarishga kiradigan bir xil Docker tasvirlari sinovdan o'tkaziladi.
Ushbu yondashuvni avtomatlashtirish bir qator muammolarni keltirib chiqaradi, ularning echimi quyida tavsiflanadi:
- bir xil docker xostidagi parallel vazifalarning ziddiyatlari;
- test takrorlash paytida ma'lumotlar bazasida identifikator ziddiyatlari;
- mikroservislar tayyor bo'lishini kutish;
- jurnallarni tashqi tizimlarga birlashtirish va chiqarish;
- chiquvchi HTTP so'rovlarini sinovdan o'tkazish;
- veb-rozetka testi (SignalR yordamida);
- OAuth autentifikatsiyasi va avtorizatsiyasini sinovdan o'tkazish.
Ushbu maqolaga asoslanadi SECR 2019 da. Shunday qilib, o'qishga dangasalar uchun, .
Ushbu maqolada men sizga sinovdan o'tayotgan xizmatni, ma'lumotlar bazasini va Docker-da Amazon AWS xizmatlarini ishga tushirish uchun skriptdan qanday foydalanishni, keyin Postman-da testlarni va ular tugallangandan so'ng yaratilgan konteynerlarni to'xtatish va o'chirishni aytib beraman. Sinovlar har safar kod o'zgarganda amalga oshiriladi. Shunday qilib, biz har bir versiya AWS maʼlumotlar bazasi va xizmatlari bilan toʻgʻri ishlashiga ishonch hosil qilamiz.
Xuddi shu skript ishlab chiquvchilarning o'zlari tomonidan Windows ish stollarida va Linux ostidagi Gitlab CI serveri tomonidan boshqariladi.
To‘g‘rirog‘i, yangi testlarni joriy qilish ishlab chiquvchining kompyuterida ham, testlar topshiriq bo‘yicha bajariladigan serverda ham qo‘shimcha vositalarni o‘rnatishni talab qilmasligi kerak.Docker bu muammoni hal qiladi.
Sinov quyidagi sabablarga ko'ra mahalliy serverda ishlashi kerak:
- Tarmoq hech qachon to'liq ishonchli emas. Minglab so'rovlardan bittasi muvaffaqiyatsiz bo'lishi mumkin;
Bunday holda, avtomatik sinov ishlamaydi, ish to'xtaydi va siz sababni jurnallardan izlashingiz kerak bo'ladi; - Ba'zi uchinchi tomon xizmatlari tomonidan juda tez-tez so'rovlarga ruxsat berilmaydi.
Bundan tashqari, stenddan foydalanish istalmagan, chunki:
- Stendni nafaqat undagi yomon kod, balki to'g'ri kod qayta ishlay olmaydigan ma'lumotlar ham buzishi mumkin;
- Sinov davomida kiritilgan barcha o'zgarishlarni qaytarishga qanchalik urinmaylik, nimadir noto'g'ri ketishi mumkin (aks holda, nima uchun sinov?).
Loyiha va jarayonni tashkil etish haqida
Kompaniyamiz Amazon AWS bulutida Docker-da ishlaydigan mikroservis veb-ilovasini ishlab chiqdi. Loyihada birlik testlari allaqachon qo'llanilgan, lekin ko'pincha birlik testlari aniqlamagan xatolar yuzaga keldi. Ma'lumotlar bazasi va Amazon xizmatlari bilan birga butun mikroservisni sinab ko'rish kerak edi.
Loyiha standart uzluksiz integratsiya jarayonidan foydalanadi, bu mikroservisni har bir majburiyat bilan sinab ko'rishni o'z ichiga oladi. Vazifani tayinlagandan so'ng, ishlab chiquvchi mikroservisga o'zgartirishlar kiritadi, uni qo'lda sinab ko'radi va barcha mavjud avtomatlashtirilgan testlarni o'tkazadi. Agar kerak bo'lsa, ishlab chiquvchi testlarni o'zgartiradi. Hech qanday muammo topilmasa, ushbu masala bo'limiga majburiyat beriladi. Har bir topshiriqdan so'ng testlar serverda avtomatik ravishda ishga tushiriladi. Muvaffaqiyatli ko'rib chiqilgandan so'ng umumiy filialga birlashish va unda avtomatik testlarni ishga tushirish sodir bo'ladi. Agar umumiy filialdagi testlar o'tsa, xizmat Amazon Elastic Container Service (skameyka)dagi sinov muhitida avtomatik ravishda yangilanadi. Stend barcha ishlab chiquvchilar va sinovchilar uchun zarur va uni buzish tavsiya etilmaydi. Ushbu muhitdagi sinovchilar qo'lda testlarni amalga oshirish orqali tuzatish yoki yangi xususiyatni tekshiradilar.
Loyiha arxitekturasi
Ilova o'ndan ortiq xizmatlardan iborat. Ulardan ba'zilari .NET Core da, ba'zilari esa NodeJs da yozilgan. Har bir xizmat Amazon Elastik konteyner xizmatidagi Docker konteynerida ishlaydi. Har birida o'z Postgres ma'lumotlar bazasi mavjud, ba'zilarida Redis ham mavjud. Umumiy ma'lumotlar bazalari mavjud emas. Agar bir nechta xizmatlarga bir xil ma'lumotlar kerak bo'lsa, u holda bu ma'lumotlar o'zgarganda ushbu xizmatlarning har biriga SNS (Simple Notification Service) va SQS (Amazon Simple Queue Service) orqali uzatiladi va xizmatlar ularni alohida ma'lumotlar bazalarida saqlaydi.
SQS va SNS
SQS HTTPS protokoli yordamida xabarlarni navbatga qo'yish va navbatdagi xabarlarni o'qish imkonini beradi.
Agar bir nechta xizmatlar bitta navbatni o'qisa, har bir xabar ulardan faqat bittasiga keladi. Bu yukni ular o'rtasida taqsimlash uchun bir xil xizmatning bir nechta nusxalarini ishga tushirishda foydalidir.
Agar siz har bir xabar bir nechta xizmatlarga yetkazilishini istasangiz, har bir qabul qiluvchining o'z navbati bo'lishi kerak va xabarlarni bir nechta navbatga ko'paytirish uchun SNS kerak bo'ladi.
SNS-da siz mavzu yaratasiz va unga obuna bo'lasiz, masalan, SQS navbati. Mavzuga xabar yuborishingiz mumkin. Bunday holda, xabar ushbu mavzuga obuna bo'lgan har bir navbatga yuboriladi. SNS xabarlarni o'qish usuliga ega emas. Agar disk raskadrovka yoki test paytida siz SNS-ga nima yuborilganligini bilib olishingiz kerak bo'lsa, siz SQS navbatini yaratishingiz, uni kerakli mavzuga obuna bo'lishingiz va navbatni o'qishingiz mumkin.
API shlyuzi
Aksariyat xizmatlarga Internetdan to'g'ridan-to'g'ri kirish mumkin emas. Kirish API Gateway orqali amalga oshiriladi, u kirish huquqlarini tekshiradi. Bu ham bizning xizmatimiz va buning uchun ham sinovlar mavjud.
Haqiqiy vaqtda bildirishnomalar
Ilova foydalanadi foydalanuvchiga real vaqtda bildirishnomalarni ko'rsatish uchun. Bu xabarnoma xizmatida amalga oshiriladi. Unga to'g'ridan-to'g'ri Internetdan kirish mumkin va o'zi OAuth bilan ishlaydi, chunki OAuth va bildirishnoma xizmatini birlashtirish bilan solishtirganda Gateway-ga veb-rozetkalarni qo'llab-quvvatlash amaliy bo'lmagan.
Taniqli sinov yondashuvi
Birlik testlari ma'lumotlar bazasi kabi narsalarni soxta ob'ektlar bilan almashtiradi. Agar mikroservis, masalan, jadvalda tashqi kalit bilan yozuv yaratishga harakat qilsa va bu kalit tomonidan havola qilingan yozuv mavjud bo'lmasa, so'rovni to'ldirib bo'lmaydi. Birlik testlari buni aniqlay olmaydi.
В Xotiradagi ma'lumotlar bazasidan foydalanish va soxta ob'ektlarni amalga oshirish taklif etiladi.
Xotiradagi ma'lumotlar bazasi Entity Framework tomonidan qo'llab-quvvatlanadigan DBMSlardan biridir. U sinov uchun maxsus yaratilgan. Bunday ma'lumotlar bazasidagi ma'lumotlar faqat undan foydalanish jarayoni tugaguncha saqlanadi. Bu jadvallarni yaratishni talab qilmaydi va ma'lumotlar yaxlitligini tekshirmaydi.
Soxta ob'ektlar o'zlari almashtirayotgan sinfni faqat test ishlab chiquvchisi uning qanday ishlashini tushunadigan darajada modellashtiradi.
Sinovni ishga tushirganingizda Postgres-ni avtomatik ravishda ishga tushirish va migratsiyani amalga oshirish uchun qanday qilib Microsoft maqolasida ko'rsatilmagan. Mening yechimim buni amalga oshiradi va qo'shimcha ravishda mikroservisning o'ziga testlar uchun maxsus kod qo'shmaydi.
Keling, yechimga o'tamiz
Rivojlanish jarayonida birlik testlari barcha muammolarni o'z vaqtida topish uchun etarli emasligi aniq bo'ldi, shuning uchun bu masalaga boshqa tomondan yondashishga qaror qilindi.
Sinov muhitini o'rnatish
Birinchi vazifa sinov muhitini joylashtirishdir. Mikroservisni ishga tushirish uchun zarur qadamlar:
- Mahalliy muhit uchun sinovdan o'tayotgan xizmatni sozlang, muhit o'zgaruvchilarida ma'lumotlar bazasi va AWS ga ulanish tafsilotlarini belgilang;
- Postgres-ni ishga tushiring va Liquibase-ni ishga tushirish orqali migratsiyani amalga oshiring.
Relyatsion DBMSlarda ma'lumotlar bazasiga ma'lumotlarni yozishdan oldin ma'lumotlar sxemasini, boshqacha aytganda, jadvallarni yaratish kerak. Ilovani yangilashda jadvallar yangi versiyada qo'llaniladigan shaklga keltirilishi kerak va afzalroq ma'lumotlarni yo'qotmasdan. Bu migratsiya deb ataladi. Dastlab bo'sh ma'lumotlar bazasida jadvallarni yaratish - bu migratsiyaning alohida holati. Migratsiya ilovaning o'ziga o'rnatilishi mumkin. .NET ham, NodeJS ham migratsiya ramkalariga ega. Bizning holatda, xavfsizlik nuqtai nazaridan, mikroservislar ma'lumotlar sxemasini o'zgartirish huquqidan mahrum bo'lib, ko'chirish Liquibase yordamida amalga oshiriladi. - Amazon LocalStack-ni ishga tushiring. Bu uyda ishlash uchun AWS xizmatlarini amalga oshirish. Docker Hub-da LocalStack uchun tayyor tasvir mavjud.
- LocalStack-da kerakli ob'ektlarni yaratish uchun skriptni ishga tushiring. Shell skriptlari AWS CLI dan foydalanadi.
Loyihani sinovdan o'tkazish uchun foydalaniladi . U ilgari mavjud edi, lekin u qo'lda ishga tushirildi va stendda allaqachon o'rnatilgan dasturni sinab ko'rdi. Ushbu vosita o'zboshimchalik bilan HTTP(S) so'rovlarini yuborish va javoblar kutilganlarga mos kelishini tekshirish imkonini beradi. So'rovlar to'plamga birlashtiriladi va butun to'plam ishga tushirilishi mumkin.
Avtomatik test qanday ishlaydi?
Sinov paytida Docker-da hamma narsa ishlaydi: sinovdan o'tayotgan xizmat, Postgres, migratsiya vositasi va Postman, aniqrog'i uning konsol versiyasi - Newman.
Docker bir qator muammolarni hal qiladi:
- Xost konfiguratsiyasidan mustaqillik;
- Bog'liqlarni o'rnatish: Docker rasmlarni Docker Hub'dan yuklaydi;
- Tizimni asl holatiga qaytarish: shunchaki idishlarni olib tashlash.
Docker-kompozitsiya konteynerlarni Internetdan ajratilgan virtual tarmoqqa birlashtiradi, unda konteynerlar domen nomlari bo'yicha bir-birini topadi.
Sinov qobiq skripti tomonidan boshqariladi. Testni Windows-da o'tkazish uchun biz git-bash-dan foydalanamiz. Shunday qilib, Windows va Linux uchun bitta skript etarli. Git va Docker loyihadagi barcha ishlab chiquvchilar tomonidan o'rnatiladi. Git-ni Windows-ga o'rnatishda git-bash o'rnatiladi, shuning uchun hamma ham shunday bo'ladi.
Skript quyidagi amallarni bajaradi:
- Docker tasvirlarini yaratish
docker-compose build - Ma'lumotlar bazasini va LocalStackni ishga tushirish
docker-compose up -d <контейнер> - Ma'lumotlar bazasini ko'chirish va LocalStackni tayyorlash
docker-compose run <контейнер> - Sinov ostida xizmat ishga tushirilmoqda
docker-compose up -d <сервис> - Sinovni o'tkazish (Nyuman)
- Barcha konteynerlarni to'xtatish
docker-compose down - Natijalarni Slack-da joylashtirish
Bizda yashil belgi yoki qizil xoch va jurnalga havola bo'lgan xabarlar o'tadigan suhbatimiz bor.
Quyidagi Docker tasvirlari ushbu bosqichlarda ishtirok etadi:
- Sinov qilinayotgan xizmat ishlab chiqarish bilan bir xil tasvirdir. Sinov uchun konfiguratsiya muhit o'zgaruvchilari orqali amalga oshiriladi.
- Postgres, Redis va LocalStack uchun Docker Hub-dan tayyor tasvirlar ishlatiladi. Bundan tashqari, Liquibase va Newman uchun tayyor tasvirlar mavjud. Biz o'zimiznikini ularning skeletiga quramiz va u erda fayllarimizni qo'shamiz.
- LocalStack-ni tayyorlash uchun siz tayyor AWS CLI tasviridan foydalanasiz va unga asoslangan skriptni o'z ichiga olgan tasvirni yaratasiz.
Foydalanish , faqat konteynerga fayllar qo'shish uchun Docker tasvirini yaratishingiz shart emas. Biroq, hajmlar bizning muhitimizga mos kelmaydi, chunki Gitlab CI vazifalari konteynerlarda ishlaydi. Siz Docker-ni bunday konteynerdan boshqarishingiz mumkin, lekin jildlar boshqa konteynerdan emas, faqat xost tizimidagi papkalarni o'rnatadi.
Siz duch kelishi mumkin bo'lgan muammolar
Tayyorlikni kutish
Xizmatga ega konteyner ishlayotgan bo'lsa, bu uning ulanishlarni qabul qilishga tayyorligini anglatmaydi. Ulanish davom etguncha kutishingiz kerak.
Bu muammo ba'zan skript yordamida hal qilinadi , bu TCP ulanishini o'rnatish imkoniyatini kutadi. Biroq, LocalStack 502 Bad Gateway xatosini berishi mumkin. Bundan tashqari, u ko'plab xizmatlardan iborat bo'lib, ulardan biri tayyor bo'lsa, bu boshqalar haqida hech narsa demaydi.
qaror: SQS va SNS dan 200 ta javobni kutuvchi LocalStack provayder skriptlari.
Parallel vazifalar to'qnashuvlari
Bitta Docker xostida bir vaqtning o'zida bir nechta testlar ishlashi mumkin, shuning uchun konteyner va tarmoq nomlari noyob bo'lishi kerak. Bundan tashqari, bir xil xizmatning turli tarmoqlaridagi testlar ham bir vaqtning o'zida ishlashi mumkin, shuning uchun har bir tuzilgan faylga ularning nomlarini yozish etarli emas.
qaror: Skript COMPOSE_PROJECT_NAME o‘zgaruvchisini noyob qiymatga o‘rnatadi.
Windows xususiyatlari
Windows-da Docker-dan foydalanganda men bir nechta narsalarni ta'kidlamoqchiman, chunki bu tajribalar nima uchun xatolar yuzaga kelishini tushunish uchun muhimdir.
- Konteynerdagi qobiq skriptlari Linux qator oxiriga ega bo'lishi kerak.
Shell CR belgisi sintaktik xatodir. Xato xabaridan shunday ekanligini aytish qiyin. Windows-da bunday skriptlarni tahrirlashda sizga tegishli matn muharriri kerak bo'ladi. Bundan tashqari, versiyani boshqarish tizimi to'g'ri tuzilgan bo'lishi kerak.
Git shunday tuzilgan:
git config core.autocrlf input- Git-bash standart Linux papkalarini taqlid qiladi va exe faylini chaqirganda (shu jumladan docker.exe) mutlaq Linux yo'llarini Windows yo'llari bilan almashtiradi. Biroq, bu mahalliy mashinada bo'lmagan yo'llar (yoki konteynerdagi yo'llar) uchun mantiqiy emas. Bu xatti-harakatni o'chirib bo'lmaydi.
qaror: yoʻl boshiga qoʻshimcha chiziq qoʻshing: /bin oʻrniga //bin. Linux bunday yo'llarni tushunadi; buning uchun bir nechta slashlar bitta bilan bir xil. Ammo git-bash bunday yo'llarni tanimaydi va ularni aylantirishga harakat qilmaydi.
Jurnal chiqishi
Sinovlarni o'tkazayotganda men Nyuman va sinovdan o'tayotgan xizmatning jurnallarini ko'rishni xohlayman. Ushbu jurnallarning hodisalari bir-biriga bog'langanligi sababli, ularni bitta konsolda birlashtirish ikkita alohida faylga qaraganda ancha qulayroqdir. Newman orqali ishga tushiriladi docker-compose ishga tushirish, va shuning uchun uning chiqishi konsolda tugaydi. Qolgan narsa, xizmatning chiqishi ham u erga borishiga ishonch hosil qilishdir.
Asl yechim qilish edi docker-tuzish bayroq yo'q -d, lekin qobiq imkoniyatlaridan foydalanib, ushbu jarayonni fonga yuboring:
docker-compose up <service> &Bu Docker-dan uchinchi tomon xizmatiga jurnallarni yuborish zarur bo'lgunga qadar ishladi. docker-tuzish jurnallarni konsolga chiqarishni to'xtatdi. Biroq, jamoa ishladi docker biriktirma.
qaror:
docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &Test takrorlash paytida identifikator ziddiyatlari
Sinovlar bir necha marta takrorlanadi. Ma'lumotlar bazasi tozalanmagan. Ma'lumotlar bazasidagi yozuvlar noyob identifikatorlarga ega. Agar so'rovlarda aniq identifikatorlarni yozsak, ikkinchi iteratsiyada biz ziddiyatga duch kelamiz.
Bunga yo'l qo'ymaslik uchun identifikatorlar noyob bo'lishi kerak yoki test tomonidan yaratilgan barcha ob'ektlar o'chirilishi kerak. Ba'zi ob'ektlarni talablar tufayli o'chirib bo'lmaydi.
qaror: Postman skriptlari yordamida GUID yaratish.
var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);Keyin so'rovdagi belgidan foydalaning {{myUUID}}, bu o'zgaruvchining qiymati bilan almashtiriladi.
LocalStack orqali hamkorlik
Agar sinovdan o'tkazilayotgan xizmat SQS navbatini o'qisa yoki yozsa, buni tekshirish uchun testning o'zi ham ushbu navbat bilan ishlashi kerak.
qaror: Postmandan LocalStack-ga so'rovlar.
AWS xizmatlari API hujjatlashtirilgan boʻlib, soʻrovlarni SDKsiz amalga oshirish imkonini beradi.
Agar xizmat navbatga yozsa, biz uni o'qiymiz va xabarning mazmunini tekshiramiz.
Agar xizmat SNS-ga xabarlarni yuborsa, tayyorgarlik bosqichida LocalStack ham navbat yaratadi va ushbu SNS mavzusiga obuna bo'ladi. Keyin hamma narsa yuqorida tavsiflangan narsaga tushadi.
Agar xizmat navbatdagi xabarni o'qishi kerak bo'lsa, oldingi test bosqichida biz ushbu xabarni navbatga yozamiz.
Sinov ostidagi mikroservisdan kelib chiqqan HTTP so'rovlarini sinab ko'rish
Ba'zi xizmatlar HTTP orqali AWSdan boshqa narsa bilan ishlaydi va ba'zi AWS xususiyatlari LocalStack-da amalga oshirilmaydi.
qaror: bu holatlarda yordam berishi mumkin , unda tayyor tasvir mavjud . Kutilayotgan so'rovlar va ularga javoblar HTTP so'rovi orqali sozlanadi. API hujjatlashtirilgan, shuning uchun biz Postmandan so'rovlar qilamiz.
OAuth autentifikatsiyasi va avtorizatsiyasini sinab ko'rish
Biz OAuth va dan foydalanamiz . Sinov mahalliy sifatida ishga tushirishimiz mumkin bo'lgan OAuth provayderini talab qiladi.
Xizmat va OAuth provayderi o'rtasidagi barcha o'zaro aloqalar ikkita so'rovga to'g'ri keladi: birinchidan, konfiguratsiya so'raladi. /.yaxshi ma'lum/openid-konfiguratsiya, so'ngra umumiy kalit (JWKS) konfiguratsiyadagi manzilda so'raladi. Bularning barchasi statik tarkibdir.
qaror: Bizning test OAuth provayderimiz statik kontent serveri va undagi ikkita fayldir. Token bir marta ishlab chiqariladi va Gitga topshiriladi.
SignalR testining xususiyatlari
Pochtachi veb-rozetkalar bilan ishlamaydi. SignalRni sinab ko'rish uchun maxsus vosita yaratilgan.
SignalR mijozi shunchaki brauzer emas. Buning uchun .NET Core ostida mijozlar kutubxonasi mavjud. .NET Core-da yozilgan mijoz ulanishni o'rnatadi, autentifikatsiya qilinadi va ma'lum bir xabarlar ketma-ketligini kutadi. Agar kutilmagan xabar olinsa yoki aloqa uzilib qolsa, mijoz 1 kod bilan chiqadi. Agar oxirgi kutilgan xabar qabul qilinsa, mijoz 0 kodi bilan chiqadi.
Nyuman mijoz bilan bir vaqtda ishlaydi. Xabarlar ularga muhtoj bo'lgan har bir kishiga yetkazilishini tekshirish uchun bir nechta mijozlar ishga tushiriladi.
Bir nechta mijozlarni ishga tushirish uchun opsiyadan foydalaning --miqyosi docker-compose buyruq satrida.
Ishlashdan oldin, Postman skripti barcha mijozlar ulanishlarni o'rnatishini kutadi.
Biz allaqachon ulanishni kutish muammosiga duch keldik. Ammo serverlar bor edi va bu erda mijoz. Boshqa yondashuv kerak.
qaror: konteynerdagi mijoz mexanizmdan foydalanadi xostdagi skriptni uning holati haqida xabardor qilish. Ulanish o'rnatilishi bilan mijoz ma'lum bir yo'lda fayl yaratadi, aytaylik /healthcheck. Docker faylidagi HealthCheck skripti quyidagicha ko'rinadi:
HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fikomanda docker tekshiruvi Konteyner uchun normal holat, salomatlik holati va chiqish kodini ko'rsatadi.
Nyuman tugatgandan so'ng, skript mijoz bilan barcha konteynerlar 0 kodi bilan tugatilganligini tekshiradi.
Baxt mavjud
Yuqorida tavsiflangan qiyinchiliklarni engib o'tganimizdan so'ng, bizda barqaror ishlaydigan testlar to'plami bor edi. Sinovlarda har bir xizmat ma'lumotlar bazasi va Amazon LocalStack bilan o'zaro aloqada bo'lgan yagona birlik sifatida ishlaydi.
Ushbu testlar 30 dan ortiq ishlab chiquvchilar jamoasini tez-tez joylashtiriladigan 10 dan ortiq mikroservislarning murakkab o'zaro ta'siri bilan dasturdagi xatolardan himoya qiladi.
Manba: www.habr.com