ما بعد كود التطبيق: توسيع نطاق CI/CD ليشمل التهيئة والتطبيقات المحمولة وأعلام الميزات
لديك الآن خطوط CI/CD تعمل لكود التطبيق، وترحيلات قاعدة البيانات، وتوفير البنية التحتية. عمليات النشر أصبحت أكثر سلاسة، والاسترجاع أسرع، وفريقك ينام بشكل أفضل في الليل. لكن هناك شعور مزعج بأن شيئًا ما لا يزال ناقصًا.
تظهر المشكلة بطرق صغيرة. يحتاج أحد أعضاء الفريق إلى تغيير سلسلة اتصال قاعدة البيانات لبيئة الاختبار. الإصلاح تافه - مجرد تحديث قيمة تهيئة - لكنه يتطلب دورة نشر كاملة لأن التهيئة مضمنة في الكود. أو يصدر فريق التطبيقات المحمولة إصدارًا جديدًا، لكن مراجعة متجر التطبيقات تستغرق ثلاثة أيام، ولم يخطط أحد لهذا التأخير. أو أن ميزة كان من المفترض أن تُطرح تدريجيًا للمستخدمين تكون إما مفعلة بالكامل أو معطلة بالكامل لأنه لا توجد آلية للتحكم بها دون إعادة نشر.
هذه ليست حالات نادرة. إنها المجالات التي تبدأ فيها معظم تطبيقات CI/CD في إظهار التشققات. الخبر السار هو أن توسيع خط الأنابيب الخاص بك للتعامل مع التهيئة والتطبيقات المحمولة وأعلام الميزات هو أمر مباشر بمجرد أن تعرف ما الذي تبحث عنه.
التهيئة كمسار تسليم منفصل
تبدأ معظم الفرق بتخزين التهيئة في متغيرات بيئة أو ملفات تهيئة تعيش بجانب كود التطبيق. هذا يعمل حتى لا يعمل. في اللحظة التي تحتاج فيها إلى تغيير قيمة لبيئة واحدة دون لمس البيئات الأخرى، تدرك أن التهيئة والكود لهما احتياجات دورة حياة مختلفة.
يجب ألا تتطلب تغييرات التهيئة بناء. يجب ألا تتطلب تشغيل مجموعة الاختبارات الكاملة. يجب ألا تتطلب نشرًا يعيد تشغيل التطبيق. سلسلة اتصال قاعدة البيانات، أو مفتاح API، أو قيمة تبديل ميزة ليست كودًا. معاملتها ككود يضيف احتكاكًا غير ضروري.
الحل هو فصل التهيئة عن الكود وإعطائها خط أنابيب خاص بها. هذا الخط أبسط من خط كود التطبيق:
- يتم إيداع تغيير في قيمة تهيئة في مستودع
- يمر التغيير بنفس عملية المراجعة مثل تغييرات الكود
- بمجرد الموافقة، يتم تطبيق التهيئة على البيئة المستهدفة
- يلتقط التطبيق القيمة الجديدة دون إعادة تشغيل
الفرق الرئيسي هو أن خط أنابيب التهيئة يتخطى مراحل البناء والاختبار. لا يوجد شيء لتجميعه أو اختبار وحدات له. المهم هو أن التهيئة تصل إلى الخادم الصحيح وأن التطبيق يمكنه إعادة تحميلها ديناميكيًا.
هذا النهج يسهل أيضًا التدقيق. كل تغيير في التهيئة يتم تتبعه في نظام التحكم بالإصدارات، ومراجعته من قبل زميل، وتطبيقه من خلال خط أنابيب. لا مزيد من الدخول عبر SSH إلى خادم لتغيير قيمة والأمل في ألا يلاحظ أحد.
خطوط أنابيب التطبيقات المحمولة لها قيود مختلفة
تبدو التطبيقات المحمولة مثل أي مشروع برمجي آخر حتى تحاول نشرها. عملية البناء تنتج ملف تثبيت يجب توقيعه رقميًا. التوزيع يمر عبر متاجر التطبيقات التي لديها عمليات مراجعة خاصة بها. وبمجرد أن يكون الإصدار في أيدي المستخدمين، لا يمكنك إجبارهم على التحديث.
هذه القيود تغير كيفية تصميم خط الأنابيب. مراحل البناء واختبار الوحدات تعمل بنفس الطريقة كما في تطبيقات الخلفية. لكن مرحلة النشر تحتاج إلى مسارين منفصلين:
المسار الأول هو للتوزيع الداخلي. قبل إرسال بناء إلى متجر التطبيقات، يحتاج فريقك إلى اختباره على أجهزة حقيقية. منصات مثل Firebase App Distribution لنظام Android وTestFlight لنظام iOS تتيح لك توزيع البناءات لفرق ضمان الجودة والمختبرين التجريبيين دون المرور بعملية مراجعة متجر التطبيقات. يجب على خط الأنابيب الخاص بك تحميل البناءات تلقائيًا إلى هذه المنصات كلما كان إصدار جديد جاهزًا للاختبار.
المسار الثاني هو للإصدار الإنتاجي. هنا يقوم خط الأنابيب بإرسال البناء الموقع إلى Google Play Store أو Apple App Store. لا يمكن لخط الأنابيب التحكم في مدة المراجعة، لكنه يمكنه تتبع الحالة. عندما تتم الموافقة على المراجعة، يمكن لخط الأنابيب تشغيل الإصدار الفعلي للمستخدمين.
بوابات المخاطر لخطوط أنابيب التطبيقات المحمولة يجب أن تتضمن فحوصات خاصة بالتطبيقات المحمولة. تواريخ انتهاء الشهادات، وصلاحية مفاتيح التوقيع، وزيادات رقم الإصدار يجب التحقق منها تلقائيًا. بناء بشهادة منتهية الصلاحية سيتم رفضه من قبل متجر التطبيقات، واكتشاف ذلك بعد انتظار المراجعة أمر مؤلم.
أعلام الميزات تتيح الطرح التدريجي
أعلام الميزات هي آلية تتيح لك تشغيل الميزات أو إيقاف تشغيلها دون نشر كود جديد. تحل مشكلة شائعة: الميزة مكتملة، لكنك لست متأكدًا مما إذا كانت جاهزة لجميع المستخدمين. ربما تحتاج إلى مزيد من الاختبارات. ربما تريد طرحها لنسبة صغيرة من المستخدمين أولاً. ربما تريد القدرة على تعطيلها بسرعة إذا حدث خطأ ما.
بدون أعلام الميزات، خياراتك محدودة. يمكنك تأخير النشر حتى تكون واثقًا، مما يبطئ التسليم. أو يمكنك النشر والأمل في الأفضل، مما يزيد المخاطر. أعلام الميزات تمنحك خيارًا ثالثًا: نشر الميزة في حالة معطلة، ثم تمكينها تدريجيًا.
إضافة أعلام الميزات إلى خط الأنابيب الخاص بك يتطلب تغييرين:
أولاً، يجب على خط الأنابيب التحقق من أن الكود يعمل بشكل صحيح في كلتا الحالتين. عندما تكون الميزة مغلفة بعلم، يجب تشغيل الاختبارات مع تمكين العلم وتعطيله. هذا يكتشف المشكلات حيث يكون منطق علم الميزة نفسه به أخطاء، أو حيث تكسر الحالة المعطلة الوظائف الحالية.
ثانيًا، يجب أن يساعدك خط الأنابيب في تنظيف الأعلام التي لم تعد هناك حاجة إليها. أعلام الميزات التي تبقى في قاعدة الكود إلى الأبد تصبح ديونًا تقنية. تضيف تعقيدًا، وتجعل الكود أصعب في القراءة، وتزيد من خطر الأخطاء. الممارسة الجيدة هي إضافة مرحلة خط أنابيب تتحقق من الأعلام التي تم طرحها بالكامل لجميع المستخدمين لفترة محددة، ثم تنشئ تلقائيًا مهمة لإزالتها.
قائمة تحقق عملية لتوسيع خط الأنابيب الخاص بك
قبل البدء في تنفيذ هذه التغييرات، راجع قائمة التحقق هذه لتحديد ما يحتاج إلى اهتمام:
- هل يمكنك تغيير قيمة تهيئة لبيئة واحدة دون إعادة نشر التطبيق؟
- هل كل تغيير في التهيئة يتم تتبعه في نظام التحكم بالإصدارات ومراجعته قبل التطبيق؟
- هل يقوم خط أنابيب التطبيقات المحمولة بتوزيع البناءات تلقائيًا على المختبرين الداخليين؟
- هل يتحقق خط أنابيب التطبيقات المحمولة من انتهاء صلاحية الشهادة وصلاحية مفتاح التوقيع؟
- هل يتم اختبار أعلام الميزات في كلتا الحالتين (مفعلة ومعطلة)؟
- هل لديك عملية لإزالة أعلام الميزات التي لم تعد هناك حاجة إليها؟
إذا أجبت بـ "لا" على أي من هذه، فلديك خطوة تالية واضحة.
الخلاصة
CI/CD لا يكتمل عندما يتم نشر كود التطبيق بسلاسة. يكتمل عندما يمر كل تغيير يؤثر على سلوك برنامجك - سواء كان كودًا، أو تهيئة، أو تبديل ميزة - عبر عملية خاضعة للتحكم، ومؤتمتة، وقابلة للتدقيق. خطوط أنابيب التهيئة تزيل احتكاك التغييرات الخاصة بالبيئة. خطوط أنابيب التطبيقات المحمولة تتعامل مع القيود الفريدة لتوزيع متجر التطبيقات. أعلام الميزات تمنحك القدرة على التحكم في المخاطر دون إبطاء التسليم.
ابدأ بالمجال الذي يسبب أكبر قدر من الألم لفريقك اليوم. بالنسبة لمعظم الفرق، هذا هو إدارة التهيئة. بمجرد أن يعمل ذلك، انتقل إلى التطبيقات المحمولة أو أعلام الميزات اعتمادًا على ما يقدمه فريقك. الهدف ليس بناء خط الأنابيب المثالي في اليوم الأول. الهدف هو التأكد من أن لا شيء يفلت من الشقوق.