من هم الأطراف المعنية فعليًا عند نشر التطبيق إلى الإنتاج

ينهي المطور تطوير ميزة جديدة. يتم ترجمة الكود بنجاح. تجتاز الاختبارات محليًا. يتم الموافقة على طلب السحب (Pull Request). ثم يبدأ العمل الحقيقي.

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

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

المشكلة هي أن معظم الفرق لا تفكر في هذه الأدوار حتى يحدث خطأ ما. تتم مراجعة الأمان بعد أن يكون الكود قد نُشر بالفعل في البيئة التجريبية (Staging). يكتشف مسؤول قاعدة البيانات (DBA) وجود ترحيل (Migration) عندما يكون النشر في منتصفه. يسمع مدير المنتج عن تأخير من تذكرة دعم، وليس من فريق الهندسة.

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

يُظهر الرسم البياني أدناه كل دور واهتمامه المركزي، وكيفية ارتباطهم أثناء دورة حياة الإصدار.

المطور: كتابة الكود هي البداية فقط

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

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

ضمان الجودة (QA): اكتشاف المشكلات قبل المستخدمين

وظيفة QA هي اكتشاف ما تفتقده الاختبارات الآلية. ليس كل خطأ له حالة اختبار. ليست كل حالة حافة (Edge Case) مغطاة. يقوم QA بإجراء اختبارات استكشافية، ويتحقق من التدفقات التي لم تكن في معايير القبول، ويتحقق من أن الميزة تحل المشكلة التي صُممت لحلها بالفعل.

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

DevOps: بناء المسار من الالتزام (Commit) إلى الإنتاج

يقوم DevOps ببناء وصيانة خط الأنابيب (Pipeline) الذي يحول الكود إلى تطبيق قيد التشغيل. يقومون بإعداد عملية البناء، وإدارة نصوص النشر (Deployment Scripts)، والتعامل مع تكوين البيئة، والتأكد من أن خط الأنابيب يعطي ملاحظات واضحة عند فشل شيء ما.

يتعامل DevOps أيضًا مع الأجزاء الفوضوية: إدارة الأسرار (Secrets Management)، والوصول إلى الشبكة بين الخدمات، وتخزين القطع الأثرية للبناء (Build Artifacts)، والمراقبة التي تخبرك ما إذا كان النشر قد نجح بالفعل. عندما يكون خط الأنابيب بطيئًا أو غير موثوق، يشعر بذلك كل دور آخر.

SRE: الحفاظ على استقرار التطبيق بعد النشر

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

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

مسؤول قاعدة البيانات (DBA): حماية طبقة البيانات

تغييرات قاعدة البيانات هي الجزء الأكثر خطورة في أي نشر. يمكن أن يؤدي الترحيل (Migration) السيئ إلى إتلاف البيانات، أو قفل الجداول، أو إيقاف التطبيق لدقائق أو ساعات. يراجع DBA كل تغيير في هيكل قاعدة البيانات (Schema)، ويتحقق من تأثير الأداء، ويخطط لاستراتيجية الترحيل بحيث لا تمنع القراءة أو الكتابة أثناء الانتقال.

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

مهندس الأمان: إغلاق الأبواب قبل فتحها

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

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

مدير المنتج: تحديد ما سيتم إصداره ومتى

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

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

مدير الإصدارات: تنسيق العملية بأكملها

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

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

قائمة تحقق عملية لإصدارك القادم

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

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

الخلاصة

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

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