هندسة الإصدار كتخصص احترافي

هندسة الإصدار كتخصص احترافي

في معظم الشركات الناشئة، يعني "النشر" قيام مهندس بالاتصال بخادم عبر SSH وتشغيل git pull. أما في Google، فنشر الخلفية البرمجية لمحرك البحث يستلزم مئات المهندسين، وعشرات البوابات الآلية، وترقية الحزم عبر خمس بيئات، والتوقيع التشفيري، وعمليات التراجع المنسقة، وفريقاً متخصصاً — فريق هندسة الإصدار (RelEng) — مهمته الوحيدة إخفاء كل هذا التعقيد عن مهندسي المنتج. يحدد هذا الدرس ماهية هندسة الإصدار، وما الذي تملكه، ولماذا يعدّ مبدأ "ابنِ مرة واحدة، ارقِّ في كل مكان" الأساسَ الذي يتيح التسليم الآمن على نطاق واسع.

ما الذي تملكه هندسة الإصدار فعلاً

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

عملياً، في منظمة تقنية كبرى، يكون فريق هندسة الإصدار مسؤولاً عن:

• تصميم نظام البناء والبنيات المعزولة (Hermetic Builds): تحديد طريقة تحويل الكود المصدري إلى ملفات تنفيذية أو صور حاويات، مع ضمان أن المصدر ذاته ينتج دائماً حزمة متطابقة بصرف النظر عن وقت البناء أو مكانه.
• إدارة الحزم: أين تُخزَّن الحزم (السجلات ومخازن البيانات الثنائية)، وكيف تُعنوَن، وإلى متى تُحتفظ، ومن يستطيع الوصول إليها.
• خطوط أنابيب الترقية: الآلية الآلية التي تنقل الحزمة من حالة البناء حتى وصولها للمستخدمين، بوابةً بوابة وبيئةً بيئة.
• مخططات الإصدار وجداول الإطلاق: تحديد ما يُعدّ إصداراً، وطريقة ترقيم الإصدارات، ووتيرة الإطلاق (التسليم المستمر لكل commit مقابل قطارات الإصدار المجدولة).
• إجراءات التراجع والإصلاحات الطارئة: ضمان إمكانية التراجع عن كل إصدار بسرعة ودون تدخل يدوي، وتحديد مسار التصعيد للتصحيحات الطارئة.
• أمن سلسلة التوريد: توقيع الحزم، التحقق من مصدرها (SLSA)، إدارة بيانات اعتماد البناء، ومنع التلاعب بين البناء والنشر.

المبدأ الأساسي: ابنِ مرة واحدة، ارقِّ في كل مكان

المفهوم الأكثر أهمية في هندسة الإصدار بسيط في ظاهره: تُبنى الحزمة مرة واحدة فقط، وتلك الحزمة المتطابقة تُرقَّى عبر كل بيئة حتى تصل إلى الإنتاج. لا تُعاد العملية من المصدر لبيئة التجريب. ولا للإنتاج. تأخذ الملف التنفيذي أو الصورة التي تم التحقق منها في التطوير، وتمضي بها للأمام.

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

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

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

• Dev/CI: اختبارات الوحدة، الـ linting، تحليل الأمن الثابت (SAST)، مسح التراخيص
• Staging: اختبارات التكامل، اختبارات العقود، اختبارات الحمل بجزء من ترافيك الإنتاج
• Canary: ترافيك المستخدمين الحقيقيين بنسبة 1–5%، مقارنة آلية لمعدلات الأخطاء وبَواديّ الزمن (p50/p99) مقابل الإصدار المستقر
• Production: طرح تدريجي (10% ثم 50% ثم 100%)، مراقبات معدل استنزاف SLO، محفزات تراجع آلية

لماذا توجد هندسة الإصدار كوظيفة مستقلة

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

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

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

مصدر الحزمة: معرفة ما أطلقته

متطلب أساسي في هندسة الإصدار الحديثة هو تتبع المصدر (Provenance) — القدرة على الإجابة، لأي حزمة في الإنتاج، عن: أي commit مصدري بناها، على أي عداء CI، في أي وقت، بأي إصدارات من التبعيات. بدون تتبع المصدر، يكون هجوم سلسلة التوريد (كاختراق SolarWinds، حين حقن المهاجمون كوداً خبيثاً في عملية البناء ذاتها) غير قابل للاكتشاف لاحقاً.

يحدد إطار SLSA (Supply-chain Levels for Software Artifacts، يُنطق "salsa") أربعة مستويات من ضمانات تتبع المصدر. يجب أن تستهدف معظم الأنظمة الإنتاجية مستوى SLSA 3 أو أعلى:

• SLSA 1: تتبع المصدر موجود (سجل البناء مُنشأ)
• SLSA 2: تتبع المصدر موقَّع من خدمة البناء
• SLSA 3: تتبع المصدر مُنشأ من منصة بناء مقواة وقابلة للتدقيق (مثل GitHub Actions مع توقيع OIDC، أو Google Cloud Build، أو Tekton Chains)
• SLSA 4: بناء معزول وقابل للإعادة؛ مراجعة من طرفين لكل تغيير في عملية البناء

على الصعيد العملي، يعني SLSA 3 أن نظام CI يُنشئ شهادة تتبع مصدر — وثيقة JSON موقَّعة تشفيرياً تقول "الحزمة sha256:abc123 بُنيت من commit a7f3d91 في المستودع github.com/myorg/api بواسطة تشغيل GitHub Actions رقم 12345678". تُخزَّن هذه الشهادة جنباً إلى جنب مع الحزمة في السجل وتُتحقق منها وقت النشر.

سجل الحزم: المصدر الوحيد للحقيقة للأشياء القابلة للنشر

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

• صور الحاويات: بروتوكول Docker Registry v2 — AWS ECR، Google Artifact Registry، GitHub Container Registry (GHCR)، JFrog Artifactory، Harbor
• حزم JVM: Maven/Gradle — Nexus، Artifactory، GitHub Packages
• حزم Python: متوافق مع PyPI — Artifactory، AWS CodeArtifact، Google Artifact Registry
• مخططات Helm: سجلات OCI أو ChartMuseum
• ملفات ثنائية عامة: S3، GCS، Azure Blob Storage، Artifactory Generic repos

يفرض السجل المُشغَّل جيداً ثلاث سياسات تلقائياً:

1. عدم القابلية للتغيير: بمجرد رفع حزمة بعلامة إصدار معينة، لا يمكن استبدالها. إذا احتجت للتعديل، تنشر إصداراً جديداً. (العلامات القابلة للتغيير كـ latest مقبولة فقط كاختصار للتسهيل، ليس كمعرّف نشر أبداً.)
2. فحص الثغرات: تُفحص جميع الصور المرفوعة مقابل قواعد بيانات CVE (Trivy، Grype، AWS Inspector) وتُصنَّف تلقائياً. الثغرات عالية الخطورة تمنع الترقية.
3. سياسات الاحتفاظ: حذف تلقائي للحزم الأقدم من N يوم أو ما بعد N إصدار، باستثناء الحزم المُصنَّفة كمرشحات إصدار أو إصدارات إنتاجية، والتي تُحتفظ إلى أجل غير مسمى أو للمدة المطلوبة للامتثال (عادة 7 سنوات في القطاعات المنظَّمة).

من النظرية إلى الممارسة: ماذا يفعل مهندس الإصدار صباح الاثنين

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

• مراجعة تشغيل الترقية الآلي في عطلة الأسبوع — فحص أي الخدمات تقدمت من التجريب إلى Canary، وأيها فشل في فحوصات SLO وبقي، ولماذا.
• فرز CVE رصدته Trivy على صورة قاعدة تستخدمها 12 خدمة — تحديد الخطورة، ومعرفة إن كانت صورة قاعدة مُصلَّحة متاحة، والتنسيق لإعادة بناء معجَّلة.
• مراجعة pull request من فريق منتج يطلب إضافة بوابة اختبار تكامل جديدة لخط أنابيب ترقيتهم.
• تحديث سياسة التحقق من شهادة SLSA في وحدة تحكم القبول لنشر لبدء إنفاذ تتبع المصدر على فئة جديدة من الخدمات.
• تشغيل تمرين فوضى: وضع علامة "محجور عليها" على حزمة إنتاجية في السجل والتحقق من أن نظام النشر يرفض ترقيتها.

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