AI yordamida deploy tekshiruvlarini amalga oshirish

1. Asosiy ma’lumotlar

Devlime uchta muhitda — ishlab chiqish, staging va production — ishlaydi va ularni boshqaradigan ikkita GitOps repozitoriyasi mavjud. Qaysi muhit yangilanayotganidan qat’i nazar, deploydan oldin ham, keyin ham bir xil tekshiruvlar amalga oshiriladi. Jumladan, bu safar nimalar deploy qilinayotgani, ma’lumotlar bazasida o‘zgarishlar bor-yo‘qligi va ular yo‘riqnomalarga muvofiq yozilgan-yozilmagani, xizmatlar o‘rtasida havola qilinayotgan kutubxona versiyalari mos kelmayotgani va commit qilinmagan yoki push qilinmagan o‘zgarishlar bor-yo‘qligi tekshiriladi.

Tekshiruvlar yakunlangach, deploy tafsilotlarini tartibga solamiz. Staging muhitiga deploy qilganimizdan darhol so‘ng ularni jamoa ichida, jamoa tekshirishi kerak bo‘lgan bandlar bilan birga ulashamiz. Testdan o‘tkazib, tuzatishlar kiritgach, production muhitiga deploy qilamiz va yig‘ilgan tafsilotlarni foydalanuvchilarga e’lon qilamiz. Production deployi hali o‘tish bosqichida, shuning uchun yana bir qo‘shimcha qadam mavjud: staging sozlamalarini production sozlamalari bilan solishtirgan holda ko‘chirish.

Bu tekshiruvlar va tashkiliy vazifalar qiyin emas. Biroq bandlar ko‘p, ulardan bittasini o‘tkazib yuborish darhol incidentga olib kelishi mumkin va ular har bir deployda takrorlanadi. VoCga tezkor javob berish uchun deploylar har kuni amalga oshirila boshlagach, bu takroriy ish kundalik vazifaga aylandi. Jamoa ishlab chiqish uchun allaqachon Claude Code va Cowork’dan foydalanadi, platforma jamoasida esa Vizend agent hub deb nomlangan jamoaviy harness mavjud. Biroq hub ishlab chiqish kontekstini saqlash uchun mo‘ljallangan, shu sababli odam ishtirokisiz bajarilishi kerak bo‘lgan deploy tekshiruvlari kabi operatsion jarayonlar uchun boshqa sozlama kerak edi. Bu jarayonning o‘zi ham o‘tish bosqichida bo‘lgani uchun, keng qamrovli yechim yaratmaslikka va faqat zarur bo‘lganichaUshbu maqolada dastlabki sozlama, uni takomillashtirish vaqti kelganini ko‘rsatgan signal hamda undan keyingi yaxshilanishlar yoritiladi.

1-rasm. Devlime deploy sikli. Quyidagi nuqtali ramka AIga topshirilgan vazifalarni ko‘rsatadi.

2. Texnologiyalarni tanlash asoslari

Ushbu jadval Claude Code rasmiy hujjatlaridagi “Extend Claude Code” va “Run prompts on a schedule” bo‘limlarida keltirilgan bandlarni qatlamlarga ajratib qayta tartiblaydi. Joriy etish vaqti haqidagi ifodalar hujjatlardan olingan, L1–L7 raqamlarini esa tushuntirish qulay bo‘lishi uchun men berdim.

Yetti qatlamdan dastlab foydalanganlarimiz L2 skills va L5 scheduled tasks bo‘ldi. Bu qaror uchun uchta mezon mavjud edi.

Birinchidan, hujjatlarda ko‘rsatilgan joriy etish vaqtiga amal qildik.Amalda duch kelgan triggerlar “bir xil jarayonni uchinchi marta tushuntirish” va “har bir deployda takrorlanadigan tekshiruvlar” bo‘ldi. “Har safar majburiy bajarilishi kerak bo‘lgan qoida” haqidagi hook triggerini esa jarayonni bir necha marta bajarganimizdan keyingina aniqlashimiz mumkin edi.

Ikkinchidan, bekor qilib bo‘lmaydigan amallarni odamlar bajaradi.Merge, commit, push, tag va production muhitidagi o‘zgarishlarni jamoa tamoyillariga muvofiq odamlar boshqaradi, shuning uchun “mustaqil ravishda bajarilishi mumkin bo‘lgan ishlar” doirasi tabiiy ravishda belgilandi. Bu doiraga commitdan oldingi bosqichgacha bo‘lgan tekshiruv, hujjatlashtirish va fayllarni o‘zgartirish ishlari kiradi.

Uchinchidan, ko‘lamga moslashtirdik.Hozirda bu tekshiruvlarni faqat men bajaryapman va jarayon o‘tish bosqichida. Bir kishi foydalanadigan o‘tish jarayoniga plugin versiyalarini boshqarish va evalni birinchi bo‘lib joriy etish to‘g‘ri tartib bo‘lmas edi. Buning o‘rniga jarayonni keyinchalik ko‘chirish mumkin bo‘lishi uchun uni skill faylida to‘liq yozdik va scheduled promptni skillni chaqiradigan qilib tuzdik.

Rejalashtirish usulini ham xuddi shu mezonlar asosida tanladik. Claude Code hujjatlarida uchta usul tasvirlangan va biz Desktop scheduled tasks (Cowork) usulini tanladik.

Cloud Routines eng qulay variant, ammo repository ichki GitLab’imizda joylashgan. Shu sababli hisob ma’lumotlarini bulut sessiyasida saqlashimiz kerak bo‘lardi va hozircha bu konfiguratsiyani sozlamaslikka qaror qildik. Ish stolidagi vazifalar kompyuterimga ulangan jildni yangi sessiyaga ulaydi va uni ishga tushiradi, repository yangilanishini (fetch) esa bajarilishdan oldin men amalga oshiraman.

Bajarilish vaqtini belgilamaganimizning yana bir sababi — deploylar muntazam emas. Hozircha ular kundalik ishlarga yaqin, barqarorlashgandan so‘ng esa rejalashtirilgan deploylar hotfixlar bilan aralashadi. Har ikkala holatda ham boshlanish sharti vaqt emas, balki “yangilanish yakunlandi” hodisasidir. Shuning uchun ikkala vazifa ham cron’ni bo‘sh qoldiradi va ishga tushirish tugmasini biror kishi bosadi.

3. Dastlabki konfiguratsiya

Dastlabki konfiguratsiya ikkita skill va ikkita rejalashtirilgan vazifadan iborat.

Skill fayllarida yozganlarim protseduradan ko‘ra ko‘proq mulohaza yuritishga taalluqli edi. Tekshiruvlar tartibi hamma joyda bir xil, ammo qaysi qiymatlarni o‘zgartirmaslik kerakligi, nimani tarjima qilmaslik va uni qayerdan topish kerakligi, shuningdek tafovut haqida qanday xabar berish kerakligi faqat bizning muhitimizga tegishli. Masalan, staging gitops’dagi katalog nomi ham prd, shuning uchun uni katalog emas, repository sifatida ajratib ko‘rsatish kerak; yoki ekran nomlari repository’da emas, lingo label’laridan olinadi, shu bois ularni tarjima qilmasdan, label’lardan topish kerak. Bu qarorlarni fayllarga yozib qo‘yish yangi sessiyaga har safar bir xil mezonlar asosida tekshiruv o‘tkazish imkonini beradi.

Amal oddiy. Repository’ni yangilang va ishga tushirish tugmasini bosing; yangi sessiya skill’larni o‘qiydi, o‘zgarish qamrovini, DB o‘zgarishlarini va versiyalar mosligini tekshiradi hamda hisobot va e’lon loyihasini qoldiradi. Men hisobotni o‘qib, faqat qaror talab qiladigan bandlarni tanlayman. Dastlab katta konfiguratsiya yaratmaganimiz ataylab qilingan edi. Biroq uni bir necha marta ishga tushirgach, bu konfiguratsiya qanchalik bardosh bera olishi va qayerlarini tuzatish kerakligi asta-sekin ayon bo‘la boshladi.

