المنصة، خط الأنابيب، واستراتيجية النشر كنظام واحد

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

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

لماذا تأتي هندسة المنصة أولاً

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

هندسة المنصة تحل هذه المشكلة من خلال توفير أساس متسق. تجيب على السؤال: كيف تحصل الفرق على بيئات دون إعادة بناء كل شيء من الصفر في كل مرة؟ قد تكون المنصة عبارة عن مجموعة Kubernetes مع قوالب موارد موحدة، أو مجموعة من وحدات Terraform التي يستخدمها كل فريق، أو طبقة خدمة مُدارة تجرد تفاصيل البنية التحتية بالكامل.

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

وحدة Terraform مشتركة تجعل هذا الاتساق قابلاً للتكرار:

# modules/team-namespace/main.tf
resource "kubernetes_namespace" "team" {
  metadata {
    name = var.team_name
    labels = {
      team    = var.team_name
      env     = var.environment
      managed = "platform"
    }
  }
}

resource "kubernetes_resource_quota" "limits" {
  metadata {
    name      = "${var.team_name}-quota"
    namespace = kubernetes_namespace.team.metadata[0].name
  }
  spec {
    hard = {
      pods                = var.max_pods
      requests.cpu        = var.max_cpu
      requests.memory     = var.max_memory
      limits.cpu          = var.max_cpu
      limits.memory       = var.max_memory
      persistentvolumeclaims = var.max_pvcs
    }
  }
}

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

خط الأنابيب كعمود فقري للتسليم

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

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

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

استراتيجية النشر تتعلق بالمستخدمين، وليس التكنولوجيا

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

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

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

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

الطبقات الثلاث يجب أن تُصمم معًا

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

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

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

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

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

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

قائمة تحقق عملية لنظام التسليم الخاص بك

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

• هل يمكن لكل فريق نشر خدمته باستخدام نفس قالب خط الأنابيب؟
• هل توفر المنصة نفس السلوك في بيئتي التدريج والإنتاج؟
• هل يمكنك التراجع عن النشر دون تدخل يدوي؟
• هل يتضمن خط الأنابيب خطوات تحقق تطابق استراتيجية النشر الخاصة بك؟
• هل يمكن للمنصة دعم استراتيجية النشر التي اخترتها دون حلول بديلة؟
• هل عملية ترحيل قاعدة البيانات مدمجة في خط الأنابيب، وليست مُدارة بشكل منفصل؟
• هل يمكنك النشر خلال ساعات العمل دون خوف من تعطيل المستخدمين؟

إذا كانت أي إجابة "لا"، فهناك فجوة بين الطبقات. أصلح الفجوة قبل توسيع النظام.

الخلاصة

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