النشر مقابل الإصدار: لماذا تحتاج إلى معرفة الفرق

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

لكن إليك السؤال غير المريح: هل يرى المستخدمون الميزة الجديدة بالفعل؟

إذا أجبت بـ "نعم" دون تفكير مرتين، فربما تخلط بين شيئين يجب أن يبقيا منفصلين. النشر (Deploy) والإصدار (Release) ليسا نفس الإجراء، ومعاملتهما كشيء واحد يخلق مخاطر غير ضرورية.

ماذا يعني النشر (Deploy) فعليًا

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

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

النشر يجيب على السؤال "هل الإصدار الجديد موجود على الخادم؟" لكنه لا يجيب على "هل يستخدمه المستخدمون؟"

ماذا يعني الإصدار (Release) فعليًا

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

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

لماذا تغيير الفصل بينهما كل شيء

يمكنك التحقق قبل أن يراه المستخدمون

يوضح مخطط التسلسل التالي هذا الفصل:

sequenceDiagram participant Dev as Developer participant Server as Production Server participant Users as Users Dev->>Server: Deploy new artifact Note over Server: New version running Dev->>Server: Run smoke tests & verify Note over Dev,Server: Verification step Dev->>Server: Release (enable feature) Server->>Users: Users see new feature

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

هذا هو الفرق بين "نشرنا ونأمل أن يعمل" و "نشرنا، تحققنا من أنه يعمل، ثم قررنا السماح للمستخدمين برؤيته."

تتحكم في موعد وصول التغييرات إلى المستخدمين

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

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

الاسترجاع (Rollback) يصبح أكثر أمانًا

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

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

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

كيفية فصل النشر والإصدار عمليًا

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

نهج آخر هو توجيه حركة المرور (traffic routing). انشر الإصدار الجديد على مجموعة فرعية من الخوادم، ثم قم بتوجيه المستخدمين تدريجيًا إلى الإصدار الجديد. هذا شائع في عمليات النشر الكناري (canary deployments) والنشر الأزرق-الأخضر (blue-green deployments). يحدث النشر عندما يكون الإصدار الجديد على الخوادم. يحدث الإصدار تدريجيًا مع تحول حركة المرور.

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

مفاهيم خاطئة شائعة

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

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

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

قائمة مراجعة عملية سريعة

قبل نشرك التالي، اطرح هذه الأسئلة:

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

الخلاصة الحقيقية

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

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

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