تسريع إصدار التطبيقات بأتمتة CI/CD وFastlane!

خلصت شغلك فجأة؟ ازاى تبطل دورات البناء اليدوي وتدخل عالم CI/CD؟ ​

تخيل المشهد: واحد من فريق الـ Testing يرن عليك، يطلب نسخة جديدة، بتبني، ترفع على Google Drive، تجرب، يطلع عيب، تعدل، تبني تاني... يومك كله بقى شغل مكرر وممل!

الحل؟ تدخل عالم CI/CD - Continuous Integration وContinuous Deployment - وتخلي كل البروسيجرات دي تتم أوتوماتيك بدل ما تعملها بإيدك كل شوية. الدنيا بتبقى أسرع، أقل أخطاء، والمطور اللي كان بيقضي اليوم كله في رفع APK يتحول لبطل يبني مميزات جديدة

يعني إيه CI و CD بالظبط؟ ​

Continuous Integration (CI): عبارة عن سيرفر أو سيرفيس بيتأكد كل مرة ترفع كود (مثلاً على GitHub) إنه بيتبنى صح، وبيشغل الاختبارات (Unit Tests)، وبيبلغك لو في Conflict أو Error - كل حاجة دي بتتم آليًا.

Continuous Deployment (CD): بعد ما الـ CI يقول كل حاجة تمام، الـ CD بيتكفل بنشر النسخة - سواء على سيرفر تجارب (مثل Firebase App Distribution) أو حتى رفع تلقائي على المتاجر لو أنت مجهزها - من غير تدخل يدوي.

---

ليه CI/CD هيوفر عليك وقت ومشاكل؟ ​

• هتقلل الأخطاء البشرية (نسخ ملفات غلط، نسخ ملفات ناقصة).
• كل تعديل بيتبني ويتفحّص فورًا - لو حاجة غلط هتوصللك رسالة فورًا.
• التوزيع للمختبرين هيبقى أوتوماتيك ومضبوط.
• تقدر تعمل rollback لنسخة سابقة بسهولة لو حصلت مشكلة.
• المطور يقدر يركز على features مش على Build/Upload.

---

الأدوات اللي هتحتاجها (وبسرعة): Fastlane - Firebase - GitHub Actions ​

هشرحلك مسار عملي صغير تقدر تبدأ بيه فورًا:

1. تجهز Git repository.
2. تضيف Fastlane عشان تسهّل عمليات البناء والنشر.
3. تستخدم Firebase App Distribution لتوزيع نسخ على الـ Testers.
4. تعمل أتمتة بالـ GitHub Actions عشان كل حاجة تتعمل أوتوماتيك لما تفتح Pull Request أو تعمل Merge.

---

أولا: Fastlane - ليه وإزاي نبدأ؟ ​

Fastlane بتخليك تحول الخطوات اليدوية (build, sign, upload) لأوامر بسيطة، مثلاً بدل ما تعمل 10 خطوات تكتب أمر واحد.

لو جهازك Windows ممكن تحتاج Ruby قبل ما تثبت Fastlane. لو Linux/Mac فالأمر أبسط.

أوامر سريعة للتثبيت والتشغيل (نموذجي):

# تثبيت Fastlane (نموذج عام)

[sudo] gem install fastlane -NV

# أو لو بتستخدم npm/yarn في بعض البيئات

npm i -g fastlane

بعد كده في فولدر مشروعك (عادة android أو ios) تشغل:

cd android
fastlane init

هتتبع خطوات التهيئة وتحدد lanes اللي عايزها (مثلاً lane للبناء، lane للنشر على Firebase).

مثال مبسّط لملف Fastfile (Lane بيبني APK ويرفعه على Firebase App Distribution):

lane :beta do
gradle(task: "assembleRelease")
firebase_app_distribution(
app: "1:1234567890:android:abcdef",
testers: "[testers@example.com](mailto:testers@example.com)",
release_notes: "New build for QA"
)
end

---

ثانيًا: Firebase App Distribution - توزع النسخ للمختبرين بسهولة ​

Firebase App Distribution هيوصللك معرفة مين جرب النسخة، مين قفل التطبيق، وكمان Feedback هيوصلك بسرعة. مزايا ممتازة للـ QA.

خطوات سريعة:

# سجل الدخول وخد Token (لـ CI)

firebase login:ci

# بعدها خزّن الـ token كسِكرت في GitHub Actions باسم FIREBASE_TOKEN

---

ثالثًا: GitHub Actions - الأتمتة اللي تشغّل كل حاجة أوتوماتيك ​

تعمل ملف YAML في .github/workflows/ اسمه مثلاً ci-cd.yml، وتكتب حاجة زي المثال ده - ده مثال مبسّط يشتغل لما تدمج على الفرع main ويشغّل Fastlane لرفع نسخة:

name: CI/CD - Build & Distribute

on:
push:
branches:
- main

jobs:
build-and-distribute:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - name: Set up JDK
    uses: actions/setup-java@v4
    with:
      distribution: 'temurin'
      java-version: '17'

  - name: Install Ruby (for Fastlane)
    uses: ruby/setup-ruby@v1
    with:
      ruby-version: '3.1'

  - name: Install dependencies
    run: |
      gem install fastlane -NV
      cd android && ./gradlew assembleRelease

  - name: Run Fastlane beta
    env:
      FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
    run: |
      cd android
      fastlane beta

المهم هنا إنك تحفظ FIREBASE_TOKEN في Secrets بتاعت الريبو على GitHub، علشان GitHub Actions يقدر يرفع بدون ما يكشف حاجة حساسة.

---

نصايح عملية وخبيرية قبل ما تطبق CI/CD ​

• دايمًا شغّل Unit Tests وIntegration Tests ضمن الـ CI - مش بس build.
• خلي الـ pipeline قصير وسريع - لو الـ CI بياخد ساعة هتتأخر.
• استعمل caching للأدوات والـ dependencies (gradle cache إلخ) لتسريع البيلد.
• افصل مراحل الـ pipeline (build → test → deploy) عشان تعرف فين المشكلة بسرعة.
• استخدم feature flags لو هتنشر تغييرات كبيرة لتجربة جزء من المستخدمين أولًا.
• اعمل نسخة staging على Firebase أو Testflight قبل النشر الرسمي.

متى تستخدم نشر تلقائي كامل ومتى تعمل نشر جزئي؟ ​

• لو التحديث بسيط (fix UI، bug minor) تقدر تنشر تلقائي للمختبرين (CD).
• لو التغيير يمس DB schema أو صلاحيات، اعمل release يدوي بعد مراجعة - متخليش كل حاجة اتوماتيك لو فيها مخاطرة كبيرة.

خلاصة سريعة ​

لو انت زهقت من روتين بناء ورفع النسخ يدوي، CI/CD هي الطريق اللي هيوفرلك وقت ويقلل الأخطاء.
ابدأ بخطوات بسيطة: Fastlane علشان الأوامر تتبسط، Firebase App Distribution علشان توزع للمختبرين، وGitHub Actions علشان تخلي كل ده أوتوماتيك.