Firebase ایپ کی تعیناتی، Google Play، TestFlight، اور App Store Connect کے لیے Fastlane اور GitHub ایکشنز کا استعمال کرتے ہوئے فلٹر ریلیز کو خودکار کیسے بنایا جائے۔

یہ جمعہ کو شام 4 بجے ہے اور ٹیم نے ابھی سپرنٹ کی آخری خصوصیت کو ضم کیا ہے۔ تاہم، پروڈکٹ مینیجر دن کے آخر تک TestFlight سے ایک نئی تعمیر کی درخواست کرتا ہے تاکہ کلائنٹ ہفتے کے آخر میں اس کا جائزہ لے سکے۔

ایکس کوڈ کھولیں، آرکائیو کے مکمل ہونے کا انتظار کریں، کوڈ پر دستخط کرنے والی کسی بھی غلطی کو ہینڈل کریں جو کل وہاں نہیں تھیں، انہیں ٹھیک کریں، دوبارہ آرکائیو کریں، دوبارہ انتظار کریں، اپ لوڈ کریں، اور ایپ اسٹور کنیکٹ کے اس کی دیکھ بھال کرنے کا انتظار کریں۔ پھر اینڈرائیڈ پر بھی ایسا ہی کریں، لیکن اب اینڈرائیڈ اسٹوڈیو کے ذریعے۔ اپنے APK پر دستخط کریں، فائر بیس ایپ ڈسٹری بیوشن میں لاگ ان کریں، فائلیں گھسیٹیں، ٹیسٹرز شامل کریں، ریلیز نوٹس لکھیں، اور بھیجیں کو دبائیں۔

اب شام کے 6:45 بجے ہیں۔ میں نے دو گھنٹے میں پروڈکٹ کوڈ کی ایک لائن بھی نہیں لکھی۔ یہ ہر ریلیز سائیکل پر ہوتا ہے۔

اب متبادل پر غور کریں۔ کوڈ dev درخت کی شاخیں۔ GitHub کے سرورز آپ کے لیے کرتے ہیں۔ منٹوں میں، آپ کا الگ تھلگ کلاؤڈ ماحول آپ کے کوڈ کی تصدیق کرتا ہے، فلٹر انسٹال کرتا ہے، خفیہ کردہ رازوں سے دستخط کرنے والے اسناد کو ڈی کوڈ کرتا ہے، APKs اور IPAs بناتا ہے، اور Android ٹیسٹرز کے لیے Firebase ایپ کی تعیناتی اور iOS ٹیسٹرز کے لیے TestFlight کو بیک وقت تعینات کرتا ہے۔ آپ پہلے ہی گھر پر ہیں۔ اطلاعات خود بخود ٹیسٹرز کو پہنچ جاتی ہیں۔

یہ وہ پائپ لائن ہے جو یہ ہینڈ بک بناتی ہے۔

اس گائیڈ کے آخر تک dev Firebase ایپ کی تعیناتی اور TestFlight پر خودکار طور پر تعمیرات تعینات کریں۔ ہدف کو دبائیں prod Google Play Store اور Apple App Store پر تقسیم کیا گیا۔ IPAs کی دستی برآمد یا APKs کو دوبارہ اپ لوڈ نہیں کرنا۔

ٹولز جو اس کو ممکن بناتے ہیں وہ ہیں GitHub ایکشنز، جو آٹومیشن کو چلانے کے لیے کلاؤڈ مشین مہیا کرتی ہے، اور Fastlane، جو کہ تعمیر، دستخط اور تعیناتی منطق کو سنبھالتی ہے۔ اس ہینڈ بک میں، دونوں کو پروڈکشن انفراسٹرکچر سمجھا جاتا ہے جس کے لیے وہی انتظام اور دستاویزات کی ضرورت ہوتی ہے جیسا کہ خود ایپ۔

انڈیکس

شرطیں

شروع کرنے سے پہلے، یقینی بنائیں کہ درج ذیل درست ہیں: ان میں سے کسی کو چھوڑنے کے نتیجے میں ایسی غلطیاں پیدا ہوں گی جن کی تشخیص مشکل ہے۔

1. GitHub ذخیرہ کے ساتھ ایک موجودہ فلٹر پروجیکٹ: اس منصوبے کو پہلے سے ہی مقامی طور پر تعمیر کیا جانا چاہئے. اگر flutter build apk --release اور flutter build ios --release --no-codesign اگر دونوں آپ کے کمپیوٹر پر کامیاب ہو جاتے ہیں، تو آپ تیار ہیں۔

2. ایڈمنسٹریٹر یا اکاؤنٹ کے مالک کے کردار کے ساتھ ایپل ڈویلپر اکاؤنٹ: آپ کو ایک App Store Connect API کلید بنانے کے لیے اس معلومات کی ضرورت ہوگی۔ ایک ڈویلپر کا کردار کافی نہیں ہے۔

3. ایک Google Play Console اکاؤنٹ جس میں ایک شائع شدہ ایپ ڈرافٹ اسٹیٹس یا اس سے زیادہ ہے: گوگل پلے API ان ایپس کو آگے نہیں بڑھا سکتا جن کا کبھی کوئی ورژن اپ لوڈ نہیں ہوا ہے۔ اگر آپ کی ایپس اپ ٹو ڈیٹ ہیں، تو آٹومیشن شروع ہونے سے پہلے آپ کو ایپ کی فہرست بنانے کے لیے ایک بار دستی اپ لوڈ کرنے کی ضرورت ہوگی۔

4. فائر بیس پروجیکٹ Firebase ایپ کی تقسیم Android اور iOS دونوں کے لیے فعال ہے۔

5. روبی آپ کے ترقیاتی کمپیوٹر پر انسٹال ہے: فاسٹ لین ایک روبی منی ہے۔ چلائیں ruby -v چیک کریں۔ macOS روبی کے ساتھ بھیجتا ہے، لیکن یہ اکثر پرانا ہوتا ہے۔ ہومبریو کے ذریعے موجودہ ورژن انسٹال کریں۔ brew install ruby.

6. مقامی طور پر نصب فاسٹ لین: کے ساتھ انسٹال کریں۔ gem install fastlane. آپ اسے اپنے ٹرمینل میں سیٹ اپ کے دوران استعمال کریں گے اس سے پہلے کہ CI سرور سنبھال لے۔

7. ہومبریو میک او ایس پر انسٹال ہے: مقامی طور پر انحصار کو انسٹال کرنے کے لیے استعمال کیا جاتا ہے۔

8. استعمال میں آسان ٹرمینل: اس گائیڈ کے تمام مراحل میں چلانے والی کمانڈز شامل ہیں۔ زیادہ تر معاملات میں کوئی GUI متبادل نہیں ہے۔

CI/CD کیا ہے اور آپ کی فلٹر ایپ کو اس کی ضرورت کیوں ہے؟

تصور

CI/CD کا مطلب ہے مسلسل انضمام اور مسلسل ترسیل۔ کلید کوڈ لکھنے اور اس کوڈ کو صارفین تک پہنچانے کے مراحل کو خودکار بنانا ہے۔ مسلسل انضمام کا مطلب یہ ہے کہ تمام کوڈ کی تبدیلیاں خود بخود تیار اور جانچ کی جاتی ہیں۔ مسلسل ترسیل کا مطلب ہے کہ تمام کامیاب تعمیرات خود بخود تعیناتی کے لیے تیار ہو جاتی ہیں۔

خاص طور پر موبائل کی ترقی کے لیے، یہ سافٹ ویئر کے تقریباً کسی بھی دوسرے شعبے سے زیادہ اہم ہے۔ موبائل کی تعمیرات پیچیدہ ہیں۔ سرٹیفکیٹس، پروویژننگ پروفائلز، کی سٹور فائلز، اور API کیز کا استعمال کرتے ہوئے کوڈ پر دستخط کرنے کی ضرورت ہوتی ہے جنہیں تعمیر کے کامیاب ہونے کے لیے بالکل صحیح طریقے سے جوڑا جانا چاہیے۔ دستی طور پر ایسا کرنا غلطی کا شکار ہے۔ آٹومیشن چیزوں کو قابل اعتماد اور دہرانے کے قابل بناتا ہے۔

دستی تعیناتی کیوں اہمیت رکھتی ہے۔

اگر تعیناتی دستی ہے، تو وقت کے ساتھ ساتھ کئی چیزیں ہوتی ہیں: سب سے پہلے، یہ ایک خصوصی مہارت بن جاتی ہے۔ صرف ایک یا دو لوگ جنہوں نے پہلے یہ کیا ہے اقدامات کو جانیں گے، اور اس شخص کے بغیر ٹیم ڈیلیور نہیں کر سکتی۔

دوسرا، یہ متضاد ہے۔ ایک شخص کی طرف سے اپنے لیپ ٹاپ پر تیار کی گئی تعمیر میں ماحول کے متغیرات یا ایکس کوڈ سیٹنگز ان کے لیپ ٹاپ پر کسی دوسرے شخص کی طرف سے تیار کی گئی تعمیر سے قدرے مختلف ہو سکتی ہیں۔

تیسرا، یہ سست ہے۔ تعمیر، آرکائیو، اور اپ لوڈ انتظار کے کھیل ہیں جو حقیقی انجینئرنگ کے کام کے بہاؤ میں خلل ڈالتے ہیں۔

آٹومیشن تینوں کو حل کرتی ہے۔ اقدامات ورژن کنٹرول فائل میں ریکارڈ کیے جاتے ہیں۔ چونکہ یہ ایک نئی کلاؤڈ مشین ہے جو ان فائلوں کے ساتھ ترتیب دی گئی ہے، اس لیے ماحول ہر رن کے لیے یکساں ہے۔ اور جب آپ اگلی خصوصیت پر کام کریں گے تو یہ عمل پس منظر میں چلے گا۔

فن تعمیر: سب کچھ کیسے جوڑتا ہے۔

کسی کنفیگریشن فائل کو چھونے سے پہلے، مجموعی نظام کو سمجھیں اور اس کے تمام اجزاء ایک ساتھ کیسے فٹ ہوتے ہیں۔ اگر آپ اس تصویر کے بغیر بناتے ہیں تو آپ کو معلوم نہیں ہوگا کہ کہاں دیکھنا ہے اور آپ کی ڈیبگنگ ناکام ہوجائے گی۔

گٹ ہب آپریشنز یہ کلاؤڈ بیسڈ ورچوئل مشین مہیا کرتا ہے جسے رنر کہتے ہیں۔ ہر بار جب آپ کنفیگرڈ برانچ کی طرف دھکیلتے ہیں تو، GitHub ایک نئے ایگزیکیوٹر (Android کے لیے Ubuntu، iOS کے لیے macOS) کو گھماتا ہے، ورک فلو فائل میں قدم چلاتا ہے، اور مکمل ہونے پر مشین کو بند کر دیتا ہے۔ مشین ہر بار مکمل طور پر صاف ہونے لگتی ہے۔

فاسٹ لین موبائل کی تعمیر اور تعیناتی کے کاموں کو خودکار کرنے کے لیے ایک اوپن سورس ٹول۔ یہ GitHub ایکشن لانچر کے اندر چلتا ہے اور پلیٹ فارم کے مخصوص مراحل کو ہینڈل کرتا ہے: ایپ بنڈل بنانا، iOS کوڈ پر دستخط کرنے کا انتظام کرنا، اور بائنریز کو تعیناتی پلیٹ فارم پر اپ لوڈ کرنا۔ آپ فاسٹ لین "لینز” بناتے ہیں (قدموں کی ترتیب کا نام) جسے GitHub ایکشن کہتے ہیں۔

فاسٹ لین میچ iOS کوڈ پر دستخط کرنے کے لیے فاسٹ لین کا سب سسٹم۔ آپ کو اس سسٹم پر انسٹال کرنے کے لیے ایک سرٹیفکیٹ اور پروویژننگ پروفائل کی ضرورت ہوگی جس پر آپ اپنی iOS ایپ بنا رہے ہیں۔ میچ اسے ایک پرائیویٹ، انکرپٹڈ GitHub ریپوزٹری میں اسٹور کرتا ہے اور اسے بنانے سے پہلے آپ کے CI رنر پر ڈاؤن لوڈ کرتا ہے۔ یہ ایک سے زیادہ کمپیوٹرز پر سرٹیفکیٹس کو دستی طور پر منظم کرنے کے ڈراؤنے خواب کو ختم کرتا ہے۔

اپنی Firebase ایپ کو متعین کریں۔ آپ کو بلٹ APK اور IPA فائلیں موصول ہوں گی۔ dev اپنے ماحول کو سمجھیں اور ٹیسٹرز کو خود بخود مطلع کریں۔

ایپ اسٹور کنیکٹ اور گوگل پلے کنسول اس کے لیے پروڈکشن بلڈ حاصل کریں: prod ماحول

سرٹیفکیٹ اسٹور ایک علیحدہ، نجی GitHub ذخیرہ ہے جسے Fastlane Match پڑھتا اور لکھتا ہے۔ ہم آپ کے iOS دستخطی مواد کو ایک پاس ورڈ کے ساتھ انکرپٹڈ رکھتے ہیں جسے صرف آپ جانتے ہیں۔

اسناد اور چابیاں بنائیں

اس سیکشن میں آپ کی CI پائپ لائن کے لیے درکار اسناد جمع کرنے کے لیے متعدد فریق ثالث ڈیش بورڈز کو تلاش کرنا شامل ہے۔

فائر بیس اسناد

Firebase ایپ کو تعینات کرنے کے لیے معلومات کے دو ٹکڑوں کی ضرورت ہوتی ہے: آپ کی ایپ ID اور ایک سروس اکاؤنٹ جو آپ کے CI سرور پر بلڈس اپ لوڈ کرنے کی اجازت دیتا ہے۔

Firebase کنسول پر جائیں اور اپنا پروجیکٹ کھولیں۔

تحریک پروجیکٹ کی ترتیبات (بائیں سائڈبار میں پروجیکٹ کے جائزہ کے آگے گیئر آئیکن)

نیچے سکرول کریں آپ کی ایپ پارٹ ٹائم نوکری. رجسٹرڈ اینڈرائیڈ اور iOS ایپس درج ہیں۔ اسے تلاش کریں اور اسے کاپی کریں۔ ایپ آئی ڈی ہر ایک اینڈرائیڈ ایپ کی شناخت یہ ہے: 1:1234567890:android:abc123def456. iOS ایپ ID ہے: 1:1234567890:ios:abc123def456.

پروجیکٹ کی ترتیبات میں رہنا سروس اکاؤنٹ ٹیگ

کلک کریں نئی نجی کلید بنائیں ڈائیلاگ باکس کو چیک کریں۔ کوئی راستہ نہیں .json فائل آپ کے کمپیوٹر پر ڈاؤن لوڈ ہو جائے گی۔ یہ فائل سروس اکاؤنٹ کی اسناد پر مشتمل ہے۔ اسے محفوظ رکھیں اور اسے کسی بھی ذخیرے کے ساتھ ارتکاب نہ کریں۔

Apple App Store کنکشن API کلید

ایپل نے پاس ورڈ پر مبنی API رسائی کو API کیز سے تبدیل کر دیا ہے۔ آپ کو فاسٹ لین کو ایپ اسٹور کنیکٹ کے ساتھ ایپل آئی ڈی کی اسناد کے بغیر بات چیت کرنے کی اجازت دینے کے لیے ایک کی ضرورت ہوگی۔

ایپ اسٹور کنیکٹ پر جائیں اور یہاں جائیں: صارفین اور رسائی اوپر نیویگیشن سے۔

اگلا پر کلک کریں۔ انضمام ٹیب کو تھپتھپائیں اور پھر اسے منتخب کریں۔ ایپ اسٹور کنکشن API یہ بائیں سائڈبار میں ہے۔

اگلا پر کلک کریں۔ + ایک نئی کلید بنانے کے لیے بٹن پر کلک کریں۔ اسے اس طرح واضح نام دیں: GitHub Actions CI. رسائی کی سطح کو اس پر سیٹ کریں: ایپ مینیجر.

کلید بنانے کے بعد، اس کا ایک نوٹ بنائیں۔ جاری کنندہ کی شناخت صفحہ کے اوپری حصے میں دکھایا گیا ہے۔ کلیدی شناخت یہ کلیدی قطار میں ظاہر ہوتا ہے۔ کلک کریں API کلید ڈاؤن لوڈ کریں۔ بچانے کے لیے .p8 فائل یہ فائل صرف ایک بار ڈاؤن لوڈ کی جا سکتی ہے۔ اگر آپ اسے کھو دیتے ہیں، تو آپ کو ایک نئی کلید بنانے کی ضرورت ہوگی۔

گوگل پلے اسٹور سروس اکاؤنٹ

Google Play API اپ لوڈز کی تصدیق کرنے کے لیے سروس اکاؤنٹ (Google Cloud میں مشین ID) استعمال کرتا ہے۔

Google Cloud Console کھولیں اور یقینی بنائیں کہ آپ Play Console سے منسلک کسی پروجیکٹ میں ہیں۔

اگلے پر جائیں۔ IAM اور منتظمین بائیں سائڈبار میں سروس اکاؤنٹ.

کلک کریں سروس اکاؤنٹ بنائیں. اسے اس طرح واضح نام دیں: github-actions-play-store. رول تفویض سروس اکاؤنٹ صارف. مکمل تخلیق۔

فہرست میں نئے بنائے گئے سروس اکاؤنٹ پر کلک کریں۔ پر جائیں۔ کلید ٹیگ کلک کریں کلید شامل کریں پھر ایک نئی کلید بنائیں. منتخب کریں JSON فارمیٹ کوئی راستہ نہیں .json فائلیں ڈاؤن لوڈ کریں۔

اب اس سروس اکاؤنٹ کو اپنے Play Console سے منسلک کریں۔ گوگل پلے کنسول پر جائیں، ایپ کھولیں اور اس پر جائیں: ترتیب پھر API رسائی. کم از کم، سروس اکاؤنٹ تک رسائی فراہم کریں۔ رہائی کے مینیجر ایپ کو اجازت دیں۔

فاسٹ لین میچنگ سرٹیفکیٹ اسٹور

Fastlane Match ایک سرشار، نجی GitHub ذخیرہ میں iOS کے دستخطی مواد کو اسٹور کرتا ہے۔ اب ایک نیا، مکمل طور پر خالی ذاتی ذخیرہ بنائیں۔ اس کا نام اس طرح رکھیں: your-app-certificates. کسی بھی فائل کے ساتھ شروع نہ کریں۔

اس کے بعد، ہم ایک ذاتی رسائی ٹوکن بناتے ہیں تاکہ فاسٹ لین کو CI ایگزیکیوٹر سے اس ذخیرہ کو پڑھنے اور لکھنے کی اجازت دی جائے۔ اپنے GitHub اکاؤنٹ پر جائیں۔ ترتیبنیچے سکرول کریں اور کلک کریں۔ ڈویلپر کی ترتیبات، پھر کلک کریں۔ ذاتی رسائی کا ٹوکن پھر ٹوکن (کلاسیکی).

ایک نیا کلاسک ٹوکن بنائیں۔ اسے ایک وضاحتی نام دیں، اس طرح: fastlane-match-ci. نیچے رینج منتخب کریں۔چیک کریں ریپو دائرہ کار (جو پورے ذخیرہ تک رسائی فراہم کرتا ہے) کی میعاد ختم ہونے کو کم از کم 1 سال تک مقرر کریں، یا اگر آپ کی سیکیورٹی پالیسی اس کی اجازت دیتی ہے تو کبھی ختم نہ ہو۔ ایک ٹوکن بنائیں اور اسے فوری طور پر کاپی کریں۔ GitHub آپ کو دوبارہ نہیں دکھائے گا۔

نیا تیار کردہ ٹوکن:

پس منظر کی خفیہ کاری: اپنی فائلوں کو نجی بنائیں

GitHub ایکشن سیکرٹس صرف سادہ متن کے تاروں کو قبول کرتے ہیں۔ دستخطی سند ایک بائنری فائل ہے۔ اینڈرائیڈ .jks کیسٹور، ایپل .p8 کلیدی فائلیں اور فائر بیس .json سروس اکاؤنٹ۔ بائنری فائل کو نجی طور پر ذخیرہ کرنے کے لیے، اسے Base64 میں تبدیل کریں۔ یہ بائنری ڈیٹا کو پرنٹ ایبل ASCII حروف کی ایک تار کے طور پر پیش کرنے کا ایک طریقہ ہے۔

اس سیکشن میں تمام کمانڈز ٹرمینل میں چلائی جاتی ہیں۔ ہر کمانڈ کو چلانے کے بعد، نتائج کو کھولیں. .txt فائل کھولیں، اس کے پورے مواد کو کاپی کریں، اور اس سٹرنگ کو کسی محفوظ جگہ پر محفوظ کریں (ایک پاس ورڈ مینیجر اچھی طرح کام کرتا ہے)۔ اسے کاپی کریں اور پھر اسے حذف کریں۔ .txt فائل

اینڈرائیڈ کی اسٹور بنائیں

Android Keystore Play Store میں آپ کی ایپ کی کرپٹوگرافک شناخت ہے۔ اگر آپ کسی مخصوص کی اسٹور کا استعمال کرتے ہوئے اپنی ایپ شائع کرتے ہیں، تو تمام اپ ڈیٹس کو ہمیشہ کے لیے ایک ہی کی اسٹور کا استعمال کرنا ہوگا۔ اس کو کھونے کا مطلب ہے کہ آپ اپنی موجودہ ایپس میں اپ ڈیٹس کو آگے نہیں کر پائیں گے۔ محفوظ طریقے سے بنائیں اور بیک اپ کریں۔

keytool -genkey -v 
  -keystore release-keystore.jks 
  -keyalg RSA 
  -keysize 2048 
  -validity 10000 
  -alias YOUR_KEY_ALIAS 
  -dname "CN=Your Name, OU=App, O=Your Company, L=Your City, ST=Your State, C=US" 
  -storepass "YOUR_SECURE_PASSWORD" 
  -keypass "YOUR_SECURE_PASSWORD"

keytool یہ جاوا ڈویلپمنٹ کٹ کا حصہ ہے اور جاوا کرپٹوگرافک کلیدی اسٹورز کے انتظام کے لیے ایک معیاری ٹول ہے۔ -keystore release-keystore.jks آؤٹ پٹ فائل کا نام بتاتا ہے۔ -keyalg RSA اور -keysize 2048 انکرپشن الگورتھم اور کلید کی لمبائی کی وضاحت کرتا ہے، جو Android سائن کرنے کے لیے معیاری انتخاب ہیں۔

-validity 10000 سرٹیفکیٹ کی میعاد کی مدت تقریباً 27 سال مقرر کی گئی ہے، جو کہ Play Store کیز کے لیے عام طور پر تجویز کردہ قدر ہے۔ -alias YOUR_KEY_ALIAS وہ نام جس سے اس کلید کو کی اسٹور کے اندر حوالہ دیا جائے گا۔ اسے کسی معنی خیز میں تبدیل کریں، جیسے کہ آپ کے ایپ کا نام۔ -dname سرٹیفکیٹ کے مالک کی شناخت کے لیے استعمال ہونے والا ایک منفرد نام۔ تمام اقدار کو اپنی معلومات سے بدل دیں۔

-storepass اور -keypass یہ ہر ایک کی اسٹور فائل اور اس کے اندر موجود کلیدوں کی حفاظت کے لیے ایک پاس ورڈ ہے۔ یہ GitHub Secrets کی ترتیب کو آسان بناتا ہے کیونکہ وہ ایک جیسی ہو سکتی ہیں۔

اب اپنی کی اسٹور فائل کو ایک Base64 سٹرنگ میں تبدیل کریں جسے GitHub Secrets محفوظ کر سکتا ہے۔

base64 -i release-keystore.jks > release-keystore-base64.txt

base64 -i release-keystore.jks بائنری پڑھیں .jks فائل کو بیس 64 سٹرنگ کے طور پر انکوڈ کریں۔ کہ > آپریٹر آؤٹ پٹ کو ری ڈائریکٹ کرتا ہے: release-keystore-base64.txt ٹرمینل پر پرنٹ کرنے کے بجائے۔ اس فائل کو کھولیں، پوری اسٹرنگ (لمبی والی) کو کاپی کریں اور اسے اپنے پاس ورڈ مینیجر میں لیبل کے نیچے محفوظ کریں۔ ANDROID_KEYSTORE_BASE64اور پھر حذف کریں .txt فائل

Apple API کلیدی انکوڈنگ

base64 -i AuthKey_YOUR_KEY_ID.p8 > authkey-base64.txt

تبدیلی AuthKey_YOUR_KEY_ID.p8 درست فائل کے نام کے ساتھ .p8 یہ ایپ اسٹور کنیکٹ سے ڈاؤن لوڈ کی گئی فائل ہے۔ کلیدی ID فائل کے نام میں ہے۔ یہ کمانڈ بائنری کلید فائل کو بیس 64 سٹرنگ میں انکوڈ کرتی ہے۔ کھلا authkey-base64.txtمواد کاپی کریں اور اسے نیچے محفوظ کریں۔ APPSTORE_API_PRIVATE_KEY_BASE64فائل پر کلک کریں اور ڈیلیٹ کریں۔

مماثلت کے لیے GitHub سندی انکوڈنگ

فاسٹ لین میچ HTTP بنیادی توثیق کا استعمال کرتے ہوئے سرٹیفکیٹ اسٹور کی توثیق کرتا ہے، جس کے لیے Base64 انکوڈ شدہ صارف نام اور ٹوکن کی ضرورت ہوتی ہے۔ یہ HTTP بنیادی تصدیق کی معیاری شکل ہے۔

echo -n "YOUR_GITHUB_USERNAME:YOUR_PERSONAL_ACCESS_TOKEN" | base64

echo -n پچھلی نئی لائنوں کے بغیر سٹرنگ پرنٹ کرتا ہے۔ کہ -n جھنڈے بہت اہم ہیں۔ بیس 64 انکوڈنگ میں پچھلی نئی لائن کے حروف شامل ہیں، جو اسناد سے سمجھوتہ کر سکتے ہیں۔ | base64 انٹرمیڈیٹ فائلوں کو لکھے بغیر براہ راست Base64 انکوڈر پر پائپ آؤٹ پٹ۔ انکوڈ شدہ نتائج براہ راست ٹرمینل پر پرنٹ کیے جاتے ہیں۔ کاپی کریں اور نیچے محفوظ کریں۔ MATCH_GIT_BASIC_AUTHORIZATION.

ماحولیاتی فائلوں کو انکوڈنگ کرنا

فلٹر ایپ .env اگر آپ حساس کنفیگریشن کے لیے فائلیں بنانا چاہتے ہیں، جیسے کہ API کیز (جنہیں گٹ کے لیے پابند نہیں کیا جانا چاہیے)، آپ کو ان کو انکوڈ کرنے کی ضرورت ہے تاکہ سی آئی رنر ان کو تعمیر کرنے سے پہلے دوبارہ تشکیل دے سکے۔

base64 -i .env > env-base64.txt

کہ .env فائل کو پروجیکٹ روٹ سے پڑھا جاتا ہے اور اسے بیس 64 کے طور پر انکوڈ کیا جاتا ہے۔ کھلا env-base64.txtمواد کاپی کریں اور اسے نیچے محفوظ کریں۔ ENV_FILE_BASE64فائل پر کلک کریں اور ڈیلیٹ کریں۔ منصوبے میں .env اگر آپ فائل کو حذف کرنا چاہتے ہیں، تو اس مرحلے کو چھوڑ دیں اور اسے بعد میں اپنی GitHub ایکشنز ورک فلو فائل سے ہٹا دیں۔

GitHub ایکشنز سیکرٹ کنفیگریشن

اپنی تمام اسناد کو انکوڈنگ کرنے کے بعد، انہیں اپنے GitHub ریپوزٹری میں اپنے خفیہ ذخیرہ میں شامل کریں۔ یہاں محفوظ کردہ راز آرام سے خفیہ کیے گئے ہیں اور ورک فلو لاگ میں چھپے ہوئے ہیں (جیسا کہ نیچے دکھایا گیا ہے)۔ *** بصورت دیگر، اگر پرنٹ ہو)، GitHub ایکشنز سے باہر چلنے والا کوڈ کبھی قابل رسائی نہیں ہے۔

GitHub پر ذخیرہ میں، پر جائیں: ترتیب اوپر نیویگیشن بار میں

بائیں سائڈبار میں راز اور متغیراتپھر عمل.

کلک کریں نیا ذخیرہ راز ذیل میں ہر ایک راز کے بارے میں۔ ورک فلو فائل ان ناموں کا براہ راست حوالہ دیتی ہے، اس لیے ناموں کو بالکل اسی طرح مماثل ہونا چاہیے جیسا کہ لکھا گیا ہے۔

درج ذیل راز ایک ایک کرکے شامل کریں۔

ماحولیات اور ترتیب:

• ENV_FILE_BASE64: انکوڈنگ کی بیس 64 سٹرنگ۔ .env فائل

فائر بیس اور گوگل پلے:

• FIREBASE_APP_ID_ANDROID: Android ایپ ID Firebase کنسول سے کاپی کی گئی (فارمیٹ: 1:xxx:android:xxx)۔

• FIREBASE_APP_ID_IOS: iOS ایپ ID Firebase کنسول سے کاپی کی گئی۔

• FIREBASE_SERVICE_ACCOUNT_JSON: اپنے Firebase سروس اکاؤنٹ سے خام مواد چسپاں کریں۔ .json براہ راست فائل۔ اس آئٹم کو انکوڈ نہ کریں۔ اپنے ورک فلو میں فائلوں پر براہ راست لکھیں۔

• GOOGLE_PLAY_JSON: اپنے Google Play سروسز اکاؤنٹ کا خام مواد پیسٹ کریں۔ .json براہ راست فائل۔

Android دستخط:

• ANDROID_KEYSTORE_BASE64: انکوڈنگ کی بیس 64 سٹرنگ۔ .jks کلیدی اسٹور فائل۔

• ANDROID_KEY_ALIAS: کی اسٹور بناتے وقت استعمال ہونے والا عرف، جیسے your-app-key)۔

• ANDROID_KEY_PASSWORD: کی اسٹور بناتے وقت یہ کلیدی پاس ورڈ سیٹ ہوتا ہے۔

• ANDROID_STORE_PASSWORD: کی سٹور بناتے وقت یہ سٹور کا پاس ورڈ سیٹ ہوتا ہے۔

ایپل ایپ اسٹور:

• APPSTORE_ISSUER_ID: App Store Connect API کلیدی صفحہ سے جاری کنندہ ID۔

• APPSTORE_API_KEY_ID: App Store Connect API کلیدی صفحہ سے کلیدی ID۔

• APPSTORE_API_PRIVATE_KEY_BASE64: انکوڈنگ کی بیس 64 سٹرنگ۔ .p8 فائل

فاسٹ لین میچز:

• MATCH_GIT_BASIC_AUTHORIZATION:بیس 64 سٹرنگ username:token.

• MATCH_PASSWORD: ایک مضبوط پاس ورڈ جو آپ خود بناتے ہیں۔ یہ میچ اسٹور میں سرٹیفکیٹ کو خفیہ کرنے کے لیے استعمال ہوتا ہے۔ مضبوط پاس ورڈ بنانے کے لیے پاس ورڈ مینیجر کا استعمال کریں۔ براہ کرم اسے محفوظ رکھیں کیونکہ اسے بازیافت نہیں کیا جاسکتا۔ اگر آپ اسے کھو دیتے ہیں، تو آپ کو سرٹیفکیٹ اسٹور کو دوبارہ بنانے کی ضرورت ہوگی۔

اینڈرائیڈ کے لیے فاسٹ لین سیٹ اپ کریں۔

اینڈرائیڈ کے لیے فاسٹ لین android/ آپ کے فلٹر پروجیکٹ کی ڈائرکٹری۔ درج ذیل فائلیں بنائیں:

منی فائل

# android/Gemfile

source "https://rubygems.org"
gem "fastlane"

plugins_path = File.join(File.dirname(__FILE__), 'fastlane', 'Pluginfile')
eval_gemfile(plugins_path) if File.exist?(plugins_path)

source "https://rubygems.org" یہ بنڈلر (روبی کے پیکیج مینیجر) کو بتاتا ہے کہ منی کہاں سے حاصل کرنا ہے۔ gem "fastlane" فاسٹ لین کو انحصار قرار دیں۔

کہ plugins_path لائن اضافی پلگ ان کے اعلانات کو لوڈ کرتی ہے: Pluginfile اگر یہ موجود ہے۔ یہ ڈھانچہ اہم ہے۔ Gemfile پلگ ان کی فہرست کو الگ سے برقرار رکھا جاتا ہے، یہ وہی اصول ہے جس کی فاسٹ لین پروجیکٹ پیروی کرتا ہے۔

ہمیشہ بنڈلر(bundle exec fastlane) کال کرنے سے fastlane بنڈلر اعلان کردہ عین مطابق منی ورژن کی ضمانت دیتا ہے، تو براہ راست Gemfile.lock اسے مشینوں میں تعمیرات کو دوبارہ تیار کرنے کے لیے استعمال کیا جا سکتا ہے۔

گریڈل پراپرٹیز فائل

# android/gradle.properties

org.gradle.jvmargs=-Xmx4G -XX:MaxMetaspaceSize=1G -XX:ReservedCodeCacheSize=512m -XX:+HeapDumpOnOutOfMemoryError

org.gradle.jvmargs گریڈل بنانے کے عمل کے لیے جاوا ورچوئل مشین کے دلائل کو ترتیب دیں۔ -Xmx4G زیادہ سے زیادہ ہیپ میموری کو 4GB پر سیٹ کریں۔ -XX:MaxMetaspaceSize=1G میٹا اسپیس (کلاس میٹا ڈیٹا) کو 1 جی بی تک محدود کریں۔ -XX:ReservedCodeCacheSize=512m مرتب شدہ کوڈ کیشنگ کے لیے 512 MB محفوظ کریں۔ -XX:+HeapDumpOnOutOfMemoryError جب JVM کی میموری ختم ہوجاتی ہے، تو یہ پوسٹ مارٹم ڈیبگنگ میں مدد کے لیے ایک ہیپ ڈمپ فائل تیار کرتا ہے۔

اس کنفیگریشن کے بغیر، GitHub ایکشن رنر گریڈل کی تعمیر کے دوران ایگزٹ کوڈ 137 یا 143 کے ساتھ اکثر ناکام ہو جاتا ہے کیونکہ پہلے سے طے شدہ JVM میموری سیٹنگ معیاری GitHub کے میزبان رنر کی 7GB RAM کی حد سے زیادہ ہے۔

اینڈرائیڈ ایپ فائل

# android/fastlane/Appfile

json_key_file(ENV["FIREBASE_SERVICE_ACCOUNT_JSON_PATH"])
package_name("com.yourcompany.app")

json_key_file(...) Fastlane کو بتائیں کہ Google سروس اکاؤنٹ JSON فائل کہاں تلاش کی جائے جو Google Play تک رسائی فراہم کرتی ہے۔ سے پڑھتا ہے۔ FIREBASE_SERVICE_ACCOUNT_JSON_PATH ماحولیاتی متغیرات GitHub ایکشنز کے ورک فلو کے مراحل میں سیٹ کیے گئے ہیں۔ package_name(...) اپنی ایپ کے پیکیج شناخت کنندہ کا اعلان کریں۔ تبدیلی com.yourcompany.app اصل ایپ پیکیج کے نام کے ساتھ جس کی وضاحت کی گئی ہے۔ AndroidManifest.xml.

اینڈرائیڈ پلگ ان فائل

# android/fastlane/Pluginfile

gem 'fastlane-plugin-firebase_app_distribution'

یہ Firebase ایپ کی تعیناتی پلگ ان کو بطور انحصار قرار دیتا ہے۔ فاسٹ لین کی بنیادی تنصیب میں پلیٹ فارم کے لیے مخصوص پلگ ان شامل نہیں ہیں۔ کہ fastlane-plugin-firebase_app_distribution زیورات ہے۔ firebase_app_distribution وہ عمل firebase لینز کو بلڈس اپ لوڈ کرنے اور ٹیسٹرز کو مطلع کرنے کے لیے استعمال کیا جاتا ہے۔ اس لائن کے بغیر firebase جب لین اسے کال کرنے کی کوشش کرتی ہے، تو یہ "غیر متعینہ طریقہ” کی خرابی کے ساتھ ناکام ہو جاتی ہے۔ firebase_app_distribution.

اینڈروئیڈ فاسٹ فائل

# android/fastlane/Fastfile

default_platform(:android)

platform :android do
  desc "Submit a new Beta Build to Firebase App Distribution"
  lane :firebase do
    notes = ENV["RELEASE_NOTES"]
    if notes.nil? || notes.strip.empty?
      file_path = File.join(Dir.pwd, "..", "release_notes.txt")
      if File.exist?(file_path) && !File.read(file_path).strip.empty?
        notes = File.read(file_path)
      else
        notes = "New build uploaded by CI"
      end
    end

    firebase_app_distribution(
      app: ENV["FIREBASE_APP_ID_ANDROID"],
      apk_path: "../build/app/outputs/flutter-apk/app-release.apk",
      groups: "testers",
      release_notes: notes,
      service_credentials_file: ENV["FIREBASE_SERVICE_ACCOUNT_JSON_PATH"]
    )
  end

  desc "Deploy to Google Play Store"
  lane :prod do
    upload_to_play_store(
      track: 'production',
      aab: '../build/app/outputs/bundle/release/app-release.aab',
      json_key: 'play-store-service-account.json',
      skip_upload_metadata: true,
      skip_upload_images: true,
      skip_upload_screenshots: true
    )
  end
end

default_platform(:android) ایک ڈیفالٹ سیاق و سباق سیٹ کرتا ہے تاکہ Fastlane کو معلوم ہو کہ یہ آپ کے Android پروجیکٹ پر کام کر رہا ہے۔ lane :firebase do اقدامات کی ایک نامزد ترتیب کی وضاحت کرتا ہے جسے کہا جاتا ہے۔ firebase.

کہ notes سب سے اوپر کی منطق ترجیح کے لحاظ سے تین ذرائع سے ریلیز نوٹ لینے کی کوشش کرتی ہے۔ RELEASE_NOTES ماحولیاتی متغیرات (GitHub ایکشنز کے ذریعے سیٹ کیا جاتا ہے جب ورک فلو کو دستی طور پر ایک نوٹ درج کرکے متحرک کیا جاتا ہے) release_notes.txt فائل کو پروجیکٹ روٹ میں محفوظ کریں اور آخر میں ڈیفالٹ متبادل سٹرنگ شامل کریں۔ firebase_app_distribution(...) یہ پلگ ان کے ذریعہ فراہم کردہ ایک کارروائی ہے۔

app: ENV["FIREBASE_APP_ID_ANDROID"] ورک فلو میں سیٹ کیے گئے ماحولیاتی متغیرات سے اپ لوڈ اور پڑھنے کے لیے Firebase ایپ کی شناخت کریں۔ apk_path اس طرف اشارہ کرتا ہے جہاں فلٹر مرتب شدہ APK کو آؤٹ پٹ کرتا ہے۔ groups: "testers" اپنی Firebase ایپ کی تعیناتی میں ٹیسٹرز کے ایک نامزد گروپ کو نشانہ بنائیں۔ اسے اپنے اصل گروپ کے نام سے بدل دیں۔ کے لیے prod لین upload_to_play_store(...) بلٹ ان فاسٹ لین ایکشن۔ track: 'production' اسے پروڈکشن ٹریک پر اپ لوڈ کیا جائے گا۔ skip_upload_metadata: true، skip_upload_images: trueاور skip_upload_screenshots: true Fastlane کو اسٹور کی فہرستوں کا نظم کرنے کی کوشش سے روکتا ہے، جو اس پائپ لائن کی ذمہ داری نہیں ہے۔

iOS کے لیے فاسٹ لین سیٹ اپ کریں۔

کوڈ پر دستخط کرنے کی وجہ سے iOS سیٹ اپ اینڈرائیڈ سے زیادہ پیچیدہ ہے۔ کہ ios/ ڈائریکٹریز کو ان کی اپنی فاسٹ لین کنفیگریشن کی ضرورت ہوتی ہے۔

iOS Gemfile

# ios/Gemfile

source "https://rubygems.org"
gem "fastlane"

plugins_path = File.join(File.dirname(__FILE__), 'fastlane', 'Pluginfile')
eval_gemfile(plugins_path) if File.exist?(plugins_path)

اس کا ڈھانچہ اینڈرائیڈ جیم فائل جیسا ہے۔ iOS اور Android الگ الگ بنڈلر ماحول کو برقرار رکھتے ہیں کیونکہ وہ علیحدہ ڈائریکٹریز میں ہیں اور ان کے لیے مختلف جیم ورژن یا پلگ ان کی ضرورت پڑ سکتی ہے۔ چل رہا ہے bundle install اندر ios/ جواہرات کو آزادانہ طور پر انسٹال کرتا ہے جو ان کے اندر نصب ہے۔ android/.

iOS ایپ فائل

# ios/fastlane/Appfile

app_identifier("com.yourcompany.app")

app_identifier(...) iOS بنڈل شناخت کنندہ کا اعلان کریں۔ یہ Xcode میں سیٹ بنڈل شناخت کنندہ سے بالکل مماثل ہونا چاہیے (رنر ٹارگٹ کے جنرل ٹیب کے نیچے دکھایا گیا ہے)۔ تبدیلی com.yourcompany.app اصل بنڈل ID کے ساتھ، Fastlane Match اس شناخت کنندہ کو پروویژننگ پروفائل فائل میں استعمال کرتا ہے جو سرٹیفکیٹ کو نام دیتا ہے اور اسے سرٹیفکیٹ اسٹور میں اسٹور کرتا ہے۔

میچ فائل

# ios/fastlane/Matchfile

git_url(ENV["MATCH_GIT_URL"] || "https://github.com/YOUR_GITHUB_USERNAME/your-certificates-repo")
storage_mode("git")
type("appstore")

git_url(...) یہ میچ کو بتاتا ہے کہ آپ کا ذاتی سرٹیفکیٹ اسٹور کہاں واقع ہے۔ GitHub ایکشن ورک فلو میں: MATCH_GIT_URL ماحول کے متغیر کو URL میں سرایت شدہ ذاتی رسائی ٹوکن کو شامل کرنے کے لیے سیٹ کیا گیا ہے، جس سے میچ کو آپ کے ذاتی اسٹور کی تصدیق ہو سکتی ہے۔ کہ || "https://github.com/..." فال بیک مقامی طور پر میچ چلاتے وقت استعمال کیا جاتا ہے، جہاں اس کے بجائے آپ کو انٹرایکٹو طور پر اسناد کے لیے کہا جاتا ہے۔ storage_mode("git") میچ کو ہدایت دیں کہ وہ S3 یا Google Cloud Storage کے بجائے Git کو اس کے سٹوریج بیک اینڈ کے طور پر استعمال کرے۔ type("appstore") ایک ڈیفالٹ سرٹیفکیٹ کی قسم سیٹ کرتا ہے، حالانکہ ہر لین اسے اوور رائیڈ کر سکتی ہے۔

iOS پلگ ان فائل

# ios/fastlane/Pluginfile

gem 'fastlane-plugin-firebase_app_distribution'

iOS کو بھی اسی Firebase ایپ کی تعیناتی پلگ ان کی ضرورت ہوتی ہے۔ firebase فائربیس پر عارضی IPA اپ لوڈ کرنے کی یہ لین ہے۔ iOS اور Android پلگ ان فائلیں الگ الگ ہیں اور دونوں کو اس اعلان کی ضرورت ہے۔

iOS فاسٹ فائل

# ios/fastlane/Fastfile

default_platform(:ios)

before_all do
  setup_ci
end

platform :ios do
  desc "Push a new beta build to TestFlight"
  lane :beta do
    api_key = app_store_connect_api_key(
      key_id: ENV["APP_STORE_CONNECT_API_KEY_KEY_ID"],
      issuer_id: ENV["APP_STORE_CONNECT_API_KEY_ISSUER_ID"],
      key_filepath: ENV["APP_STORE_CONNECT_API_KEY_KEY_FILEPATH"],
      in_house: false
    )

    match(
      type: "appstore",
      readonly: false,
      app_identifier: "com.YOUR-APP.app",
      api_key: api_key
    )

    update_code_signing_settings(
      path: "Runner.xcodeproj",
      use_automatic_signing: false,
      team_id: "GL369K3W98",
      code_sign_identity: "Apple Distribution",
      profile_name: "match AppStore com.YOUR-APP.app",
      targets: ["Runner"]
    )

    build_app(
      workspace: "Runner.xcworkspace",
      scheme: "Runner",
      export_method: "app-store"
    )

    notes = ENV["RELEASE_NOTES"]
    if notes.nil? || notes.strip.empty?
      file_path = File.join(Dir.pwd, "..", "release_notes.txt")
      if File.exist?(file_path) && !File.read(file_path).strip.empty?
        notes = File.read(file_path)
      else
        notes = "New build uploaded by CI"
      end
    end

    upload_to_testflight(
      skip_waiting_for_build_processing: true,
      changelog: notes
    )
  end

  desc "Deploy to Apple App Store"
  lane :prod do
    api_key = app_store_connect_api_key(
      key_id: ENV["APP_STORE_CONNECT_API_KEY_KEY_ID"],
      issuer_id: ENV["APP_STORE_CONNECT_API_KEY_ISSUER_ID"],
      key_filepath: ENV["APP_STORE_CONNECT_API_KEY_KEY_FILEPATH"],
      in_house: false
    )

    match(
      type: "appstore",
      readonly: false,
      app_identifier: "com.YOUR-APP.app",
      api_key: api_key
    )

    update_code_signing_settings(
      path: "Runner.xcodeproj",
      use_automatic_signing: false,
      team_id: "GL369K3W98",
      code_sign_identity: "Apple Distribution",
      profile_name: "match AppStore com.YOUR-APP.app",
      targets: ["Runner"]
    )

    build_app(
      workspace: "Runner.xcworkspace",
      scheme: "Runner",
      export_method: "app-store"
    )

    upload_to_app_store(
      force: true, # Skip HTML report
      submit_for_review: false, # Uploads to App Store Connect without auto-submitting for review
      automatic_release: false
    )
  end

  desc "Push a new beta build to Firebase App Distribution"
  lane :firebase do
    api_key = app_store_connect_api_key(
      key_id: ENV["APP_STORE_CONNECT_API_KEY_KEY_ID"],
      issuer_id: ENV["APP_STORE_CONNECT_API_KEY_ISSUER_ID"],
      key_filepath: ENV["APP_STORE_CONNECT_API_KEY_KEY_FILEPATH"],
      in_house: false
    )

    match(
      type: "adhoc",
      readonly: false,
      app_identifier: "com.YOUR-APP.app",
      api_key: api_key
    )

    update_code_signing_settings(
      path: "Runner.xcodeproj",
      use_automatic_signing: false,
      team_id: "GL369K3W98",
      code_sign_identity: "Apple Distribution",
      profile_name: "match AdHoc com.YOUR-APP.app",
      targets: ["Runner"]
    )

    build_app(
      workspace: "Runner.xcworkspace",
      scheme: "Runner",
      export_method: "ad-hoc"
    )

    notes = ENV["RELEASE_NOTES"]
    if notes.nil? || notes.strip.empty?
      file_path = File.join(Dir.pwd, "..", "release_notes.txt")
      if File.exist?(file_path) && !File.read(file_path).strip.empty?
        notes = File.read(file_path)
      else
        notes = "New build uploaded by CI"
      end
    end

    firebase_app_distribution(
      app: ENV["FIREBASE_APP_ID_IOS"],
      groups: "testers",
      release_notes: notes,
      service_credentials_file: ENV["FIREBASE_SERVICE_ACCOUNT_JSON_PATH"]
    )
  end
end

before_all do setup_ci end یہ تمام گلیوں کے سامنے چلتا ہے۔ setup_ci CI کی کھپت کے لیے آپ کے ماحول کو ترتیب دینے کے لیے بلٹ ان فاسٹلین ٹاسک۔ ایک عارضی کیچین سیٹ اپ کریں (میک او ایس کو پاس ورڈ کا اشارہ کیے بغیر سرٹیفکیٹ انسٹال کرنے کی اجازت دیتے ہوئے)، کوڈ سائن کرنے والے پاپ اپ کو غیر فعال کریں، اور CI سے متعلقہ دیگر ترتیبات کو ترتیب دیں۔ اس کے بغیر، سرٹیفکیٹ کی تنصیب صارف کے منظوری کے ڈائیلاگ پر کلک کرنے کا انتظار کرے گی جو کبھی نہیں آتا ہے۔

app_store_connect_api_key(...) ایپ اسٹور کنیکٹ API کلید کو پڑھتا ہے اور ایک API کلیدی آبجیکٹ تیار کرتا ہے جسے بعد کے آپریشنز ایپ اسٹور کی توثیق کے لیے استعمال کرتے ہیں۔ key_id، issuer_idاور key_filepath یہ سب ورک فلو میں سیٹ کیے گئے ماحولیاتی متغیرات سے آتے ہیں۔ in_house: false اس سے ظاہر ہوتا ہے کہ یہ ایک معیاری ڈویلپر اکاؤنٹ ہے (مختلف تعیناتی قوانین کے ساتھ ایپل انٹرپرائز پروگرام اکاؤنٹ نہیں)۔

match(type: "appstore", ...) اپنے سرٹیفکیٹ اسٹور سے جڑیں، AppStore ڈسٹری بیوشن سرٹیفکیٹ اور پروویژننگ پروفائل ڈاؤن لوڈ کریں، اور انہیں اپنے macOS کیچین میں انسٹال کریں۔

readonly: false میچ کو ایک سرٹیفکیٹ بنانے کی اجازت دیں اگر اس کے پاس پہلے سے کوئی سرٹیفکیٹ نہیں ہے۔ جب پہلی بار کسی نئے پروجیکٹ کے لیے چلایا جاتا ہے، میچ ایک سرٹیفکیٹ تیار کرتا ہے اور اسے مخزن میں دھکیلتا ہے۔ اس کے بعد کی رنز صرف موجودہ سرٹیفکیٹ کو ڈاؤن لوڈ کریں۔ کے لیے firebase لین type: "adhoc" استعمال کیا جاتا ہے کیونکہ Firebase ایپ کی تعیناتی کے لیے App Store سرٹیفکیٹ کی بجائے عارضی تعیناتی سرٹیفکیٹ کی ضرورت ہوتی ہے۔

update_code_signing_settings(...) آپ نے ابھی ڈاؤن لوڈ کردہ میچ سے مخصوص سرٹیفکیٹ اور پروفائل استعمال کرنے کے لیے اپنی Xcode پروجیکٹ فائل میں ترمیم کریں۔

use_automatic_signing: false اہم: خودکار دستخط ایکس کوڈ کو سرٹیفکیٹ کا خود انتظام کرنے پر مجبور کرتا ہے، لیکن یہ بغیر سر کے CI ماحول میں ناکام ہوجاتا ہے۔ team_id: "YOUR_TEAM_ID" یہ Apple Developer Team ID ہے جو Apple Developer Portal کے ممبرشپ سیکشن میں ظاہر ہوتی ہے۔ profile_name: "match AppStore com.yourcompany.app" یہ اس نام کے کنونشن سے میل کھاتا ہے جو Match آپ کا پروفائل بناتے وقت استعمال کرتا ہے۔

build_app(workspace: "Runner.xcworkspace", scheme: "Runner", export_method: "app-store") کال xcodebuild اپنی ایپ کو آرکائیو اور ایکسپورٹ کرنے کے لیے Runner.xcworkspace یہ ایک ایکس کوڈ ورک اسپیس ہے جو فلٹر میں بنائی گئی ہے۔ اگر آپ کے پاس CocoaPods پر انحصار ہے، تو آپ کو پروجیکٹ فائل کے بجائے ورک اسپیس کا استعمال کرنا چاہیے۔ export_method: "app-store" Xcode کو بتاتا ہے کہ حتمی IPA کے لیے کون سے برآمدی اختیارات استعمال کیے جائیں۔ Firebase لین کے لیے یہ ہوگا: "ad-hoc".

upload_to_testflight(skip_waiting_for_build_processing: true) اپنا IPA App Store Connect پر اپ لوڈ کریں۔ skip_waiting_for_build_processing: true فاسٹ لین کو ہدایت کرتا ہے کہ وہ ایپل کے تعمیراتی عمل کو مکمل کرنے کا انتظار نہ کرے۔ اس میں 15 سے 30 منٹ لگ سکتے ہیں۔ اپ لوڈ مکمل ہو گیا ہے اور ورک فلو مکمل ہو گیا ہے۔ ایپل پروسیسنگ مکمل کرنے کے بعد، آپ کی تعمیر TestFlight میں ظاہر ہوگی۔

upload_to_app_store(force: true, submit_for_review: false, automatic_release: false) پروڈکشن کی تعیناتی کے لیے App Store Connect پر اپ لوڈ کریں۔ force: true سی آئی فاسٹلین کی ایچ ٹی ایم ایل سمری رپورٹ کو چھوڑ دیتا ہے، جو مفید نہیں ہے۔ submit_for_review: false ایپ کے جائزے کے لیے خودکار طور پر بلڈز جمع کرانے کے بجائے، ہم بلڈز کو اپ لوڈ کرتے ہیں تاکہ آپ ان کا جائزہ لے کر دستی طور پر جمع کر سکیں۔ automatic_release: false منظوری کے بعد خودکار ریلیز کو روکیں۔

ایک GitHub ایکشن ورک فلو بنائیں

ورک فلو ایک YAML فائل ہے جس پر واقع ہے: .github/workflows/ یہ آپ کے ذخیرے کی جڑ میں ہے۔ ہر فائل ایک ورک فلو کو اس کے نام، اس کو متحرک کرنے والے واقعات، اور عمل کرنے کے اقدامات کی ترتیب سے متعین کرتی ہے۔

اینڈروئیڈ ورک فلو

# .github/workflows/android_distribution.yml

name: Android Firebase App Distribution
on:
  push:
    branches:
      - dev
      - prod
  workflow_dispatch:
    inputs:
      release_notes:
        description: 'Release Notes'
        required: false
        default: 'Manual trigger from GitHub Actions'

jobs:
  distribute_android:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v3
        with:
          distribution: 'zulu'
          java-version: '17'

      - uses: subosito/flutter-action@v2
        with:
          channel: 'stable'
          cache: true

      - run: flutter pub get

      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.2'
          bundler-cache: true
          working-directory: android

      - name: Decode Keystore
        env:
          ANDROID_KEYSTORE_BASE64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
        run: |
          echo $ANDROID_KEYSTORE_BASE64 | base64 --decode > android/app/upload-keystore.jks
          echo "storeFile=upload-keystore.jks" > android/key.properties
          echo "storePassword=${{ secrets.ANDROID_STORE_PASSWORD }}" >> android/key.properties
          echo "keyPassword=${{ secrets.ANDROID_KEY_PASSWORD }}" >> android/key.properties
          echo "keyAlias=${{ secrets.ANDROID_KEY_ALIAS }}" >> android/key.properties

      - name: Create .env file
        env:
          ENV_FILE_BASE64: ${{ secrets.ENV_FILE_BASE64 }}
        run: echo $ENV_FILE_BASE64 | base64 --decode > .env

      - name: Build Android Release
        run: |
          if [ "${{ github.ref_name }}" == "prod" ]; then
            flutter build appbundle --release
          else
            flutter build apk --release
          fi

      - name: Create Firebase Service Account JSON
        if: ${{ github.ref_name == 'dev' }}
        env:
          FIREBASE_SERVICE_ACCOUNT_JSON: ${{ secrets.FIREBASE_SERVICE_ACCOUNT_JSON }}
        run: echo $FIREBASE_SERVICE_ACCOUNT_JSON > android/firebase-service-account.json

      - name: Distribute to Firebase App Distribution (Dev)
        if: ${{ github.ref_name == 'dev' }}
        env:
          FIREBASE_APP_ID_ANDROID: ${{ secrets.FIREBASE_APP_ID_ANDROID }}
          FIREBASE_SERVICE_ACCOUNT_JSON_PATH: "firebase-service-account.json"
          RELEASE_NOTES: ${{ github.event.inputs.release_notes }}
        run: bundle exec fastlane firebase
        working-directory: android

      - name: Distribute to Google Play Store (Prod)
        if: ${{ github.ref_name == 'prod' }}
        env:
          GOOGLE_PLAY_JSON: ${{ secrets.GOOGLE_PLAY_JSON }}
        run: |
          echo $GOOGLE_PLAY_JSON > play-store-service-account.json
          bundle exec fastlane prod
        working-directory: android

name: Android Firebase App Distribution یہ وہ ڈسپلے نام ہے جو آپ کے ذخیرے کے لیے GitHub ایکشنز ٹیب میں ظاہر ہوتا ہے۔

on: push: branches: [dev, prod] محرکات کو ترتیب دیں۔ یہ ورک فلو چلتا ہے جب بھی کسی کمٹ کو درج ذیل میں سے کسی کی طرف دھکیل دیا جاتا ہے۔ dev یا prod درخت کی شاخیں۔ یہ کسی دوسری شاخ پر نہیں چلے گا، بشمول: main اور developیہ اسٹیجنگ برانچ ہے جو برقرار رہے گی۔

workflow_dispatch: inputs: release_notes دستی ٹرگر شامل کریں۔ GitHub ایکشنز ٹیب میں، آپ "رن ورک فلو” پر کلک کر سکتے ہیں اور اختیاری طور پر ریلیز نوٹ درج کر سکتے ہیں تاکہ فاسٹ لین کو منتقل کیا جائے۔ یہ جانچ اور عارضی ریلیز کے لیے مفید ہے۔

runs-on: ubuntu-latest ورچوئل مشین کی وضاحت کرتا ہے۔ اوبنٹو اینڈرائیڈ کے لیے استعمال کیا جاتا ہے کیونکہ اینڈرائیڈ بلڈ ٹول چین لینکس پر چلتا ہے اور اوبنٹو لانچر میک او ایس لانچر سے سستا ہے۔

actions/checkout@v4 ریپوزٹری کو ایگزیکیوٹر کی ورکنگ ڈائرکٹری میں کلون کریں۔ اس کے بغیر، آپ کا کوڈ دوسرے مراحل میں قابل رسائی نہیں ہوگا۔

actions/setup-java@v3 زولو ڈسٹری بیوشن کا استعمال کرتے ہوئے جاوا 17 انسٹال کریں۔ فی الحال، فلٹر پروجیکٹس میں استعمال ہونے والی گریڈ 8 کی مطابقت کے لیے Java 17 درکار ہے۔ اگر صحیح جاوا ورژن نہیں ملا تو، گریڈل فوراً ناکام ہو جائے گا۔

subosito/flutter-action@v2 فلٹر SDK انسٹال کریں۔ channel: 'stable' ایک مستحکم ریلیز چینل استعمال کریں جو پروڈکشن کی تعمیر کے لیے موزوں ہو۔ cache: true ورک فلو رن کے درمیان Cache Flutter SDK ڈاؤن لوڈ ہوتا ہے، جس سے بعد میں چلنے والے سیٹ اپ کے وقت میں نمایاں کمی آتی ہے۔

ruby/setup-ruby@v1 روبی 3.2 انسٹال اور چلائیں۔ bundle install پر android/ درج ذیل صورتوں میں ڈائرکٹری خود بخود: bundler-cache: true یہ مقرر ہے. کہ bundler-cache یہ آپشن رن کے درمیان نصب جواہرات کو بھی کیش کرتا ہے، جس سے آپ کو فی ورک فلو رن 2-3 منٹ کی بچت ہوتی ہے۔

کہ کیسٹور ڈی کوڈ اقدامات اینڈرائیڈ سیکیورٹی سیٹنگز کا مرکز ہیں۔ echo $ANDROID_KEYSTORE_BASE64 | base64 --decode > android/app/upload-keystore.jks Base64 انکوڈنگ کو الٹا کر کے بائنری کو دوبارہ تخلیق کریں۔ .jks فائل کو متوقع راستے میں رکھیں۔ فالو اپ echo کمانڈ لکھنا key.properties یہ وہ فائل ہے جسے اینڈرائیڈ گریڈل کی اسٹورز اور پاس ورڈز تلاش کرنے کے لیے پڑھتا ہے۔ ہر بار جب آپ اسے چلاتے ہیں تو یہ فائل براہ راست آپ کے رازوں سے نئے سرے سے بنائی جاتی ہے، لہذا یہ مستقل طور پر کہیں بھی محفوظ نہیں ہوتی ہے۔

if [ "${{ github.ref_name }}" == "prod" ] bash مشروط. github.ref_name اس شاخ کا نام جس نے دھکا لگایا۔ برانچ کی صورت میں prodورک فلوز ایپ بنڈلز کا استعمال کرتے ہوئے بنائے جاتے ہیں (.aabپلے اسٹور کے لیے درکار ہے)۔ ورنہ ( dev)، APK(.apkFirebase ایپس کو تعینات کرنے کے لیے یہ آسان، تیز اور بہترین ہے)۔ ایک ہی ورک فلو فائل اس ایک شرط کا استعمال کرتے ہوئے دونوں شاخوں پر کارروائی کرتی ہے۔

if: ${{ github.ref_name == 'dev' }} مرحلہ کی سطح مشروط۔ اس شرط کے ساتھ اقدامات صرف اس صورت میں چلیں گے جب ٹرگر برانچ ہو: dev. Firebase کی تعیناتی کے مرحلے کو مکمل طور پر چھوڑ دیں۔ prod دھکیلنا پلے اسٹور کا مرحلہ مکمل طور پر چھوڑ دیتا ہے۔ dev دھکا۔

iOS ورک فلو

# .github/workflows/ios_distribution.yml

name: iOS TestFlight and Firebase Distribution
on:
  push:
    branches:
      - dev
      - prod
  workflow_dispatch:
    inputs:
      release_notes:
        description: 'Release Notes'
        required: false
        default: 'Manual trigger from GitHub Actions'

jobs:
  distribute_ios:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v3
        with:
          distribution: 'zulu'
          java-version: '17'

      - uses: subosito/flutter-action@v2
        with:
          channel: 'stable'
          cache: true

      - run: flutter pub get

      - name: Create .env file
        env:
          ENV_FILE_BASE64: ${{ secrets.ENV_FILE_BASE64 }}
        run: echo $ENV_FILE_BASE64 | base64 --decode > .env

      - name: Build Flutter iOS (No Codesign)
        run: flutter build ios --release --no-codesign

      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.2'
          bundler-cache: true
          working-directory: ios

      - name: Configure Fastlane Match
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          MATCH_GIT_BASIC_AUTHORIZATION: ${{ secrets.MATCH_GIT_BASIC_AUTHORIZATION }}
        run: |
          echo "MATCH_PASSWORD=${MATCH_PASSWORD}" >> $GITHUB_ENV
          AUTH=$(echo "$MATCH_GIT_BASIC_AUTHORIZATION" | base64 --decode)
          echo "MATCH_GIT_URL=https://$AUTH@github.com/YOUR_GITHUB_USERNAME/your-certificates-repo" >> $GITHUB_ENV

      - name: Create Auth Key for App Store Connect
        env:
          APPSTORE_API_PRIVATE_KEY_BASE64: ${{ secrets.APPSTORE_API_PRIVATE_KEY_BASE64 }}
          APPSTORE_API_KEY_ID: ${{ secrets.APPSTORE_API_KEY_ID }}
        run: |
          mkdir -p ~/.appstoreconnect/private_keys/
          echo $APPSTORE_API_PRIVATE_KEY_BASE64 | base64 --decode > ~/.appstoreconnect/private_keys/AuthKey_${APPSTORE_API_KEY_ID}.p8

      - name: Create Firebase Service Account JSON
        if: ${{ github.ref_name == 'dev' }}
        env:
          FIREBASE_SERVICE_ACCOUNT_JSON: ${{ secrets.FIREBASE_SERVICE_ACCOUNT_JSON }}
        run: echo $FIREBASE_SERVICE_ACCOUNT_JSON > ios/firebase-service-account.json

      - name: Distribute to Firebase App Distribution (Dev)
        if: ${{ github.ref_name == 'dev' }}
        env:
          FIREBASE_APP_ID_IOS: ${{ secrets.FIREBASE_APP_ID_IOS }}
          FIREBASE_SERVICE_ACCOUNT_JSON_PATH: "firebase-service-account.json"
          RELEASE_NOTES: ${{ github.event.inputs.release_notes }}
          APP_STORE_CONNECT_API_KEY_ISSUER_ID: ${{ secrets.APPSTORE_ISSUER_ID }}
          APP_STORE_CONNECT_API_KEY_KEY_ID: ${{ secrets.APPSTORE_API_KEY_ID }}
          APP_STORE_CONNECT_API_KEY_KEY_FILEPATH: ~/.appstoreconnect/private_keys/AuthKey_${{ secrets.APPSTORE_API_KEY_ID }}.p8
        run: bundle exec fastlane firebase
        working-directory: ios

      - name: Distribute to TestFlight (Dev)
        if: ${{ github.ref_name == 'dev' }}
        env:
          APP_STORE_CONNECT_API_KEY_ISSUER_ID: ${{ secrets.APPSTORE_ISSUER_ID }}
          APP_STORE_CONNECT_API_KEY_KEY_ID: ${{ secrets.APPSTORE_API_KEY_ID }}
          APP_STORE_CONNECT_API_KEY_KEY_FILEPATH: ~/.appstoreconnect/private_keys/AuthKey_${{ secrets.APPSTORE_API_KEY_ID }}.p8
        run: bundle exec fastlane beta
        working-directory: ios

      - name: Distribute to Apple App Store (Prod)
        if: ${{ github.ref_name == 'prod' }}
        env:
          APP_STORE_CONNECT_API_KEY_ISSUER_ID: ${{ secrets.APPSTORE_ISSUER_ID }}
          APP_STORE_CONNECT_API_KEY_KEY_ID: ${{ secrets.APPSTORE_API_KEY_ID }}
          APP_STORE_CONNECT_API_KEY_KEY_FILEPATH: ~/.appstoreconnect/private_keys/AuthKey_${{ secrets.APPSTORE_API_KEY_ID }}.p8
        run: bundle exec fastlane prod
        working-directory: ios

runs-on: macos-latest iOS کی تعمیرات پر یہ غیر گفت و شنید ہے۔ Xcode صرف macOS پر چلتا ہے۔ xcodebuild (جسے فاسٹ لین اندرونی طور پر استعمال کرتا ہے) صرف وہاں دستیاب ہے۔ میکوس لانچر کی قیمت اوبنٹو لانچر کے مقابلے میں فی منٹ 10 گنا زیادہ ہے، اس لیے میں اینڈرائیڈ پر اوبنٹو استعمال کرتا ہوں۔ iOS کے لیے کوئی متبادل نہیں ہے۔

flutter build ios --release --no-codesign فلٹر ڈارٹ کوڈ اور مقامی iOS فریم ورک کوڈ کو کوڈ پر دستخط کیے بغیر ریلیز بلڈز میں مرتب کریں۔ کہ --no-codesign جھنڈے یہاں اہم ہیں۔ فلٹر کی تعمیر کے مرحلے کو دستخط کرنے کی کوشش نہیں کرنی چاہئے کیونکہ دستخطی سرٹیفکیٹ ابھی تک انسٹال نہیں ہوا ہے۔ فاسٹ لین میچ درست سرٹیفکیٹ ڈاؤن لوڈ اور انسٹال کرتا ہے اور پھر اس کے بعد آنے والی فاسٹ لین لین کے دستخط کو سنبھالتا ہے۔

کہ فاسٹلین میچنگ کنفیگریشن اقدامات اہم کام انجام دیتے ہیں۔ AUTH=$(echo "$MATCH_GIT_BASIC_AUTHORIZATION" | base64 --decode) ڈی کوڈ بیس 64۔ username:token سادہ متن پر سٹرنگ لوٹاتا ہے۔ echo "MATCH_GIT_URL=https://$AUTH@github.com/..." >> $GITHUB_ENV ٹوکن سمیت مکمل تصدیقی URL درج کریں۔ $GITHUB_ENV ایک فائل جسے GitHub ایکشنز ماحولیاتی متغیرات کو بعد کے مراحل تک پھیلانے کے لیے پڑھتا ہے۔ تصدیق شدہ URL فارمیٹ https://username:token@github.com/... HTTP بنیادی توثیق، فارمیٹ Git غیر انٹرایکٹو ماحول میں اسناد کو منتقل کرنے کے لیے استعمال کرتا ہے۔

کہ تصدیق کی کلید بنائیں اقدامات ہیں۔ .p8 یہ فائل Base64 انکوڈ شدہ ہے۔ mkdir -p ~/.appstoreconnect/private_keys/ ایک ڈائرکٹری بنائیں جہاں فاسٹلین کلید تلاش کرنے کی توقع کرے۔ echo $APPSTORE_API_PRIVATE_KEY_BASE64 | base64 --decode > ~/.appstoreconnect/private_keys/AuthKey_${APPSTORE_API_KEY_ID}.p8 ڈی کوڈ شدہ کلید کو درست فائل کے نام کے پیٹرن پر لکھیں۔ app_store_connect_api_key میں اسے ڈھونڈ رہا ہوں۔

iOS ورک فلو متوازی تعیناتی کے دو مراحل چلاتا ہے: dev انڈے کا پودا: firebase لین (ایک عارضی IPA بناتا ہے اور اسے Firebase ایپ کی تعیناتی پر اپ لوڈ کرتا ہے)، اور beta لین (ایک ایپ اسٹور IPA بنایا اور اسے TestFlight پر اپ لوڈ کیا)۔ دونوں شیئر سیٹ اپ مرحلہ کے بعد ترتیب وار چلتے ہیں۔ اس کا مطلب ہے ایک دھکا۔ dev دونوں تقسیمی چینلز کو خودکار طور پر تعمیرات فراہم کرتا ہے۔

اسکرین شاٹ:

اینڈرائیڈ اور آئی او ایس ورک فلو چلانا:

اینڈرائیڈ ورک فلو مکمل:

مکمل iOS ورک فلو:

اینڈرائیڈ اور آئی او ایس مکمل شدہ ورک فلو:

فائربیس ایپ کی تعیناتی – اینڈرائیڈ:

فائربیس ایپ کی تعیناتی – iOS:

TestFlight iOS کی تعمیر:

کس طرح پوری تعیناتی آخر سے آخر تک چلتی ہے۔

تمام کنفیگریشن مکمل ہونے کے بعد، پش سے پش تک واقعات کی مکمل ترتیب حسب ذیل ہے: dev:

چونکہ دونوں رنرز متوازی طور پر چلتے ہیں، اس لیے پلیٹ فارمز کے لیے کل وال کلاک کا وقت تقریباً یکساں ہوتا ہے جہاں زیادہ وقت لگتا ہے (عام طور پر Xcode مرتب کرنے کے اوقات کی وجہ سے iOS)۔

کے لیے prod پش کے لیے، ترتیب کا ڈھانچہ ایک جیسا ہے، لیکن تقسیم کا حتمی مرحلہ Google Play Store (Android) اور App Store Connect (iOS) کو نشانہ بناتا ہے۔

بہترین طرز عمل

اپنے سرٹیفکیٹ اسٹور کو نجی رکھیں اور رسائی کو کنٹرول کریں۔

سرٹیفکیٹ اسٹور میں iOS پر دستخط کرنے والے مواد کو مماثل پاس ورڈ کے ساتھ انکرپٹ کیا گیا ہے۔ اگرچہ فائلیں انکرپٹڈ ہیں، اس ریپوزٹری تک رسائی کے ساتھ وہی سلوک کریں جیسا کہ آپ کسی پروڈکشن ڈیٹا بیس تک رسائی کا علاج کرتے ہیں۔ ذاتی رسائی والے ٹوکنز کو منسوخ کریں جن کی مزید ضرورت نہیں ہے۔ اپنا میچ پاس ورڈ کہیں بھی سادہ متن میں شیئر نہ کریں۔

کم سے کم تعداد کی حکمت عملی طے کریں۔

خودکار CI تعمیرات کے لیے فی اپ لوڈ ایک منفرد نمبر کی ضرورت ہوتی ہے۔ ایپ اسٹور کنیکٹ اور گوگل پلے دونوں ڈپلیکیٹ بلڈ نمبرز کے ساتھ اپ لوڈز کو مسترد کرتے ہیں۔ ورژن سازی کی حکمت عملی کو نافذ کریں جس میں دستی مداخلت کی ضرورت نہ ہو۔ ایک قابل اعتماد نقطہ نظر GitHub ایکشنز کو استعمال کرنا ہے۔ GITHUB_RUN_NUMBERایک عدد عدد ہے جو ہر بار ورک فلو کے چلنے پر بڑھتا ہے۔

- name: Set Build Number
  run: |
    BUILD_NUMBER=${{ github.run_number }}
    # For Flutter, update the build number in pubspec.yaml
    sed -i '' "s/version: .*/version: 1.0.0+${BUILD_NUMBER}/" pubspec.yaml

github.run_number GitHub کے ذریعہ فراہم کردہ ایک ماحولیاتی متغیر جو 1 سے شروع ہوتا ہے جب پہلا ورک فلو ریپوزٹری میں چلتا ہے اور اس کے بعد کے ہر رن کے لیے 1 کا اضافہ ہوتا ہے۔ یہ ہر رن کے لیے ایک منفرد، یکسر بڑھتی ہوئی تعداد کو یقینی بناتا ہے۔ کہ sed کمانڈ ورژن لائن کی جگہ لے لیتا ہے۔ pubspec.yaml رن نمبر کو بلڈ نمبر کے طور پر شامل کیا جاتا ہے۔

برانچ کے تحفظ کے اصول شامل کریں۔

اپنی شاخوں کو حادثاتی طور پر براہ راست دھکیلنے سے بچانے کے لیے آٹومیشن کو لاگو کریں۔ اسٹوریج کی ترتیبات میں، جائیں: جگہ تحفظ کے اصول شامل کریں: main، develop، devاور prod.

کے لیے prod خاص طور پر، انضمام سے پہلے ایک یا زیادہ پل کی درخواستوں کی منظوری کی ضرورت پر غور کریں۔ یہ پروڈکشن کی تعیناتی سے آگ لگنے سے پہلے ایک انسانی گیٹ بناتا ہے۔

ورک فلو پر عمل درآمد کے وقت اور لاگت کی نگرانی کریں۔

عملدرآمد کے وقت کی بنیاد پر GitHub ایکشن چارجز۔ میکوس ٹائم لینکس ٹائم سے 10 گنا زیادہ مہنگا ہے۔ اپنی GitHub تنظیم پر جائیں۔ ترتیبپھر دعوی اپنے موجودہ استعمال کو چیک کریں۔

کیشنگ( cache: true پھڑپھڑانا اور bundler-cache: true روبی) سب سے زیادہ بااثر اصلاح ہے۔ اس کے بعد کی رن جو پہلی رن کے بعد کیشے کو ٹکراتی ہیں وہ ڈاؤن لوڈ کو چھوڑ دیں گی اور مراحل کو مکمل طور پر نکال دیں گی۔

ان پٹ کے بجائے ریلیز کی معلومات کو فائل میں اسٹور کریں۔

کہ release_notes.txt فاسٹ فائل کے فال بیک کا مطلب ہے کہ آپ پل کی درخواست کے حصے کے طور پر ریلیز نوٹس کا ارتکاب کر سکتے ہیں، اور وہ ریلیز نوٹس خود بخود Firebase اور TestFlight تعیناتی اطلاعات میں ظاہر ہوں گے۔ اس فائل کو اپنے پروجیکٹ روٹ میں بنائیں اور اسے ہر ریلیز برانچ کے ساتھ اپ ڈیٹ کریں۔ یہ آپ کے ورژن کی سرگزشت میں ریلیز کے نوٹس کو اس کے بیان کردہ کوڈ کے ساتھ رکھے گا۔

عام غلطیاں

فاسٹ لین کے ورک اسپیس کے بجائے ایکس کوڈ پروجیکٹ کا استعمال

فلٹر iOS پروجیکٹس میں ہمیشہ ایک ورک اسپیس ہوتا ہے (Runner.xcworkspaceپروجیکٹ فائل نہیں (Runner.xcodeproj) کیونکہ CocoaPods انحصار ورک اسپیس کی سطح سے منسلک ہیں۔ گزرنا Runner.xcodeproj کو build_app یہ لاپتہ انحصار کی خرابی کے ساتھ ناکام ہوجاتا ہے۔ ہمیشہ استعمال کریں۔ workspace: "Runner.xcworkspace".

سیٹ نہیں ہے۔ setup_ci iOS کے لیے

بھول setup_ci پر before_all اسے مسدود کرنے سے آپ کے ورک فلو کو غیر معینہ مدت تک روک دیا جائے گا جب کہ macOS کیچین تک رسائی کی منظوری کا انتظار کرتا ہے، جو کبھی نہیں آتا۔ یہ ٹائم آؤٹ کی طرح لگتا ہے اور غلطی کا پیغام کہیں اور اشارہ کرتا ہے۔ ہمیشہ شامل before_all do setup_ci end CI کے لیے استعمال ہونے والی تمام iOS فاسٹ فائلوں میں۔

نئے پروجیکٹس کے لیے صرف پڑھنے کے موڈ میں میچز چلانا

پہلی بار میچ آپ کے نئے ایپ شناخت کنندہ پر چلتا ہے، آپ کو ایک سرٹیفکیٹ اور پروویژننگ پروفائل بنانے کی ضرورت ہوگی۔ اگر readonly: true اگر سیٹ ہو تو میچ سرٹیفکیٹ نہیں بنا سکے گا اور "سرٹیفکیٹ نہیں ملا” کی خرابی کے ساتھ ناکام ہو جائے گا۔ استعمال کریں readonly: false. پیداوار میں، کچھ ٹیمیں readonly: true ابتدائی سیٹ اپ کے بعد حادثاتی سرٹیفکیٹ کی تخلیق نو کو روکنے کے لیے false یہ ترتیب درست ہے۔

میں بلڈ نمبر بڑھانا بھول گیا۔

ایپل اور گوگل دونوں ہی ان بلڈز کو مسترد کرتے ہیں جن کا ورژن نمبر پہلے اپ لوڈ کردہ بلڈ جیسا ہی ہوتا ہے۔ دو بار دبائیں dev اگر آپ بلڈ نمبر نہیں بڑھاتے ہیں تو دوسرا اپ لوڈ ناکام ہو جائے گا۔ کہ GITHUB_RUN_NUMBER آپ ہمارے بہترین طریقوں میں بیان کردہ حکمت عملیوں کو استعمال کرکے خود بخود اس سے بچ سکتے ہیں۔

ٹریلنگ لائن بریکس کا استعمال کرتے ہوئے فائلوں کو انکوڈ کریں۔

استعمال کریں echo "content" | base64 اس کے بجائے echo -n "content" | base64 انکوڈنگ سے پہلے سٹرنگ میں ٹریلنگ نیو لائن کریکٹر شامل کرتا ہے۔ جب CI ایگزیکیوٹر کے ذریعے ڈی کوڈ کیا جاتا ہے، فائل میں پچھلی نئی لائنیں ہوتی ہیں جو اصل میں موجود نہیں تھیں۔ کے لیے username:token ایک تار ڈالیں MATCH_GIT_BASIC_AUTHORIZATIONایک پچھلی نئی لائن آپ کی اسناد کو خراب کر دیتی ہے اور تصدیق کی ناکامی کا سبب بنتی ہے جو کہ اجازت کی غلطی کی طرح دکھائی دیتی ہے۔ ہمیشہ استعمال کریں۔ echo -n فائلوں کے بجائے تاروں کو انکوڈنگ کرتے وقت۔

Firebase کے ساتھ تعیناتی کی غلط قسم کا استعمال

iOS کے لیے Firebase ایپ کی تعیناتی میں شامل ہیں: عارضی یہ ایک App Store سرٹیفکیٹ ہے، تقسیم کا سرٹیفکیٹ نہیں۔ چونکہ ایڈہاک بلڈز کو خاص طور پر ایپ اسٹور سے باہر براہ راست ڈیوائس کی تعیناتی کے لیے ڈیزائن کیا گیا ہے، اس لیے وہ App Store کے دستخط شدہ IPAs کو Firebase پر اپ لوڈ کرنے میں ناکام رہتے ہیں۔ کہ firebase iOS فاسٹ فائل میں لین واضح طور پر استعمال کرتی ہیں: type: "adhoc" اور export_method: "ad-hoc" اس وجہ سے۔ کہ beta لین کا استعمال type: "appstore" اس کی وجہ یہ ہے کہ TestFlight کو App Store سرٹیفکیٹ درکار ہے۔

اپنے Google Play سروسز اکاؤنٹ کو ناکافی اجازتیں دیں۔

سب سے عام Play Store اپ لوڈ کی ناکامی API میں اجازت کی خرابی ہے۔ سروس اکاؤنٹ کم از کم ریلیز مینیجر کی اجازتوں کے ساتھ Play Console ایپ سے منسلک ہونا چاہیے۔ گوگل کلاؤڈ میں سروس اکاؤنٹ بنانا صرف آدھا سیٹ اپ ہے۔ آپ کو API رسائی کے ذریعے Play Console کے اندر اپنے سروس اکاؤنٹ تک رسائی فراہم کرنے کی بھی ضرورت ہوگی۔ اگر آپ Play Console مرحلہ چھوڑ دیتے ہیں، تو اس کے نتائج یہ ہیں: 403 Forbidden فاسٹلین اپ لوڈ آپریشن کی وجہ سے خرابی۔

نتیجہ

جو ہم نے یہاں بنایا ہے وہ ایک انفراسٹرکچر ہے جو کمپاؤنڈ ریٹرن ادا کرتا ہے۔ جب آپ پہلی بار دھکا دیتے ہیں۔ dev GitHub ایکشنز ٹیب میں صارف کی مداخلت کے بغیر Android اور iOS دونوں کی تعمیرات کو مکمل دیکھیں۔ ترتیب کی قدر فوری اور بصری ہے۔ نمبر 4، نمبر 10، نمبر 50: قدر خاموشی سے مرکب ہے کیونکہ آپ کو اندازہ نہیں ہے کہ تعیناتی ہو رہی ہے۔ یہ صرف ہوتا ہے۔

اس گائیڈ میں موجود فن تعمیر ایک عام راستے کا احاطہ کرتا ہے، لیکن بنیادی ٹولز (GitHub ایکشنز، فاسٹ لین، میچ) تقریباً کسی بھی ورک فلو کو ایڈجسٹ کرنے کے لیے کافی لچکدار ہیں۔ ٹیم تعمیرات سے پہلے خودکار جانچ، مکمل یا ناکام ہونے پر سلیک اطلاعات، Git ٹیگز کے ذریعے ورژن نمبر کا انتظام، اور متعدد ہدف والے ماحول کے لیے اقدامات شامل کرتی ہے۔ dev اور prod. یہاں کی فاؤنڈیشن ان تمام ایکسٹینشنز کو سپورٹ کرتی ہے۔

سب سے بڑھ کر ایک پریکٹس جس پر زور دینا ضروری ہے وہ یہ ہے کہ آپ اپنی CI کنفیگریشن فائلوں کے ساتھ اپنے پروڈکشن کوڈ کی طرح ہی دیکھ بھال کرتے ہیں۔ پل کی درخواست میں ورک فلو فائل میں تبدیلیوں کا جائزہ لیں۔ ان اقدامات کی وضاحتیں شامل کریں جو غیر واضح ہیں۔ اپنے راز کو اپنی ورک فلو فائلوں میں اور اس خفیہ اسٹور میں رکھیں جہاں ان کا تعلق ہے۔ پائپ لائنز انہی وجوہات کی بنا پر ناکام ہو جاتی ہیں جن کی وجہ سے پروڈکشن کوڈ ناکام ہو جاتا ہے: غیر جائزہ شدہ تبدیلیاں، گمشدہ سیاق و سباق، اور غیر دستاویزی مفروضے۔

یہ پائپ لائن ٹیموں کو مصنوعات کو تیزی سے اور زیادہ اعتماد کے ساتھ بھیجنے کی اجازت دیتی ہے کیونکہ ٹیسٹرز کے ہاتھ میں کوڈ حاصل کرنے کا عمل اب غلطی کا شکار دستی کام نہیں ہے۔ یہ کوڈ کا ارتکاب کرنے کا ایک ضمنی اثر ہے، اور بالکل ایسا ہی ہونا چاہیے۔

حوالہ جات

گٹ ہب آپریشنز

فاسٹ لین

معافی مانگو

گوگل

پھڑپھڑانا