4. Tuzatish vaqti kelganini ko‘rsatuvchi belgilar

Beshta belgi bor edi. Ulardan uchtasi rasmiy hujjatlarda ko‘rsatilgan joriy etish nuqtalarining aynan o‘zi edi.

Asosiy qism protseduralar o‘rniga shell parchalariga to‘lib ketgan

Ikkita skill fayli qariyb 400 qatorga yetdi va ularning yarmi kod bloklaridan iborat edi. Tuzilma AI’ga repository snapshot’ini olish, image tag’larini taqqoslash, DB migration fayl nomlarini tekshirish, versiyalar matritsasini tekshirish va ekran yo‘llarini ajratib olish kabi deterministik vazifalar uchun asosiy qismdagi shell parchalarini har safar qayta terib, ishga tushirishni topshirardi. Natijalar har bir bajarilishda biroz farq qilar, hatto bir safar avvalgi bajarilishdan qolgan faylni o‘qib, noto‘g‘ri tafovut ham hosil qilgan. Rasmiy hujjatlardagi iborani ishlatadigan bo‘lsak, “saralash algoritmini ishga tushirish tokenlar bo‘yicha saralashdan arzonroq.” Trigger berilganda SKILL.md asosiy qismi to‘liq holda kontekstga yuklanadi, skriptlar esa faqat ishga tushiriladi va chiqishi uchun tokenlardan foydalanadi.

Bir xil qoidalarning nusxalari bir nechta joyda mavjud

Git qoidalari to‘rtta joyda mavjud edi: ikkita skill va ikkita rejalashtirilgan promptda. Buning sababi “Agar skill mavjud bo‘lmasa, quyidagi protseduraga amal qiling” degan qism bilan to‘liq protseduraning promptlarda takrorlanganidir. Zaxiralilikni ta’minlash niyati yaxshi edi, ammo bu bitta qoidani o‘zgartirish uchun to‘rtta joyga tegishni anglatardi va nusxalardan biri farqlanib ketgan edi.

Bajarilish muhiti hodisaga sabab bo‘ldi

Rejalashtirilgan vazifalar ishlagan muhitda ulangan jildlarda fayllarni o‘chirish bloklangan edi. Biroq git faqat o‘qishga o‘xshab ko‘rinadigan buyruqlar uchun ham lock fayllarini yaratadi va o‘chiradi, shuning uchun o‘chirib bo‘lmaydigan bo‘sh lock fayllari har bir repository’da qolib ketdi. “Faqat o‘qish buyruqlari xavfsiz” degan qoida bu muhitda noto‘g‘ri edi. Bu hodisadan lock fayllarining o‘zidan tashqari yana ikki saboq olindi. Bajarilish muhitining tabiati dizaynning bir qismidir, jumla shaklida yozilgan qoidalar esa rasmiy hujjatlarda aytilganidek, “kafolatlar emas, so‘rovlardir.” Har safar bajarilishi shart bo‘lgan qoidalar hook’lar orqali majburiy ta’minlanishi kerak.

Protsedura shakllanib bo‘ldi

Ikkala skill’ning bo‘limlar tuzilmasi bir xil bo‘lib qoldi: tamoyillar → maqsadlar → snapshot va yangilik holati → qamrov → bloklovchi shartlar → natijalar. Bu qaysi bosqichlarni skriptlar bilan belgilash mumkinligini, qaysilari esa AI mulohazasini talab qilishini ajratish mumkin bo‘lib qolganini anglatardi va tavsiya etilgan tuzilmaga o‘tish vaqti kelgan edi (asosiy qismda protsedura bo‘ladi, qoidalar reference fayllarda, kod esa skriptlarda joylashadi). Agar boshidanoq shu tuzilma bilan boshlaganimizda, nimasi deterministik, nimasi esa mulohazani talab qilishini bilmaganimiz sababli narsalarni noto‘g‘ri ajratgan bo‘lardik.

