ایپ ڈویلپمنٹ میں یوم اجرا: جوہر، مراحل اور تیاری
یوم اجرا (release day) موبائل ایپ کے نئے ورژن کی اجرا کی طے شدہ تاریخ ہے، جس میں بلڈ کی تیاری، اسٹور کا جائزہ، مرحلہ وار رول آؤٹ اور نگرانی شامل ہے۔ iOS ایپس کے لیے، عمل ایپل کے لازمی جائزے کی وجہ سے منصوبہ بند اجرا کی تاریخ سے 24-48 گھنٹے پہلے App Store Connect میں بلڈ اپ لوڈ کرنے سے شروع ہوتا ہے۔ Android کے لیے، بلڈ کو Google Play Console میں اسمبل اور اپ لوڈ کیا جاتا ہے، جہاں جائزے کے عمل میں عام طور پر 1-4 گھنٹے لگتے ہیں۔ Apple Developer Guidelines (2025) کے مطابق، 90% بلڈ 24 گھنٹے کے اندر جائزہ پاس کر لیتے ہیں۔ مرحلہ وار رول آؤٹ اشاعت کے بعد غلطیاں ملنے پر اثر کو کم کرنے میں مدد کرتا ہے۔
اہم نکات
- یوم اجرا — بلڈ کی تیاری سے لے کر رول آؤٹ کے بعد نگرانی تک سرگرمیوں کا مجموعہ
- مرحلہ وار رول آؤٹ — بتدریج رول آؤٹ: 1%، 10%، 50%، 100%
- اسموک ٹیسٹنگ — اسٹور میں بھیجنے سے پہلے بلڈ کا حتمی معائنہ
- رول بیک منصوبہ — سنگین غلطیوں کے لیے پہلے سے تیار کردہ رول بیک منظرنامہ
- اجرا کا جائزہ — 100% رول آؤٹ مکمل ہونے کے بعد عمل کا تجزیہ
یوم اجرا کیا ہے اور اس کی تیاری کیسے کریں
یوم اجرا صرف شائع کرنے کے بٹن کو دبانے کا لمحہ نہیں ہے۔ یہ ایک مربوط عمل ہے جس میں ڈویلپرز، QA، DevOps، پروڈکٹ مینیجرز اور کبھی کبھی سپورٹ ٹیم شامل ہوتی ہے۔ تیاری یوم اجرا سے 2-3 ہفتے پہلے شروع ہوتی ہے: دائرہ کار پر اتفاق، کوڈ فریز، ریگریشن ٹیسٹنگ، اجرا نوٹس اور مارکیٹنگ کے مواد کی تیاری۔ تیاری جتنی زیادہ مکمل ہوگی، یوم اجرا اتنا ہی آسانی سے گزرے گا۔
یوم اجرا کی تیاری کی جانچ پڑتال کی فہرست میں شامل ہے: اجرا بلڈ پر حتمی QA رن (ریگریشن + اسموک سویٹ)؛ اسٹورز میں میٹا ڈیٹا کی جانچ (نام، تفصیل، اسکرین شاٹس، کلیدی الفاظ)؛ پروڈکٹ مینیجر کے ساتھ مرحلہ وار رول آؤٹ فیصد پر اتفاق؛ رول بیک منصوبہ تیار کرنا (کون سا ٹیگ دوبارہ تعینات کرنا ہے، اس میں کتنا وقت لگے گا)؛ آنے والے اجرا کے بارے میں ٹیم اور متعلقہ خدمات کو مطلع کرنا۔ اجرا کی جانچ پڑتال کی فہرست CI/CD کے ذریعے خودکار ہونی چاہیے — مثال کے طور پر، GitHub Actions ورک فلو کے طور پر جو اجرا ٹیگ بنانے سے پہلے تمام نکات کی جانچ کرتا ہے۔
تیاری کا ایک اہم عنصر بلیک آؤٹ مدت (blackout period) ہے — وہ مدت جب پروڈکشن میں تعیناتی ممنوع ہوتی ہے۔ عام طور پر، بلیک آؤٹ یوم اجرا سے 48 گھنٹے پہلے نافذ کیا جاتا ہے اور کامیاب 100% رول آؤٹ کے 24 گھنٹے بعد ہٹا دیا جاتا ہے۔ تبدیلی فریز بلیک آؤٹ مدت کے دوران اجرا سے متعلق تمام خدمات پر لاگو ہوتا ہے۔
بلڈ کی تیاری: کوڈ فریز، ٹیگنگ اور اسمبلی
یوم اجرا سے 24-48 گھنٹے پہلے، کوڈ فریز نافذ کیا جاتا ہے — کوڈ میں تبدیلیوں کی مکمل روک۔ ڈویلپرز دستاویزات اور اجرا نوٹس کی تیاری پر توجہ دیتے ہیں۔ DevOps ایک مقررہ ٹیگ (مثلاً v2.6.0-rc1) سے اجرا بلڈ تیار کرتا ہے۔ بلڈ مکمل ریگریشن سویٹ (خودکار + دستی ٹیسٹ) سے گزرتا ہے۔ اگر سنگین بگز ملتے ہیں، تو انہیں کوڈ فریز سے پہلے ٹھیک کیا جاتا ہے یا اجرا ملتوی کر دیا جاتا ہے۔ اجرا کا امیدوار (RC) — وہ بلڈ جو QA پاس کر چکا ہے اور اسٹور میں بھیجنے کے لیے تیار ہے۔
Git میں ٹیگنگ: ایک تشریح شدہ ٹیگ بنایا جاتا ہے (git tag -a v2.6.0 -m “Release v2.6.0”)۔ CI/CD پائپ لائن Google Play کے لیے AAB (Android App Bundle) اور Apple App Store کے لیے IPA (iOS App Store Package) بناتی ہے۔ بلڈ کے ساتھ منسلک ہوتے ہیں: چیکسم فائل (SHA256)، تبدیلی لاگ اور معلوم مسائل کی فہرست (known issues)۔ دوبارہ قابل تولید بلڈ — ایک مثالی عمل جہاں اسی ٹیگ سے دوبارہ بلڈ کرنے پر بائنری طور پر ایک جیسا نتیجہ ملتا ہے۔
bash
# اجرا پائپ لائن — ٹیگ کی تخلیق اور بلڈ
# فرض کرتا ہے کہ کوڈ فریز پہلے سے فعال ہے
# develop سے اجرا برانچ بنائیں
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# کوڈ فریز: برانچ کے تحفظ کے قوانین نئے PRs کو روکتے ہیں
# CI/CD میں ریگریشن سویٹ چلائیں
./gradlew clean testReleaseUnitTest connectedReleaseTest
# کامیاب QA کے بعد اجرا ٹیگ بنائیں
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# CI/CD کے ذریعے اجرا بائنری بنائیں
# fastlane build_release AAB + universal APK تیار کرتا ہے
fastlane build_releaseاہم: ورژن بمپ (ورژن کوڈ اور ورژن نام کو اپ ڈیٹ کرنا) کوڈ فریز سے پہلے کیا جاتا ہے۔ کوڈ فریز کے بعد، ورژن تبدیل نہیں ہوتا۔ Android کے لیے: versionCode — یکسانیت سے بڑھنے والا عدد؛ versionName — معنوی ورژن (2.6.0)۔ iOS کے لیے: CFBundleVersion (بلڈ نمبر) اور CFBundleShortVersionString (معنوی ورژن)۔ ورژننگ gradle/xcconfig میں خودکار ہونی چاہیے۔
اسٹور میں اپ لوڈ اور جائزے کا عمل
iOS کے لیے: بلڈ Xcode، Transporter یا fastlane کے ذریعے App Store Connect میں اپ لوڈ کیا جاتا ہے۔ اپ لوڈ کے بعد، بلڈ Apple کے خودکار معائنے (processing) سے گزرتا ہے، پھر دستی جائزے کے لیے بھیجا جاتا ہے۔ اوسط جائزہ وقت 24 گھنٹے ہے، لیکن Apple جائزہ لینے والوں کے کام کے بوجھ اور تعمیل کی ضروریات کے لحاظ سے 1 گھنٹے سے 7 دن تک مختلف ہو سکتا ہے۔ تیز رفتار جائزہ — سنگین بگ فکسز کے لیے تیز رفتار جائزے کی درخواست (مہینے میں ایک بار سے زیادہ دستیاب نہیں، ضمانت نہیں)۔
Android کے لیے: بلڈ Google Play Console کے ذریعے اپ لوڈ کیا جاتا ہے۔ Google ایک مشترکہ نقطہ نظر استعمال کرتا ہے: خودکار جانچ (رسائی، میلویئر، پالیسی کی تعمیل) + انتخابی دستی جائزہ۔ اوسط جائزہ وقت 1-4 گھنٹے ہے۔ اندرونی ٹیسٹ ٹریک اور بند ٹریک پروڈکشن ٹریک پر اشاعت سے پہلے حتمی جانچ کی اجازت دیتے ہیں۔ سفارش: اندرونی ٹیسٹ میں 1-2 دن → بند بیٹا میں 1 دن → بتدریج پروڈکشن رول آؤٹ۔
دونوں پلیٹ فارمز کے لیے، بلڈ اپ لوڈ کرنے سے پہلے میٹا ڈیٹا کی جانچ کرنا بہت ضروری ہے: ایپ کا نام، تفصیل (مختصر + مکمل)، ہر معاون ڈیوائس کے لیے اسکرین شاٹس (iPhone 6.5″، 5.5″، iPad، Android فون، ٹیبلیٹ)، کلیدی الفاظ (iOS) یا اسٹور لسٹنگ تجربات (Android)۔ میٹا ڈیٹا میں غلطی جائزے میں ایک اضافی دن تاخیر کر سکتی ہے۔ ایپ میٹا ڈیٹا تمام معاون زبانوں میں مقامی ہونا چاہیے۔
مرحلہ وار رول آؤٹ: بغیر خطرے کے اجرا کو کیسے رول آؤٹ کریں
مرحلہ وار رول آؤٹ (بتدریج رول آؤٹ، مرحلہ وار تعیناتی) ایک حکمت عملی ہے جہاں نیا ورژن صارفین کے لیے ایک بار میں نہیں بلکہ مرحلہ وار دستیاب ہوتا ہے۔ ایک پختہ ٹیم کے لیے عام نمونہ: 1% صارفین (پہلے 2-4 گھنٹے) → 10% (24 گھنٹے) → 25% (24 گھنٹے) → 50% (24 گھنٹے) → 100%۔ ہر مرحلے میں میٹرکس کی نگرانی اور سنگین غلطیوں کی عدم موجودگی کی جانچ شامل ہے۔ مرحلہ وار رول آؤٹ اجرا کے دوران خطرے کو کم کرنے کا بنیادی ذریعہ ہے۔
Google Play Console مربوط مرحلہ وار رول آؤٹ فراہم کرتا ہے: آپ صارفین کا فیصد متعین کر سکتے ہیں اور بتدریج اضافہ طے کر سکتے ہیں۔ iOS App Store Connect کے لیے، ایسی کوئی مربوط خصوصیت نہیں ہے — مرحلہ وار رول آؤٹ مرحلہ وار اجرا (7 دنوں میں خودکار کوریج میں اضافہ جسے روکا جا سکتا ہے) یا جغرافیائی تقسیم کے ساتھ سرور سائیڈ فیچر فلیگ کے ذریعے لاگو کیا جاتا ہے۔ مرحلہ وار اجرا App Store Connect میں مسائل ملنے پر اجرا کو روکنے کی اجازت دیتا ہے۔
اگلے مرحلے میں جانے کے لیے کلیدی میٹرکس: کریش فری شرح (نئے اجرا کے لیے ≥99.9%)، ANR شرح (Android، ≤0.1%)، بیک اینڈ API پر غلطی کی شرح (≤0.5% 5xx)، صارفین کی درجہ بندی (پچھلے ورژن سے کم نہیں)، apdex سکور (≥0.94)۔ اگر کوئی بھی میٹرک حد سے تجاوز کرتا ہے تو، وجہ معلوم ہونے تک رول آؤٹ روک دیا جاتا ہے۔ Go/no-go گیٹ ہر مرحلے پر اجرا مینیجر یا آن کال انجینئر کی ذمہ داری ہے۔
اجرا کے بعد نگرانی: پہلے گھنٹوں میں کیا دیکھیں
اجرا کے بعد پہلے 4 گھنٹے سب سے اہم وقت ہوتے ہیں۔ ٹیم کریش کی شرح (Sentry، Firebase Crashlytics، App Center)، بیک اینڈ پر 5xx غلطی کی شرح، حسب ضرورت واقعات (کامیاب ادائیگیاں، لاگ ان، رجسٹریشن)، App Store اور Google Play میں صارفین کی درجہ بندی اور سوشل میڈیا حوالہ جات (Twitter، Reddit) کی نگرانی کرتی ہے۔ نگرانی کا ڈیش بورڈ پہلے سے تیار ہونا چاہیے اور دفتر میں ایک بڑی اسکرین پر یا مخصوص Slack چینل میں دستیاب ہونا چاہیے۔ اجرا ڈیش بورڈ — تمام اجرا میٹرکس کے لیے ایک ہی پینل۔
خاص توجہ ریگریشن میٹرکس پر: اسی مدت میں پچھلے ورژن کے ساتھ کریش کی شرح کا موازنہ۔ اگر کریش کی شرح 0.1% سے زیادہ بڑھ گئی ہے، تو یہ ایک سرخ جھنڈا ہے جس کے فوری تجزیہ کی ضرورت ہے۔ اہم API اینڈ پوائنٹس کی میڈین اور p95 لیٹنسی کا موازنہ کرنا بھی ضروری ہے: کریش کے بغیر بھی، جوابی وقت میں 200ms کا اضافہ کسی مسئلے کا اشارہ ہو سکتا ہے۔ میٹرکس موازنہ (بیس لائن بمقابلہ موجودہ) Datadog یا Grafana میں خودکار ہوتا ہے۔
صارفین کا تاثر عددی میٹرکس جتنا ہی اہم ہے۔ اجرا کے بعد پہلے گھنٹوں میں، صارفین اسٹورز میں فعال طور پر جائزے چھوڑتے ہیں اور سپورٹ کو لکھتے ہیں۔ ٹیسٹوں میں نہ پکڑے گئے بگز جائزوں میں جلدی سامنے آتے ہیں۔ ٹیم لیڈ یا ایک مقرر کردہ QA انجینئر پہلے 4 گھنٹوں میں ہر 30 منٹ بعد جائزوں کی نگرانی کرتا ہے اور انہیں درجہ بند کرتا ہے: غلط مثبت، معلوم مسئلہ (پہلے سے known issues کی فہرست میں)، نیا بگ۔ نئے بگز P0/P1 — رول آؤٹ روکنے کا محرک۔
رول بیک: اجرا کو کب اور کیسے واپس لیا جائے
رول بیک سنگین مسائل ملنے پر پچھلے مستحکم ورژن پر واپس جانا ہے۔ رول بیک کا فیصلہ اجرا مینیجر تکنیکی لیڈ کے ساتھ مل کر لیتا ہے اگر: نئے اجرا کی کریش فری شرح 99% سے نیچے گر جائے، ڈیٹا لیک کا پتہ چلے، اہم فعالیت (ادائیگیاں، تصدیق) 5% سے زیادہ صارفین کے لیے کام نہ کرے، یا اسٹور (App Store Review) نے اشاعت کے بعد بلڈ مسترد کر دیا ہو۔ رول بیک محرک اجرا سے پہلے متعین کیا جانا چاہیے تاکہ فیصلہ جذبات کی بجائے حقائق پر مبنی ہو۔
Android کے لیے: Google Play Console میں رول بیک کا مطلب مرحلہ وار رول آؤٹ روکنا اور پچھلے ورژن پر سوئچ کرنا ہے۔ اگر موجودہ بلڈ پہلے سے 100% صارفین پر ہے تو، پچھلے ورژن کو نئے اجرا کے طور پر شائع کریں۔ iOS کے لیے: App Store Connect کے ذریعے — مرحلہ وار اجرا → اجرا روکیں → اصلاح کے ساتھ نیا ورژن جاری کریں (App Store پچھلے ورژن پر واپس جانے کی اجازت نہیں دیتا)۔ iOS رول بیک زیادہ پیچیدہ ہے: ڈویلپر کو revert commits کے ساتھ نیا بلڈ تیار کرنا ہوگا اور دوبارہ جائزے سے گزرنا ہوگا۔
رول بیک کے بعد، ٹیم واقعہ موڈ میں چلی جاتی ہے: بنیادی وجہ کا تجزیہ، ہاٹ فکس یا اصلاح کے ساتھ اگلا اجرا، پوسٹ مارٹم۔ رول بیک ناکامی نہیں بلکہ ایک معیاری طریقہ کار ہے۔ وہ ٹیمیں جنہوں نے کبھی رول بیک نہیں کیا، وہ ممکنہ طور پر مسائل کو محسوس نہیں کر رہی ہیں، بگ سے پاک اجرا نہیں کر رہی ہیں۔ رول بیک کی شرح DORA میٹرکس میں سے ایک ہے: اعلی کارکردگی والی ٹیمیں 10% سے کم اجرا میں رول بیک کرتی ہیں اور 1 گھنٹے سے کم وقت میں بحال ہو جاتی ہیں۔
اکثر پوچھے گئے سوالات
موبائل ایپ جاری کرنے کے لیے بہترین دن کون سا ہے؟
بہترین دن منگل، بدھ یا جمعرات ہیں۔ پیر کو ہفتے کے آخر سے زیادہ ٹریفک ہوتی ہے، اور جمعہ کو مسئلہ والے اجرا کے ساتھ ہفتے کے آخر میں جانے کا خطرہ ہوتا ہے۔ جمعہ سے بچیں: اگر تعیناتی کے بعد کوئی مسئلہ ملتا ہے تو، ٹیم اسے ہفتے کے آخر میں ٹھیک کرے گی یا پیر تک انتظار کرے گی۔
اگر App Store Review بلڈ مسترد کر دے تو کیا کریں؟
Resolution Center میں مسترد کرنے کی وجہ پڑھیں، اسے ٹھیک کریں اور بلڈ دوبارہ اپ لوڈ کریں۔ عام وجوہات: ٹوٹے ہوئے لنکس، نامکمل فیلڈز، بغیر سبسکرپشن کے مواد (اگر ضروری ہو)، پرانے اسکرین شاٹس۔ App Review مستردی اجرا میں 24-48 گھنٹے تاخیر کرتی ہے، لہذا پہلا بلڈ اپ لوڈ منصوبہ بند اجرا کی تاریخ سے 3-5 دن پہلے ہونا چاہیے۔
شروع کرنے کے لیے مرحلہ وار رول آؤٹ کا کتنا فیصد بہترین ہے؟
بڑے اجرا (اہم تبدیلیاں) کے لیے — 1%۔ پیچ اجرا کے لیے — 5-10%۔ پہلا مرحلہ اتنا چھوٹا ہونا چاہیے کہ غلطی کی صورت میں اثر کم سے کم ہو، لیکن اتنا بڑا کہ شماریاتی لحاظ سے اہم میٹرکس حاصل کیے جا سکیں۔ 10 ملین صارفین والی ایپ کے لیے 1% کا مطلب 100,000 لوگ ہیں — سنگین مسائل کا پتہ لگانے کے لیے کافی ہے۔
کیا اجرا پارٹی کرنی چاہیے؟
اجرا پارٹی (ٹیم جشن) اختیاری ہے لیکن حوصلے کے لیے فائدہ مند ہے۔ بلڈ اپ لوڈ کرنے کے لمحے کے بجائے کامیاب 100% رول آؤٹ کے بعد کرنا بہتر ہے۔ اجرا جشن کو اجرا کے جائزے کے ساتھ ملایا جا سکتا ہے تاکہ بحث کی جا سکے کہ کیا اچھا ہوا اور کیا بہتر کیا جا سکتا ہے۔
“اجرا یا ملتوی” کے فیصلے کا ذمہ دار کون ہے؟
ذمہ داری اجرا مینیجر (عام طور پر ایک سینئر انجینئر یا تکنیکی لیڈ) پر ہے۔ فیصلہ ڈیڈ لائن کی بجائے اجرا ڈیش بورڈ کے اعداد و شمار کی بنیاد پر کیا جاتا ہے۔ اجرا مینیجر کو اجرا میں تاخیر کرنے کا اختیار ہے اگر میٹرکس go/no-go گیٹ پاس نہ کریں۔
خلاصہ
- یوم اجرا — کوڈ فریز سے رول آؤٹ کے بعد نگرانی تک مربوط عمل
- تیاری — اجرا کا امیدوار، QA رن، میٹا ڈیٹا جانچ، رول بیک منصوبہ
- مرحلہ وار رول آؤٹ — 1% → 10% → 25% → 50% → 100% ہر مرحلے پر go/no-go گیٹ کے ساتھ
- نگرانی — کریش فری شرح، ANR، 5xx غلطی کی شرح، پہلے 4 گھنٹوں میں صارفین کی درجہ بندی
- رول بیک — کریش فری شرح 99% سے نیچے گرنے پر معیاری طریقہ کار
- مواصلت — اجرا سے پہلے اور بعد میں ٹیم اور اسٹیک ہولڈرز کو مطلع کرنا
- اجرا کا جائزہ — 100% رول آؤٹ مکمل ہونے کے بعد عمل کا جائزہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں