Tətbiqlərin hazırlanmasında buraxılış günü: mahiyyəti, mərhələləri və hazırlıq
Buraxılış günü (release day) — mobil tətbiqin yeni versiyasının buraxılması üçün planlaşdırılmış tarix olub, build hazırlığı, mağaza rəyi, staged rollout və monitorinqi əhatə edir. iOS tətbiqləri üçün proses App Store Connect-ə build yükləməklə başlayır (planlaşdırılmış buraxılış tarixindən 24-48 saat əvvəl) məcburi Apple rəyi səbəbindən. Android üçün — Google Play Console-da qurma və yükləmə, burada rəy prosesi adətən 1-4 saat çəkir. Apple Developer Guidelines (2025)-ə görə, build-ların 90%-i 24 saat ərzində rəyi keçir. Staged rollout dərc edildikdən sonra səhvlər aşkarlandıqda təsiri minimuma endirməyə imkan verir.
Əsas məqamlar
- Release day — build-in qurulmasından rollout sonrası monitorinqə qədər tədbirlər kompleksi
- Staged rollout — tədricən yayma: 1%, 10%, 50%, 100%
- Smoke testing — build-in mağazaya göndərilməzdən əvvəl son yoxlanışı
- Rollback plan — kritik səhvlər zamanı əvvəlcədən hazırlanmış geri qaytarma ssenarisi
- Release retrospective — rollout 100% tamamlandıqdan sonra prosesin təhlili
Buraxılış günü nədir və ona necə hazırlaşmaq lazımdır
Buraxılış günü — sadəcə Publish düyməsini basmaq anı deyil. Bu, proqramçıların, QA-nın, devopsların, product menecerlərin və bəzən dəstəyin iştirak etdiyi əlaqələndirilmiş bir prosesdir. Hazırlıq buraxılış günündən 2-3 həftə əvvəl başlayır: scope-un razılaşdırılması, code freeze, reqressiya testi, release notes və marketinq materiallarının hazırlanması. Hazırlıq nə qədər hərtərəfli olarsa, buraxılış günü bir o qədər rahat keçir.
Buraxılış gününə hazırlıq checklist-i: buraxılış build-ində yekun QA keçidi (regression + smoke suite); mağazalarda metadata yoxlanışı (ad, təsvir, ekran görüntüləri, keywords); product menecer ilə staged rollout faizinin razılaşdırılması; rollback planının hazırlanması (hansı teq yenidən yerləşdiriləcək, nə qədər vaxt aparacaq); komandanın və əlaqədar xidmətlərin qarşıdakı buraxılış barədə xəbərdar edilməsi. Release checklist CI/CD vasitəsilə avtomatlaşdırılmalıdır — məsələn, buraxılış teqi yaratmazdan əvvəl bütün maddələri yoxlayan GitHub Actions workflow şəklində.
Hazırlığın vacib elementi — blackout period (istehsalatda yerləşdirmələrin qadağan olduğu dövr). Adətən blackout buraxılış günündən 48 saat əvvəl tətbiq edilir və 100% uğurlu rollout-dan 24 saat sonra ləğv edilir. Bu, buraxılışa mane ola biləcək təsadüfi yerləşdirmələrin qarşısını alır. Change freeze blackout dövründə buraxılışla əlaqəli bütün xidmətlərə şamil edilir.
Build hazırlığı: code freeze, teqləmə və qurma
Buraxılış günündən 24-48 saat əvvəl code freeze tətbiq edilir — koddakı dəyişikliklərin tam dayandırılması. Proqramçılar sənədləşmə və release notes hazırlığına keçirlər. DevOps müəyyən edilmiş teqdən (məs. v2.6.0-rc1) buraxılış build-i yığır. Build tam regression suite-dən (avtomatik + əl testləri) keçir. Critical bugs aşkar edilərsə — onlar code freeze-dən əvvəl düzəldilir və ya buraxılış təxirə salınır. Release candidate (RC) — QA-dan keçmiş və mağazaya göndərilməyə hazır build.
Git-də teqləmə: annotasiyalı teq yaradılır (git tag -a v2.6.0 -m "Release v2.6.0"). CI/CD pipeline Google Play üçün AAB (Android App Bundle) və Apple App Store üçün IPA (iOS App Store Package) yığır. Build-ə əlavə olunur: nəzarət məbləğləri olan fayl (SHA256), changelog və məlum problemlərin siyahısı (known issues). Reproducible builds — eyni teqdən təkrar qurmanın ikili eyni nəticə verdiyi ideal təcrübə.
bash
# Buraxılış pipeline-i — teq yaratma və qurma
# Code freeze-in artıq aktiv olduğunu qəbul edir
# Develop-dan buraxılış branch-i yaradın
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: branch mühafizə qaydaları yeni PR-ları bloklayır
# CI/CD-də reqressiya dəstini işə salın
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Uğurlu QA-dan sonra buraxılış teqi yaradın
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# CI/CD vasitəsilə buraxılış binary-sini qurun
# fastlane build_release AAB + universal APK yaradır
fastlane build_releaseVacib: version bump (version code və version name-in yenilənməsi) code freeze-dən əvvəl edilir. Code freeze-dən sonra versiya dəyişmir. Android üçün: versionCode — monoton artan tam ədəd; versionName — semantik versiya (2.6.0). iOS üçün: CFBundleVersion (build number) və CFBundleShortVersionString (semantik versiya). Versioning gradle/xcconfig-də avtomatlaşdırılmalıdır.
Mağazaya yükləmə və rəydən keçmə
iOS üçün: build Xcode, Transporter və ya fastlane vasitəsilə App Store Connect-ə yüklənir. Yükləndikdən sonra build avtomatik Apple yoxlamasından (processing) keçir, sonra əl rəyinə göndərilir. Orta rəy müddəti — 24 saat, lakin Apple rəyçilərinin yükündən və compliance tələblərindən asılı olaraq 1 saatdan 7 günə qədər dəyişə bilər. Expedited review — kritik bug fixes üçün sürətləndirilmiş rəy sorğusu (ayda bir dəfədən çox olmayaraq, zəmanət verilmir).
Android üçün: build Google Play Console vasitəsilə yüklənir. Google kombinə edilmiş yanaşma tətbiq edir: avtomatik test (accessibility, malware, policy compliance) + seçmə əl rəyi. Orta rəy müddəti — 1-4 saat. Internal test track və Closed track Production track-də dərc edilməzdən əvvəl yekun test aparmağa imkan verir. Tövsiyə olunur: Internal test üçün 1-2 gün → Closed beta üçün 1 gün → tədricən Production rollout.
Hər iki platforma üçün build yükləməzdən əvvəl metadatları yoxlamaq kritik əhəmiyyət daşıyır: tətbiqin adı, təsviri (short + full), hər bir supported device üçün ekran görüntüləri (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) və ya store listing experiments (Android). Metadatada səhv rəyi əlavə bir gün gecikdirə bilər. App metadata bütün dəstəklənən dillərdə lokalizasiya edilməlidir.
Staged rollout: buraxılışı risksiz necə yaymaq olar
Staged rollout (gradual rollout, staged deployment) — yeni versiyanın istifadəçilərə dərhal deyil, mərhələli şəkildə əlçatan olduğu strategiya. Yetkin komanda üçün tipik sxem: istifadəçilərin 1%-i (ilk 2-4 saat) → 10% (24 saat) → 25% (24 saat) → 50% (24 saat) → 100%. Hər mərhələ metrikaların monitorinqini və kritik səhvlərin olmadığının yoxlanılmasını əhatə edir. Staged rollout — buraxılışlarda riskin minimallaşdırılmasının əsas alətidir.
Google Play Console daxili staged rollout təmin edir: istifadəçilərin faizini göstərmək və tədricən artımı planlaşdırmaq olar. iOS App Store Connect-də belə daxili imkan yoxdur — staged rollout Phased Release (7 gün ərzində avtomatik əhatə dairəsinin artırılması, dayandırma imkanı ilə) və ya geolokasiya ilə server-side feature flags vasitəsilə həyata keçirilir. Phased release App Store Connect-də problem aşkar edildikdə Buraxılışı Dayandırmaq (Pause Release) imkanı verir.
Növbəti mərhələyə keçid üçün əsas metrikalar: crash-free rate (yeni buraxılış üçün ≥99.9%), ANR rate (Android, ≤0.1%), backend API-də error rate (≤0.5% 5xx), istifadəçi reytinqləri (əvvəlki versiyadan aşağı olmamalı), apdex score (≥0.94). Hər hansı metrika həddi aşarsa — səbəblər aydınlaşdırılana qədər rollout dayandırılır. Go/no-go gate hər mərhələdə — release manager və ya on-call mühəndisinin məsuliyyətidir.
Buraxılış sonrası monitorinq: ilk saatlarda nəyə baxmaq lazımdır
Buraxılışdan sonra ilk 4 saat — ən kritik vaxtdır. Komanda crash rate (Sentry, Firebase Crashlytics, App Center), backenddə error rate 5xx, custom events (uğurlu ödənişlər, girişlər, qeydiyyatlar), App Store və Google Play-də istifadəçi reytinqləri, sosial media qeydləri (Twitter, Reddit) monitorinq edir. Monitorinq dashboard-ı əvvəlcədən hazırlanmalı və ofisdə böyük ekranda və ya ayrılmış Slack kanalında əlçatan olmalıdır. Release dashboard — buraxılışın bütün metrikaları üçün vahid pəncərə.
Xüsusi diqqət — reqressiya metrikaları: crash rate-in əvvəlki versiya ilə müqayisəsi. Crash rate 0.1%-dən çox artarsa — bu dərhal analiz tələb edən qırmızı bayraqdır. Həmçinin əsas API endpoint-lərinin median və p95 gecikməsini müqayisə etmək vacibdir: crashesiz belə, cavab müddətinin 200ms yavaşlaması problemə işarə edə bilər. Metric comparison (baseline vs current) Datadog və ya Grafana-da avtomatlaşdırılır.
İstifadəçi rəyi (user feedback) — rəqəmsal metrikalar qədər vacibdir. Buraxılışdan sonra ilk saatlarda istifadəçilər mağazalarda fəal şəkildə rəy yazır və dəstəyə müraciət edirlər. Testlər tərəfindən tutulmayan səhvlər rəylərdə tez üzə çıxır. Team lead və ya təyin edilmiş QA mühəndisi ilk 4 saat ərzində hər 30 dəqiqədən bir rəyləri izləyir və təsnif edir: false positive, known issue (artıq known issues siyahısında), new bug. New bugs P0/P1 — rollout-un dayandırılması üçün trigger.
Rollback: buraxılışı nə vaxt və necə geri qaytarmaq lazımdır
Rollback — kritik problemlər aşkar edildikdə əvvəlki stabil versiyaya qayıdış. Rollback qərarı release manager tərəfindən tech lead ilə birgə qəbul edilir, əgər: yeni buraxılışın crash-free rate-i 99%-dən aşağı düşərsə, məlumat sızması aşkar edilərsə, kritik funksionallıq (ödənişlər, autorizasiya) istifadəçilərin >5%-i üçün işləməzsə və ya mağaza (App Store Review) build-i dərc edildikdən sonra rədd edərsə. Rollback trigger buraxılışdan əvvəl müəyyən edilməlidir ki, qərar faktlara əsaslanaraq qəbul edilsin, emosiyalara deyil.
Android üçün: Google Play Console-da rollback — staged rollout-un dayandırılması və əvvəlki versiyaya keçid. Əgər cari build artıq 100% istifadəçidədirsə — əvvəlki versiyanın yeni buraxılış kimi dərc edilməsi. iOS üçün: App Store Connect vasitəsilə — Phased Release → Pause Release → düzəliş ilə yeni versiyanın buraxılması (App Store əvvəlki versiyaya qayıtmağa imkan vermir). iOS rollback daha mürəkkəbdir: proqramçı revert-commitlər ilə yeni build yığmalı və rəyi yenidən keçməlidir.
Rollback-dən sonra komanda insident rejiminə keçir: root cause analysis, hotfix və ya düzəliş ilə növbəti buraxılış, post-mortem. Rollback — uğursuzluq deyil, standart prosedurdur. Heç vaxt rollback etməyən komandalar çox güman ki, problemi görmür, qüsursuz buraxılışlar etmir. Rollback rate — DORA metrikalarından biridir: yüksək məhsuldar komandalar buraxılışların <10%-də rollback edir və <1 saata bərpa olur.
Tez-tez verilən suallar
Mobil tətbiqin buraxılışı üçün hansı gün daha yaxşıdır?
Ən yaxşı günlər — çərşənbə axşamı, çərşənbə və ya cümə axşamı. Bazar ertəsi — həftəsonundan yüksək trafik, cümə — həftəsonuna problemli buraxılışla daxil olma riski. Cümədən qaçın: yerləşdirmədən sonra problem aşkar edilərsə, komanda onu həftəsonu düzəldəcək və ya bazar ertəsini gözləyəcək.
App Store Review build-i rədd edərsə nə etməli?
Resolution Center-də rədd etmə səbəbini oxuyun, düzəldin və build-i yenidən yükləyin. Tez-tez rast gəlinən səbəblər: işləməyən keçidlər, doldurulmamış sahələr, abunə tələb olunduqda məzmunsuz, köhnəlmiş ekran görüntüləri. App Review rejection buraxılışı 24-48 saat gecikdirir, buna görə build-in ilk yüklənməsi planlaşdırılmış buraxılış tarixindən 3-5 gün əvvəl olmalıdır.
Başlanğıc üçün staged rollout-un hansı faizi optimaldır?
Böyük buraxılışlar üçün (major changes) — 1%. Patch buraxılışlar üçün — 5-10%. İlk mərhələ səhv halında təsirin minimal olması üçün kifayət qədər kiçik, lakin statistik əhəmiyyətli metrikalar əldə etmək üçün kifayət qədər böyük olmalıdır. 1% 10 milyon istifadəçisi olan tətbiq üçün — 100 min nəfər, kritik problemləri aşkar etmək üçün kifayətdir.
Release party etmək lazımdırmı?
Release party (komanda şənliyi) — isteğe bağlıdır, lakin əhval-ruhiyyə üçün faydalıdır. Build yükləmə anında deyil, 100% uğurlu rollout-dan sonra keçirmək daha yaxşıdır. Release celebration nəyin yaxşı getdiyini və nəyi təkmilləşdirmək olduğunu müzakirə etmək üçün release retrospective ilə birləşdirilə bilər.
„Buraxılış və ya təxirə sal“ qərarına kim cavabdehdir?
Cavabdehlik release manager-in üzərindədir (adətən senior engineer və ya tech lead). Qərar deadline-ə əsasən deyil, release dashboard məlumatları əsasında qəbul edilir. Release manager metrikalar go/no-go gate-dən keçməzsə, buraxılışı gecikdirmək səlahiyyətinə malikdir.
Nəticə
- Buraxılış günü — code freeze-dən rollout sonrası monitorinqə qədər əlaqələndirilmiş proses
- Hazırlıq — release candidate, QA keçidi, metadata yoxlanışı, rollback planı
- Staged rollout — 1% → 10% → 25% → 50% → 100% hər mərhələdə go/no-go gate ilə
- Monitorinq — crash-free rate, ANR, error rate 5xx, istifadəçi reytinqləri ilk 4 saatda
- Rollback — crash-free rate 99%-dən aşağı düşdükdə standart prosedur
- Kommunikasiya — komandanın və maraqlı tərəflərin buraxılışdan əvvəl və sonra xəbərdar edilməsi
- Release retrospective — rollout 100% tamamlandıqdan sonra prosesin təhlili
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun