ما الذي يتغير عند شحن تطبيق جوال

إذا كنت قد أمضيت سنوات في شحن تطبيقات الويب، فإن توصيل التطبيقات للجوال يبدو وكأنك تدخل عالمًا مختلفًا. مع تطبيق الويب، تقوم بالبناء، الرفع إلى الخادم، وتنتهي المهمة. يقوم المستخدمون بتحديث المتصفح، ويرون أحدث إصدار. أنت تتحكم في كل شيء: الخادم، البنية التحتية، توقيت الإصدار.

تطبيقات الجوال لا تعمل بهذه الطريقة. والفروقات عميقة بما يكفي لتتطلب تغيير خط أنابيب CI/CD بالكامل.

التطبيق يعيش على جهاز شخص آخر

أول وأهم فرق هو مكان تشغيل التطبيق. تطبيق الجوال لا يعيش على خادم تديره. إنه يعيش على جهاز في جيب شخص ما. لا يمكنك استبدال الملفات على خادم. لا يمكنك دفع إصلاح عاجل وجعله ساري المفعول فورًا.

في كل مرة تريد شحن إصدار جديد، يجب عليك إعادة بناء التطبيق، توقيعه رقميًا، وإرساله إلى متجر التطبيقات. ثم يجب على المستخدم تنزيل التحديث وتثبيته بنفسه. بعض المستخدمين سيقومون بالتحديث فورًا. آخرون سيتجاهلون الإشعار لأسابيع. وقلة لن تقوم بالتحديث أبدًا.

هذا يغير طريقة تفكيرك في التوصيل. لا يمكنك افتراض أن الجميع على أحدث إصدار. لا يمكنك إصلاح خطأ حرج وجعله يصل إلى جميع المستخدمين في دقائق. السيطرة التي كانت لديك مع توصيل الويب قد ولت.

منصتان، نظاما بناء مختلفان

توصيل الجوال يعني التعامل مع أنظمة بناء متعددة. أندرويد يستخدم Gradle. آي أو إس يستخدم Xcode. لكل منهما قواعده الخاصة حول إصدارات SDK، التبعيات، وتنسيقات المخرجات. لا يمكنك بناء تطبيق أندرويد على macOS وشحنه لمستخدمي آي أو إس، أو العكس.

يحتاج خط الأنابيب الخاص بك إلى التعامل مع مسارين بناء منفصلين. يمكن تشغيلهما بالتوازي أو بالتسلسل، حسب إعداداتك، لكنهما ليسا متماثلين أبدًا. تكوين البناء لأندرويد موجود في ملفات Gradle. تكوين البناء لآي أو إس موجود في ملفات مشروع Xcode وخطط البناء. التبعيات تُدار بشكل مختلف. عملية التوقيع مختلفة تمامًا.

إذا كنت تدعم كلا المنصتين، فإن خط أنابيب CI/CD الخاص بك يصبح عمليًا خطي أنابيب يشتركان في بعض منطق الاختبار والإشعارات لكنهما يتباعدان في خطوة البناء.

التوقيع ليس اختياريًا

قبل أن يتم تثبيت تطبيق جوال على جهاز المستخدم، يجب توقيعه رقميًا. هذا التوقيع يثبت أن التطبيق جاء منك، وليس من شخص يتظاهر بأنه أنت. أندرويد يستخدم ملف keystore. آي أو إس يستخدم شهادات وملفات تعريف التزويد.

هذه ملفات سرية. إذا تسربت، يمكن لشخص آخر نشر تطبيقات تبدو كتطبيقاتك. إذا فقدتها، لا يمكنك أبدًا شحن تحديث آخر لتطبيقك الحالي على متجر Play أو App Store. لا يوجد استرداد. سيتعين عليك إنشاء قائمة تطبيق جديدة وفقدان جميع مستخدميك الحاليين.

في خط الأنابيب الخاص بك، يجب تخزين هذه الملفات بشكل آمن. لا تقم أبدًا بتضمينها بشكل ثابت في مستودعك. لا تقم أبدًا بإيداعها في نظام التحكم بالإصدارات. استخدم مدير أسرار، تخزين مشفر في نظام CI الخاص بك، أو خدمة توقيع مخصصة. يجب أن يصل خط الأنابيب إلى هذه الملفات فقط خلال خطوة التوقيع وليس في أي مكان آخر.

المتجر يتحكم في توقيت إصدارك

لا يمكنك فقط إرسال ملف APK أو IPA إلى المستخدمين. يجب أن يمر التطبيق عبر متجر التطبيقات. كل من Google Play Store و Apple App Store لديهما عمليات مراجعة. Google Play عادة ما يراجع في غضون ساعات. مراجعة Apple قد تستغرق وقتًا أطول وغالبًا ما تكون أكثر صرامة.

