النشر: الفعل النشط لوضع الأرتيفكت في البيئة

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

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

ما يحدث فعليًا أثناء النشر

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

إليك مثال ملموس على شكل هذه الخطوات كأوامر شل:

scp myapp-v1.2.0.jar user@staging-server:/opt/myapp/ && \
ssh user@staging-server "systemctl stop myapp && \
  cp /opt/myapp/myapp-v1.2.0.jar /opt/myapp/current.jar && \
  systemctl start myapp"

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

يوضح مخطط التسلسل التالي الفصل بين النشر والإصدار:

sequenceDiagram participant AR as Artifact Registry participant DT as Deployment Tool participant S as Server participant LB as Load Balancer DT->>AR: سحب الأرتيفكت v1.2.0 DT->>S: نقل الأرتيفكت DT->>S: إيقاف العملية القديمة (v1.1.0) DT->>S: بدء العملية الجديدة (v1.2.0) DT->>S: التحقق من الصحة S-->>DT: سليم Note over DT,LB: اكتمل النشر DT->>LB: تحويل حركة المرور إلى v1.2.0 Note over DT,LB: يحدث الإصدار

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

النشر مقابل الإصدار

النشر هو إجراء تقني. تضع أرتيفكت في بيئة وتشغله. الإصدار (Release) يتعلق بالوصول. يجيب على السؤال: متى يبدأ المستخدمون فعليًا في استخدام الإصدار الجديد؟

تخيل أن فريقك ينشر الإصدار 1.2.0 إلى بيئة الإنتاج في الساعة 2:00 صباحًا. خوادم الإنتاج تشغل الآن الإصدار الجديد، لكن الفريق يتعمد عدم توجيه حركة مرور المستخدمين إليه بعد. لقد حدث النشر. لم يحدث الإصدار. المستخدمون لا يزالون على الإصدار القديم. يمكن للفريق التحقق من أن الإصدار الجديد سليم قبل فتح الباب.

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

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

النشر ليس دائمًا سلسًا

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

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

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

الآثار العملية

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

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

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

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

قائمة تحقق بسيطة للنشر

قبل أن تعتبر النشر مكتملاً، راجع هذه النقاط:

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

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

الخلاصة

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

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