Keyingi foydalanuvchi uchun mos shakllantirilmagan

Skill’lar hisobim bilan sinxronlangan, ma’lum tafovutlar va ko‘rsatish glossariysi nasriy ro‘yxatlar ko‘rinishida edi, asosiy qismda esa sanalar qo‘shilgan jumlalar mavjud edi. Yagona foydalanuvchi men bo‘lgan paytda bu muammo emasdi. Ammo buni o‘zim alohida yozadigan harness’ga qo‘shish yoki jamoa yoxud tashkilotda AI’ni joriy etish uchun ishlatish uchun uni plugin sifatida tartibga solish, konfiguratsiyani ma’lumotga aylantirish va qoidalarni bir joyda saqlash kerak. Agar uni vaqtinchalik protsedura sifatida tashlab yuboriladigan shaklda qoldirsak, keyingi bosqichda hammasini qayta qurishimizga to‘g‘ri keladi.

5. Yaxshilanishlar

Yaxshilanishlar yo‘nalishini bitta jumla bilan ifodalash mumkin. Skriptlar belgilangan qoidalar asosida tekshiruvlarni bajaradi, AI skill’lar asosida mulohaza yuritadi, qoidalar faqat bitta joyda saqlanadi, hook’lar esa bajarilishi shart bo‘lgan qoidalarni majburiy ta’minlaydi. Men ushbu standartga muvofiq ikkita skill’ni yana qayta ajratdim va ularni bitta plugin’ga birlashtirdim.

devlime-release-ops/
├── skills/        release-check · release-notes · prd-gitops-sync
│                  (각 50줄 안팎, 체크리스트 + 판단)
├── references/    repos · git-rules · flyway-check · configmap-compare
│                  notice-style · known-deviations · history · ledger
├── config/        저장소 표 · gitops 대조 규칙 · 기준값 · 버전 상호 참조
│                  알려진 편차 · ledger  (JSON)
├── scripts/       snapshot · freshness · changes · flyway_lint · version_matrix
│                  cm_pair · routes · locate · ledger · notice_lint · image_tags
│                  configmap_diff · plan_validate · plan_apply · plan_verify
├── hooks/         hooks.json + guard.py  (명령 실행 전 규칙 검사)
├── evals/         스킬별 평가 + 트리거 질의
└── tests/         합성 저장소 생성 + 검사

Skriptlar tekshiruvlarni bajaradi va exit code’lar orqali aloqa qiladi. Repository’ning yangilangan-yangilanmagani, o‘zgarish qamrovi, DB o‘zgarishlari formati, kutubxona versiyalari mosligi va image tag’larini taqqoslash kabi belgilangan qoidalarga ega tekshiruvlar Python skriptlari orqali bajariladi. Natijalar fayllarga saqlanadi, exit code esa “o‘tdi / bloklandi / tekshirish kerak / xato” holatlaridan birini bildiradi. Agar bloklansa, skill uni hisobotning yuqori qismiga joylashtiradi va to‘xtaydi; tekshirish talab qiladigan bandlar esa mulohaza yuritish uchun uzatiladi. Endi skill asosiy qismida faqat ushbu skriptlarni tartib bilan chaqiradigan checklist va mulohaza talab qiladigan bandlarni qanday tekshirish haqidagi tushuntirishlar mavjud.

Release check:
- [ ] 1. 스냅샷        snapshot.py
- [ ] 2. 신선도        freshness.py     (낡았으면 멈추고 최신화 명령을 사용자에게)
- [ ] 3. 변경 범위     changes.py
- [ ] 4. DB 반영 사항  flyway_lint.py   (판단이 필요한 항목만 가이드 문서를 읽고 판정)
- [ ] 5. 버전 정합     version_matrix.py
- [ ] 6. 보고서 조립 → 문서 저장