هذا يعني أن الوقت بين انتهاء بناءك وبدء المستخدمين في استخدام الإصدار الجديد ليس تحت سيطرتك. طرف ثالث يقرر متى يصبح تطبيقك متاحًا. إذا رفضوا طلبك، يجب عليك إصلاح المشكلة، إعادة البناء، وإعادة الإرسال. الساعة تعود إلى الصفر.

هذا يؤثر أيضًا على استراتيجية التراجع. على الويب، التراجع يعني نشر الإصدار السابق. على الجوال، لا يمكنك إجبار المستخدمين على العودة. المستخدمون الذين قاموا بالتحديث بالفعل سيبقون على الإصدار المعطل حتى تشحن إصلاحًا. وهذا الإصلاح يجب أن يمر بالمراجعة مرة أخرى.

الإصدارات التدريجية تصبح أساسية

لأنه لا يمكنك التراجع بسهولة، يجب أن تكون حذرًا بشأن كيفية إصدارك. كل من أندرويد وآي أو إس يدعمان الإصدارات التدريجية. أندرويد يسميها staged rollout. آي أو إس يسميها phased release.

الفكرة بسيطة: تقوم بإصدار الإصدار الجديد لنسبة صغيرة من المستخدمين أولاً. ربما 1% أو 5%. تراقب تقارير الأعطال، معدلات الأخطاء، وملاحظات المستخدمين. إذا كان كل شيء جيدًا، توسع الإصدار إلى 10%، ثم 25%، ثم 50%، ثم 100%. إذا حدث خطأ ما، توقف الإصدار. فقط المجموعة الصغيرة من المستخدمين الذين تلقوا التحديث بالفعل تتأثر.

هذا ليس اختياريًا لتوصيل الجوال الجاد. إنها الطريقة الأساسية لتقليل المخاطر عندما لا يمكنك التراجع فورًا.

ماذا يعني هذا لخط الأنابيب الخاص بك

كل هذه الفروقات تتراكم لتنتج خط أنابيب CI/CD يبدو مختلفًا جدًا عن خط أنابيب الويب. يجب أن يتعامل خط أنابيب الجوال الخاص بك مع:

المخطط التالي يوضح المسارين جنبًا إلى جنب، مسلطًا الضوء على أين يضيف الجوال بوابات إضافية.

flowchart TD subgraph Web W1[Build] --> W2[Upload to server] W2 --> W3[Users refresh browser] end subgraph Mobile M1[Build] --> M2[Sign app] M2 --> M3[Submit to store] M3 --> M4[Store review] M4 --> M5[User downloads update] end W1 -.-> M1
  • عمليات بناء خاصة بالمنصة باستخدام أدوات مختلفة
  • توقيع آمن بأسرار يجب ألا تتسرب أبدًا
  • رفع إلى متاجر التطبيقات مع إرسال آلي
  • استراتيجيات إصدار تدريجي يمكن إيقافها أو توسيعها

تحتاج أيضًا إلى التفكير في الاختبار بشكل مختلف. المحاكيات يمكنها اكتشاف العديد من المشكلات، لكنها ليست مثالية. بعض الأخطاء تظهر فقط على أجهزة حقيقية ذات أجهزة محددة، حساسات، أو ظروف شبكة. يجب أن يتضمن خط الأنابيب الخاص بك اختبارًا آليًا على الأجهزة الافتراضية وعملية اختبار على الأجهزة الحقيقية قبل الإصدار الكامل.

قائمة مراجعة سريعة لـ CI/CD للجوال

  • قم بتخزين مفاتيح التوقيع والشهادات في مدير أسرار آمن، وليس في مستودعك
  • قم بإعداد وظائف بناء منفصلة لأندرويد وآي أو إس باستخدام أدوات كل منهما
  • قم بأتمتة الرفع إلى Google Play Console و App Store Connect
  • قم بتطبيق الإصدار التدريجي في خط الأنابيب الخاص بك
  • أضف مراقبة الأعطال والتقارير التي تشغل التنبيهات أثناء الإصدار التدريجي
  • اختبر على كل من المحاكيات والأجهزة الحقيقية قبل توسيع نسبة الإصدار

الخلاصة

توصيل الجوال ليس توصيل ويب مع خطوة بناء مختلفة. التطبيق يعيش على أجهزة لا تتحكم فيها. المتجر يتحكم في توقيت إصدارك. التراجع ليس زرًا تضغط عليه. يجب أن يأخذ خط أنابيب CI/CD الخاص بك هذه الحقائق في الاعتبار من البداية. ابنِ للمنصة، وقع بأمان، أصدر تدريجيًا، وراقب بلا كلل. هذه هي الطريقة الوحيدة لشحن تطبيقات الجوال دون الاستيقاظ على حادثة إنتاج لا يمكنك إصلاحها حتى دورة المراجعة التالية.