لماذا تعتمد استراتيجية النشر على نوع التطبيق الذي تبنيه

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

التطبيق عديم الحالة: بسيط وقابل للاستبدال

تخيل واجهة برمجة تطبيقات للطقس. تقبل اسم مدينة، وتعيد بيانات درجة الحرارة والرطوبة. كل طلب مستقل. التطبيق يجلب بيانات جديدة في كل مرة، لا يخزن شيئًا محليًا، وليس لديه ذاكرة لمن سأل عن ماذا.

هذا النوع من التطبيقات يسمى عديم الحالة. لا يهتم بالطلبات السابقة. كل استدعاء هو صفحة بيضاء.

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

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

التطبيق ذو الحالة: دقيق ومعقد

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

هذا تطبيق ذو حالة. يعتمد على البيانات المستمرة. وهذا يغير كل شيء في النشر.

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

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

طيف التأثير: أداة داخلية مقابل خدمة عامة

تختلف التطبيقات أيضًا في مقدار الضرر الذي يمكن أن تسببه عند تعطلها.

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

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

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

يساعدك مخطط التدفق التالي في تحديد استراتيجية النشر التي تناسب طبيعة تطبيقك ومستوى المخاطرة:

flowchart TD A[ابدأ: ما نوع التطبيق؟] --> B{عديم الحالة أم ذو حالة؟} B -->|عديم الحالة| C{مستوى التأثير؟} B -->|ذو حالة| D{مستوى التأثير؟} C -->|منخفض| E[تحديث تدريجي بسيط] C -->|مرتفع| F[أزرق-أخضر أو كناري] D -->|منخفض| G[تحديث تدريجي مع خطة ترحيل] D -->|مرتفع| H[طرح مرحلي + ترحيل قاعدة بيانات + مراقبة] E --> I[تراجع سريع بالتبديل] F --> J[تحويل حركة المرور تدريجيًا] G --> K[اختبار إجراء التراجع] H --> L[خطة تراجع متعددة الخطوات]

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

التبعيات: الاقتران الخفي

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

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

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

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

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

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

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

يجب أن يعكس خط الأنابيب الخاص بك طبيعة التطبيق الذي يخدمه. هذا يعني:

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

قائمة مراجعة عملية لتقييم احتياجات النشر لتطبيقك

قبل تصميم أو تعديل خط أنابيب النشر الخاص بك، راجع قائمة المراجعة هذه:

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

الخلاصة الملموسة

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