Mobil tətbiq release engineering xidmətləri yeni iOS və Android versiyasını sadəcə build edib mağazaya yükləməkdən daha geniş bir istehsal imkanları toplusudur. Məqsəd hər relizin təkrarlana bilən, izlənə bilən və lazım olduqda məhdudlaşdırıla və ya düzəldilə bilən şəkildə çıxmasıdır. Bunun üçün mobil binary, API-lər, konfiqurasiya, feature flag-lər, mağaza metadatası, analitika və insident reaksiyası eyni buraxılış planında idarə olunmalıdır.
Canlı məhsulda əsas sual “tətbiqi göndərə bilərikmi?” deyil, “bu versiya real istifadəçilərə təsir etdikdə onu təhlükəsiz idarə edə, müşahidə edə və zərurətdə geri çəkə bilərikmi?” sualıdır. POLADO-nun texniki dəstək və konsaltinq xidməti məhz bu əməliyyat qatını qurmağa və ya mövcud prosesi audit etməyə yönəlir.
Niyə mobil reliz yalnız store submit deyil?
Mobil tətbiq istifadəçi cihazında köhnə versiyalarla uzun müddət birlikdə yaşayır. Buna görə backend API-də edilən dəyişiklik, məcburi yeniləmə qaydası, autentifikasiya axını və ya push notification formatı əvvəlki tətbiq build-ləri ilə də işləməlidir. Store-dan təsdiq alınması server dəyişikliyinin, remote konfiqurasiyanın və üçüncü tərəf xidmətlərinin buraxılışa hazır olduğu anlamına gəlmir.
Etibarlı proses mobil və backend relizlərini uyğunluq matrisi ilə bağlayır: hansı app versiyalarının hansı API kontraktını dəstəklədiyi, köhnə müştərilər üçün hansı endpoint və sahələrin nə qədər saxlanacağı, kritik dəyişikliklərin hansı feature flag arxasında qalacağı əvvəlcədən qeyd olunur. Bu yanaşma mobil tətbiqlərin hazırlanması işini launch günü bitən layihə yox, idarə edilən məhsul xidməti kimi təşkil edir.
Mobile app CI/CD implementation: pipeline nələri avtomatlaşdırmalıdır?
CI/CD pipeline-ın məqsədi “bir düymə ilə production” deyil. Məqsəd insanın yaddaşından və lokal kompüterindən asılı addımları yoxlamaq, artefaktların mənşəyini qorumaq və yalnız uyğun build-in növbəti mərhələyə keçməsinə imkan verməkdir.
Build, imzalama və sirlər
- iOS və Android build-ləri təmiz, versiyalanmış mənbə kodundan yaranmalıdır.
- Signing sertifikatları, provisioning profilləri, keystore və API açarları repozitoriyada saxlanmamalıdır; giriş hüquqları məhdud olan secret store istifadə edilməlidir.
- Pipeline build nömrəsini avtomatik və geri izlənə bilən formada təyin etməli, commit, branch, build artefaktı və release qeydi arasında əlaqə yaratmalıdır.
- Android-də tətbiq yeniləməsinin qəbul olunması üçün application ID, imzalama sertifikatı və daha yüksək version code uyğun olmalıdır. Bu səbəbdən signing açarının sahibliyi və bərpa proseduru əməliyyat riski kimi idarə edilməlidir.
Apple ekosistemində istifadəçiyə görünən versiya və build nömrəsi ayrıca identifikatorlardır; düzgün nömrələmə crash hesabatını, TestFlight testini və store-dakı versiyanı eyni release rekordunda birləşdirməyə kömək edir. Android tərəfdə isə Play App Signing, upload key və paket versiyası üzrə məsuliyyət bölgüsü konkret yazılmalıdır.
Avtomatik keyfiyyət qapıları
Hər commit production üçün namizəd deyil. Pipeline-da kompilasiya, statik analiz, unit test, seçilmiş inteqrasiya testləri, dependency və secret yoxlaması, imzalı artefaktın yaradılması kimi məcburi qapılar olmalıdır. Kritik istifadəçi ssenariləri üçün cihaz və ya emulator testləri də əlavə edilir: giriş, qeydiyyat, ödənişə keçid, əsas məlumatın açılması, offline-dan bərpa və deep link.
Qapılar məhsula uyğun qurulmalıdır. Məsələn, tədbir tətbiqində proqramın və QR giriş axınının işləməsi əsasdır; maliyyə məhsulunda isə sessiya, balansın göstərilməsi və əməliyyat statuslarının düzgünlüyü daha kritikdir. POLADO-nun AIIF 2026 kimi iştirakçı yönümlü platforma işlərində olduğu kimi, reliz yoxlaması istifadəçinin real vaxtda yerinə yetirdiyi vacib işlərdən başlamalıdır.
Environment konfiqurasiyası və feature flag-lər
Development, staging və production fərqli server URL-i olan eyni tətbiq demək deyil. Hər mühit üçün API endpoint-ləri, OAuth client-ləri, push sertifikatları, analitika layihələri, payment sandbox parametrləri və error reporting açarları düzgün ayrılmalıdır. Production sirrinin test build-ə, test endpoint-in isə canlı tətbiqə düşməsini avtomatik yoxlamalarla qarşısını almaq lazımdır.
Feature flag-lər riskli funksiyanı binary ilə birlikdə göndərib onu ayrıca aktivləşdirməyə imkan verir. Ancaq flag özü də release obyekti sayılmalıdır: sahibi, məqsədi, hədəf auditoriyası, aktivləşmə şərti, audit izi və silinmə tarixi olmalıdır. Flag-lərin idarəsiz çoxalması köhnə kod yolları və anlaşılmaz davranış yaradır.
Store-dakı binary-ni geri almaq adətən ani əməliyyat deyil. Ona görə ən effektiv ilk müdafiə xətti server tərəfdən geriyə uyğunluq, feature flag ilə söndürmə və rollout-un dayandırılmasıdır.
App Store və Google Play release management üçün hazırlıq
Store readiness buraxılışın son dəqiqə checklist-i deyil, sprint boyunca toplanan sübut və materialdır. App Store üçün review qeydində yeni funksiyanın konkret izahı, test hesabı, giriş məlumatı, lazım olan hardware və istifadəçi axınının göstərilməsi vacibdir. Metadata, screenshot, privacy məlumatı və tətbiqin real davranışı uyğun olmalıdır. Şifrələmə istifadə edən tətbiqlər üçün export compliance qiymətləndirilməsi də reliz planına daxil edilməlidir.
Google Play-də release track-ləri və managed publishing funksiyası texniki komandanın təsdiqdən sonra dəqiq yayın vaxtını idarə etməsinə kömək edir. Hər iki mağaza üçün release owner, lazım olan hesab rolları, tətbiqin store listing-i, privacy məlumatı, content rating, test hesabları və support kontaktları əvvəlcədən təsdiqlənməlidir.
Store submit checklist
- Versiya, build nömrəsi və release notes təsdiqlənib.
- Production API-ləri və remote konfiqurasiya hazırdır.
- Yeni və köhnə tətbiq versiyaları üzrə backend uyğunluğu yoxlanılıb.
- Review üçün test hesabı, OTP/2FA təlimatı və demo məlumatı hazırlanıb.
- Screenshot, məxfilik açıqlamaları, data collection və store metadata aktualdır.
- Crash monitoring dashboard, alert kanalı və məsul şəxslər relizdən əvvəl aktivdir.
- Rollback qərarını verən şəxs və kommunikasiya mətnləri müəyyən olunub.
Mərhələli mobil app rollout necə idarə edilməlidir?
Mərhələli yayım yalnız faiz seçmək deyil; müşahidə və qərar dövrüdür. Google Play update relizlərində rollout faizini artırmağa, dayandırmağa və davam etdirməyə imkan verir. Apple-da automatic updates üçün phased release yeddi gün ərzində tədricən genişlənir, lakin istifadəçi yeniləməni əl ilə dərhal da yükləyə bilər. Buna görə 1% istifadəçi üçün belə production-a hazır backend, support və insident prosesi lazımdır.
Hər mərhələ üçün ölçülə bilən davam/dayandır meyarları yazın: əvvəlki versiya ilə müqayisədə crash-free sessiya, ANR, login uğuru, API error rate, checkout və ya əsas conversion axınının tamamlanması, support müraciətlərinin mövzusu. Təkcə orta göstəriciyə baxmayın; OS versiyası, cihaz ailəsi, ölkə, tətbiq versiyası və istifadəçi segmenti üzrə fərqləri araşdırın.
- Əvvəl daxili test və məhdud beta qrupunda kritik ssenariləri yoxlayın.
- Kiçik production cohort ilə başlayın və müşahidə pəncərəsini təyin edin.
- Texniki və biznes metrikləri normal olduqda faiz artımı edin.
- Siqnal pisləşdikdə rollout-u dayandırın, flag ilə funksiyanı söndürün və səbəbi araşdırın.
- İstifadəçilər artıq zədələnmiş build-dədirsə, düzəliş relizi və aydın support kommunikasiyası hazırlayın.
Praktik mobile app rollback strategy
Rollback tək bir düymə və ya mağazadan versiyanı silmək deyil. Google Play-də rollout-un dayandırılması yeni istifadəçilərin problemli versiyanı almasını məhdudlaşdırır, lakin artıq yenilənmiş istifadəçiləri əvvəlki binary-yə qaytarmır. Apple-da phased release-i dayandırmaq da eyni məntiqdədir. Buna görə rollback planı dörd ayrı yolu əhatə etməlidir.
- Yayımı dayandırmaq: mərhələli rollout-u halt/pause etmək.
- Davranışı söndürmək: feature flag, remote config və ya server-side kill switch ilə riskli funksiyanı bağlamaq.
- Backend-i geri uyğun saxlamaq: əvvəlki tətbiq versiyasının API kontraktını və əsas məlumat formatlarını qorumaq.
- Düzəliş versiyasını göndərmək: minimal, fokuslu patch build hazırlamaq, yenidən test etmək və mağaza prosesinə təqdim etmək.
Məsələn, yeni checkout ekranı tətbiqdə açılır, amma müəyyən Android cihazlarında ödəniş provider callback-i işləmir. Doğru ilk addım bütün backend-i geri almaq deyil. Rollout dayandırılır, yeni checkout flag ilə söndürülür, köhnə axın saxlanılır, təsirlənən sessiyalar ölçülür və patch hazırlanır. Əgər problem API cavabındadırsa, əvvəl köhnə mobil müştəri ilə uyğun server cavabı bərpa edilir.
Production support: relizdən sonra kim nə edir?
Mobil app production support release günü bitmir. Növbətçilik və eskalasiya modeli, alert hədləri, log və crash hesabatına giriş, store review cavabları, istifadəçi müraciətlərinin prioriteti, status update tezliyi və post-incident review əvvəlcədən razılaşdırılmalıdır. Komanda həm texniki simptomu, həm də istifadəçi təsirini eyni anda izah edə bilməlidir.
POLADO release engineering işini CI/CD, təhlükəsiz konfiqurasiya, store release management, müşahidə, support prosedurları və backend uyğunluğunu birləşdirən xidmət kimi təqdim edir. Mövcud tətbiqinizdə buraxılışlar əl ilə aparılırsa, signing açarlarının sahibliyi qeyri-müəyyəndirsə, store submit-lər gecikirsə və ya production insidentində kimin qərar verdiyi bilinmirsə, texniki dəstək və konsaltinq komandamızla release audit və praktik təkmilləşdirmə planını müzakirə edin.