Ilovalarni ishlab chiqishda chiqarish kuni: mohiyati, bosqichlari va tayyorgarlik
Chiqarish kuni (release day) — mobil ilovaning yangi versiyasini chiqarish uchun rejalashtirilgan sana bo'lib, build tayyorlash, do'kon review-si, staged rollout va monitoringni o'z ichiga oladi. iOS ilovalari uchun jarayon build-ni App Store Connect-ga yuklash bilan boshlanadi (rejalashtirilgan chiqarish sanasidan 24-48 soat oldin) majburiy Apple review-si sababli. Android uchun — Google Play Console-da qurish va yuklash, bu yerda review jarayoni odatda 1-4 soat davom etadi. Apple Developer Guidelines (2025) ga ko'ra, build-larning 90% 24 soat ichida review-dan o'tadi. Staged rollout nashr etilgandan so'ng xatolar aniqlanganda ta'sirni minimallashtirishga imkon beradi.
Asosiy fikrlar
- Release day — build-ni qurishdan rollout dan keyingi monitoringgacha bo'lgan tadbirlar majmui
- Staged rollout — bosqichma-bosqich tarqatish: 1%, 10%, 50%, 100%
- Smoke testing — build-ni do'konga yuborishdan oldin yakuniy tekshirish
- Rollback plan — tanqidiy xatolar uchun oldindan tayyorlangan qaytarish ssenariysi
- Release retrospective — rollout 100% tugagandan so'ng jarayon tahlili
Chiqarish kuni nima va unga qanday tayyorlanish kerak
Chiqarish kuni — bu shunchaki Publish tugmasini bosish momenti emas. Bu dasturchilar, QA, devopslar, product menejerlar va ba'zan yordam xizmati ishtirok etadigan muvofiqlashtirilgan jarayon. Tayyorgarlik chiqarish kunidan 2-3 hafta oldin boshlanadi: scope-ni kelishish, code freeze, regressiya testi, release notes va marketing materiallarini tayyorlash. Tayyorgarlik qanchalik puxta bo'lsa, chiqarish kuni shunchalik tinch o'tadi.
Chiqarish kuniga tayyorgarlik checklist-i: chiqarish build-idagi yakuniy QA o'tishi (regression + smoke suite); do'konlarda metama'lumotlarni tekshirish (nom, tavsif, ekran tasvirlari, keywords); product menejer bilan staged rollout foizini kelishish; rollback rejasini tayyorlash (qaysi tegni qayta joylashtirish, qancha vaqt ketadi); jamoa va bog'liq xizmatlarni bo'lajak chiqarish haqida xabardor qilish. Release checklist CI/CD orqali avtomatlashtirilishi kerak — masalan, chiqarish tegini yaratishdan oldin barcha bandlarni tekshiradigan GitHub Actions workflow shaklida.
Tayyorgarlikning muhim elementi — blackout period (ishlab chiqarishga joylashtirishlar taqiqlangan davr). Odatda blackout chiqarish kunidan 48 soat oldin joriy etiladi va 100% muvaffaqiyatli rollout-dan 24 soat keyin olib tashlanadi. Bu chiqarishga xalaqit berishi mumkin bo'lgan tasodifiy joylashtirishlarning oldini oladi. Change freeze blackout davrida chiqarish bilan bog'liq barcha xizmatlarga tatbiq etiladi.
Build tayyorlash: code freeze, teglash va qurish
Chiqarish kunidan 24-48 soat oldin code freeze joriy etiladi — koddagi o'zgarishlarni to'liq to'xtatish. Dasturchilar hujjatlar va release notes tayyorlashga o'tadilar. DevOps belgilangan tegdan (masalan, v2.6.0-rc1) chiqarish build-ni quradi. Build to'liq regression suite-dan (avtomatik + qo'lda testlar) o'tadi. Agar tanqidiy xatolar topilsa — ular code freeze-dan oldin tuzatiladi yoki chiqarish kechiktiriladi. Release candidate (RC) — QA-dan o'tgan va do'konga yuborishga tayyor build.
Git-da teglash: annotatsiyalangan teg yaratiladi (git tag -a v2.6.0 -m "Release v2.6.0"). CI/CD pipeline Google Play uchun AAB (Android App Bundle) va Apple App Store uchun IPA (iOS App Store Package) quradi. Build-ga ilova qilinadi: nazorat summalari fayli (SHA256), changelog va ma'lum muammolar ro'yxati (known issues). Reproducible builds — bir xil tegdan qayta qurish ikkilik bir xil natija beradigan ideal amaliyot.
bash
# Chiqarish pipeline i — teg yaratish va qurish
# Code freeze allaqachon faol deb hisoblaydi
# Develop dan chiqarish branch ini yarating
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: branch himoya qoidalari yangi PR larni bloklaydi
# CI/CD da regressiya to'plamini ishga tushiring
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Muvaffaqiyatli QA dan keyin chiqarish tegini yarating
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# CI/CD orqali chiqarish binary sini quring
# fastlane build_release AAB + universal APK ishlab chiqaradi
fastlane build_releaseMuhim: version bump (version code va version name ni yangilash) code freeze-dan oldin qilinadi. Code freeze-dan keyin versiya o'zgarmaydi. Android uchun: versionCode — monoton ortib boruvchi butun son; versionName — semantik versiya (2.6.0). iOS uchun: CFBundleVersion (build number) va CFBundleShortVersionString (semantik versiya). Versioning gradle/xcconfig da avtomatlashtirilishi kerak.
Do'konga yuklash va review-dan o'tish
iOS uchun: build Xcode, Transporter yoki fastlane orqali App Store Connect-ga yuklanadi. Yuklangandan so'ng build avtomatik Apple tekshiruvidan (processing) o'tadi, keyin qo'lda review-ga yuboriladi. O'rtacha review vaqti — 24 soat, lekin Apple review-chilarining yuklamasiga va compliance talablariga qarab 1 soatdan 7 kungacha o'zgarishi mumkin. Expedited review — tanqidiy xatolarni tuzatish uchun tezlashtirilgan review so'rovi (oyda bir martadan ko'p bo'lmagan, kafolatlanmagan).
Android uchun: build Google Play Console orqali yuklanadi. Google kombinatsiyalangan yondashuvni qo'llaydi: avtomatik test (accessibility, malware, policy compliance) + tanlab qo'lda review. O'rtacha review vaqti — 1-4 soat. Internal test track va Closed track Production track-da nashr qilishdan oldin yakuniy test o'tkazishga imkon beradi. Tavsiya etiladi: Internal test uchun 1-2 kun → Closed beta uchun 1 kun → bosqichma-bosqich Production rollout.
Ikkala platforma uchun build-ni yuklashdan oldin metama'lumotlarni tekshirish juda muhim: ilova nomi, tavsifi (short + full), har bir supported device uchun ekran tasvirlari (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) yoki store listing experiments (Android). Metama'lumotdagi xato review-ni qo'shimcha bir kunga kechiktirishi mumkin. App metadata barcha qo'llab-quvvatlanadigan tillarda lokalizatsiya qilinishi kerak.
Staged rollout: chiqarishni xavfsiz qanday tarqatish
Staged rollout (gradual rollout, staged deployment) — yangi versiya foydalanuvchilarga birdaniga emas, balki bosqichma-bosqich taqdim etiladigan strategiya. Yetuk jamoa uchun odatiy sxema: foydalanuvchilarning 1% (birinchi 2-4 soat) → 10% (24 soat) → 25% (24 soat) → 50% (24 soat) → 100%. Har bir bosqich metrikalarni kuzatish va tanqidiy xatolar yo'qligini tekshirishni o'z ichiga oladi. Staged rollout — chiqarishlarda xavfni minimallashtirishning asosiy vositasidir.
Google Play Console ichki staged rollout ni ta'minlaydi: foydalanuvchilarning foizini ko'rsatish va bosqichma-bosqich o'sishni rejalashtirish mumkin. iOS App Store Connect-da bunday ichki imkoniyat yo'q — staged rollout Phased Release (7 kun davomida avtomatik qamrovni oshirish, to'xtatish imkoniyati bilan) yoki geografik taqsimot bilan server-side feature flags orqali amalga oshiriladi. Phased release App Store Connect-da muammo aniqlanganda Chiqarishni To'xtatish (Pause Release) imkoniyatini beradi.
Keyingi bosqichga o'tish uchun asosiy metrikalar: crash-free rate (yangi chiqarish uchun ≥99.9%), ANR rate (Android, ≤0.1%), backend API da error rate (≤0.5% 5xx), foydalanuvchi reytinglari (oldingi versiyadan past bo'lmasligi kerak), apdex score (≥0.94). Agar biron bir metrika chegaradan oshsa — sabablar aniqlanmaguncha rollout to'xtatiladi. Go/no-go gate har bir bosqichda — release manager yoki on-call muhandisining mas'uliyati.
Chiqarishdan keyin monitoring: dastlabki soatlarda nimaga qarash kerak
Chiqarishdan keyingi dastlabki 4 soat — eng tanqidiy vaqt. Jamoa crash rate (Sentry, Firebase Crashlytics, App Center), backenddagi error rate 5xx, custom events (muvaffaqiyatli to'lovlar, kirishlar, ro'yxatdan o'tishlar), App Store va Google Play-dagi foydalanuvchi reytinglari, ijtimoiy tarmoq eslatmalari (Twitter, Reddit) ni kuzatadi. Monitoring dashboard-i oldindan tayyorlangan bo'lishi va ofisda katta ekranda yoki maxsus Slack kanalida mavjud bo'lishi kerak. Release dashboard — chiqarishning barcha metrikalari uchun yagona oyna.
Maxsus e'tibor — regressiya metrikalari: crash rate ni oldingi versiya bilan bir xil davrda solishtirish. Agar crash rate 0.1% dan ko'proq oshsa — bu zudlik bilan tahlil qilishni talab qiladigan qizil bayroqdir. Shuningdek, asosiy API endpointlarining median va p95 kechikishini solishtirish muhim: hatto crashlarsiz ham, javob vaqtining 200ms sekinlashishi muammoga ishora qilishi mumkin. Metric comparison (baseline vs current) Datadog yoki Grafana da avtomatlashtiriladi.
Foydalanuvchi fikr-mulohazalari (user feedback) — raqamli metrikalar kabi muhim. Chiqarishdan keyingi dastlabki soatlarda foydalanuvchilar do'konlarda faol ravishda sharh qoldiradilar va yordam xizmatiga yozadilar. Testlar tomonidan ushlanmagan xatolar sharhlarda tezda paydo bo'ladi. Team lead yoki tayinlangan QA muhandisi dastlabki 4 soat davomida har 30 daqiqada sharhlarni kuzatadi va tasniflaydi: false positive, known issue (allaqachon known issues ro'yxatida), new bug. New bugs P0/P1 — rollout ni to'xtatish uchun trigger.
Rollback: chiqarishni qachon va qanday qaytarish kerak
Rollback — tanqidiy muammolar aniqlanganda oldingi barqaror versiyaga qaytish. Rollback qarori release manager tomonidan tech lead bilan birgalikda qabul qilinadi, agar: yangi chiqarishning crash-free rate i 99% dan pastga tushsa, ma'lumot sizib chiqishi aniqlansa, tanqidiy funksionallik (to'lovlar, avtorizatsiya) foydalanuvchilarning >5% uchun ishlamasa yoki do'kon (App Store Review) build-ni nashrdan keyin rad etsa. Rollback trigger chiqarishdan oldin belgilanishi kerak, shunda qaror his-tuyg'ularga emas, balki faktlarga asoslanadi.
Android uchun: Google Play Console da rollback — staged rollout ni to'xtatish va oldingi versiyaga o'tish. Agar joriy build allaqachon 100% foydalanuvchilarda bo'lsa — oldingi versiyani yangi chiqarish sifatida nashr qilish. iOS uchun: App Store Connect orqali — Phased Release → Pause Release → tuzatish bilan yangi versiyani chiqarish (App Store oldingi versiyaga qaytishga ruxsat bermaydi). iOS rollback murakkabroq: dasturchi revert-commitlar bilan yangi build qurishi va review-ni qaytadan o'tishi kerak.
Rollback dan keyin jamoa insident rejimiga o'tadi: root cause analysis, hotfix yoki tuzatish bilan keyingi chiqarish, post-mortem. Rollback — muvaffaqiyatsizlik emas, balki standart protsedura. Hech qachon rollback qilmagan jamoalar, ehtimol, muammoni sezmaydilar, nuqsonsiz chiqarishlar chiqarmaydilar. Rollback rate — DORA metrikalaridan biri: yuqori samarali jamoalar chiqarishlarning <10% da rollback qiladilar va <1 soatda tiklanadilar.
Tez-tez beriladigan savollar
Mobil ilovani chiqarish uchun eng yaxshi kun qaysi?
Eng yaxshi kunlar — seshanba, chorshanba yoki payshanba. Dushanba — dam olish kunlaridan yuqori trafik, juma — dam olish kunlariga muammoli chiqarish bilan kirish xavfi. Jumadan saqlaning: agar joylashtirishdan keyin muammo aniqlansa, jamoa uni dam olish kunlarida tuzatadi yoki dushanbagacha kutadi.
App Store Review build-ni rad etsa nima qilish kerak?
Resolution Center da rad etish sababini o'qing, tuzating va build-ni qayta yuklang. Tez-tez uchraydigan sabablar: ishlamaydigan havolalar, to'ldirilmagan maydonlar, obuna talab qilinganda kontentsiz, eskirgan ekran tasvirlari. App Review rejection chiqarishni 24-48 soatga kechiktiradi, shuning uchun build-ni birinchi yuklash rejalashtirilgan chiqarish sanasidan 3-5 kun oldin bo'lishi kerak.
Boshlang'ich uchun staged rollout ning qanday foizi optimal?
Katta chiqarishlar uchun (major changes) — 1%. Patch chiqarishlar uchun — 5-10%. Birinchi bosqich xato bo'lgan taqdirda ta'sir minimal bo'lishi uchun yetarlicha kichik, ammo statistik ahamiyatli metrikalarni olish uchun yetarlicha katta bo'lishi kerak. 1% 10 million foydalanuvchisi bo'lgan ilova uchun — 100 ming kishi, tanqidiy muammolarni aniqlash uchun yetarli.
Release party qilish kerakmi?
Release party (jamoa bayrami) — ixtiyoriy, ammo ruhiy holat uchun foydali. Build yuklash vaqtida emas, balki 100% muvaffaqiyatli rollout dan keyin o'tkazish yaxshiroq. Release celebration nima yaxshi o'tgani va nimani yaxshilash mumkinligini muhokama qilish uchun release retrospective bilan birlashtirilishi mumkin.
„Chiqarish yoki kechiktirish“ qaroriga kim javobgar?
Javobgarlik release manager zimmasida (odatda senior engineer yoki tech lead). Qaror deadline ga emas, balki release dashboard ma'lumotlariga asoslanadi. Release manager metrikalar go/no-go gate dan o'tmasa, chiqarishni kechiktirish vakolatiga ega.
Xulosa
- Chiqarish kuni — code freeze dan rollout dan keyingi monitoringgacha muvofiqlashtirilgan jarayon
- Tayyorgarlik — release candidate, QA o'tishi, metama'lumotlarni tekshirish, rollback rejasi
- Staged rollout — 1% → 10% → 25% → 50% → 100% har bosqichda go/no-go gate bilan
- Monitoring — crash-free rate, ANR, error rate 5xx, foydalanuvchi reytinglari dastlabki 4 soatda
- Rollback — crash-free rate 99% dan pastga tushganda standart protsedura
- Kommunikatsiya — jamoa va manfaatdor tomonlarni chiqarishdan oldin va keyin xabardor qilish
- Release retrospective — rollout 100% tugagandan so'ng jarayon tahlili
Biz kalit topshirig'i bilan mobil ilovani ishlab chiqamiz
IT Sectr 2017-yildan beri startaplar va korxonalar uchun iOS va Android ilovalarini yaratadi. Biz sizga maslahat beramiz va eng yaxshi yechimni taklif qilamiz.
Shuningdek o'qing