Qaytarib bo‘lmaydigan o‘zgarishlar to‘rt bosqichga bo‘linadi: rejalashtirish, tekshirish, qo‘llash va tasdiqlash. Operatsion sozlamalarni o‘zgartirish jarayoni taqqoslash natijalariga asoslanib fayllarni darhol tahrirlashdan, avval AI reja faylini yaratadigan jarayonga o‘zgardi (qaysi fayldagi qaysi qiymat nimaga va nima sababdan o‘zgartirilishi), so‘ng validation skripti qo‘llashdan oldin ushbu rejani qoidalar va joriy fayllar bilan taqqoslaydi. Rejadagi hatto bitta bandda qaror keyinga qoldirilgan bo‘lsa ham, bajarilish davom etmaydi; agar foydalanuvchi ma’qullagan qiymat shu orada o‘zgarsa, jarayon to‘xtaydi. Bu ichki blogdagi “decision gate” va “snapshot-based approval” yondashuvlarini bevosita qabul qiladi. O‘zgarishlar qo‘llangach, haqiqiy o‘zgarishlar rejaga aynan mos kelishini yana tekshiradi.

Qoidalar bir joyda saqlanadi va hook’lar orqali majburiy ta’minlanadi. To‘rtta joyga tarqalgan qoidalar endi yagona reference fayliga ega bo‘lib, u qoidalarning yagona ishonchli manbasi hisoblanadi; skill’lar va rejalashtirilgan promptlar faqat shu faylga murojaat qiladi. Hook’lar xuddi shu qoidalarni tool-call bosqichida tekshiradi va tafovut qiladigan buyruqlarni sababini ko‘rsatgan holda rad etadi. Jumla shaklida yozilgan qoidalar AI amal qilishi kutiladigan narsalardir, hook’lar esa ularga amal qilmaslikni imkonsiz qiladi. Rejalashtirilgan vazifa promptlarida endi protsedura takrorlanmaydi; ular shunchaki ikki qatordan iborat: “skill’ni ishga tushir; agar u mavjud bo‘lmasa, to‘xta.” Sanali tarix alohida faylga ko‘chirildi va asosiy qismda faqat qoidalar qoldirildi.

Oldin va keyin taqqoslash

6. Xulosa

Bu sozlama skilllar toʻplami, oʻn uchta skript, bitta hook va ularni birlashtiradigan bitta plagindan iborat. Claude Code taqdim etadigan kengaytma funksiyalarining yetti qatlami orqali qaralganda, bu hali ham faqat bir qism, bundan tashqari, hozircha unda faqat bitta foydalanuvchi bor. Biroq bu koʻlam yetarli boʻlmagani uchun emas, balki ustuvorlik tartibi belgilanganligi natijasidir. Rasmiy hujjatlarda har bir funksiyani qachon joriy etish kerakligi koʻrsatilgani sababli, qaysi triggerlarga yetganimni va qaysilariga hali yetmaganimni ayta olaman hamda keyingi funksiya qachon zarur boʻlishini oldindan bilaman.

Dastlabki sozlamadan plag­ingacha boʻlgan eng katta oʻzgarish tekshiruv bandlarining joylashuvida boʻldi. Avval xayolimda va xabarlar tarixida boʻlgan narsalar fayllarga koʻchirildi; bu fayllarning yarmi odamlar oʻqishi uchun qoidalarga, qolgan yarmi esa skriptlar bajarishi uchun tekshiruvlarga aylandi. Natijada biz bir xil narsalarni bir xil tartibda koʻrib chiqdik, qarori keyinga qoldirilgan bandlar har safar oʻsha joyida qoldi va shu orada tasdiqlangan qiymat oʻzgarganida jarayon toʻxtadi. AI bilan deploy tekshiruvlari ustida ishlash vaqtni tejashdan koʻra bu foydaning koʻproq qismini berdi.

Keyingi qadam — bu sozlamani haqiqiy repositoryda validatsiya qilish. Ushbu sozlamani qanday boshqarish va uni jamoaga qachon taqdim etish keyingi maqolada, "Shaxsiy AI sozlamasini jamoa resursiga aylantirish mezonlari"da yoritiladi.

Juno