عندما يكون كل نشر قصة مختلفة: فخ التسليم العشوائي

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

لا أحد يشتكي، لأن الأمور تعمل في الغالب. حتى لا تعمل.

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

هذا هو المستوى الأول من نضج التسليم: العشوائي (Ad Hoc). كل شيء يدوي. كل شيء مختلف في كل مرة. والعملية بأكملها تعتمد على من هو متاح، وليس على ما هو موثق أو آلي.

مشكلة الاعتماد على الأفراد

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

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

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

flowchart TD A[Developer starts deployment] --> B{Which method?} B --> C[FTP files to server] B --> D[Run personal script] B --> E[Direct edit on production] C --> F[Files may be incomplete] D --> G[Script only works on one machine] E --> H[Risk of wrong SQL command] F --> I[Deployment fails silently] G --> J[Another dev cannot run it] H --> K[No rollback possible] I --> L[Person on leave - no fix] J --> L K --> L L --> M[Deployment takes hours]

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

النشر اليدوي: لا توجد عمليتان متماثلتان

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

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

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

تغييرات قاعدة البيانات بدون شبكة أمان

إدارة قاعدة البيانات في المستوى 1 خطيرة بشكل خاص. يتم تطبيق تغييرات المخطط (Schema) مباشرة على قاعدة بيانات الإنتاج. مطور يسجل الدخول إلى خادم قاعدة البيانات، ويشغل جملة ALTER TABLE، ويأمل ألا ينكسر شيء.

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

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

البنية التحتية المدارة بالذاكرة

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

لا يوجد بنية تحتية ككود (Infrastructure as Code). لا توفير آلي. لا توجد عملية إعداد قابلة للتكرار. يعتمد الفريق على الذاكرة، والملاحظات اللاصقة، وحسن نية من قام بإعداد الخادم الأصلي.

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

لماذا تبقى الفرق في المستوى 1

البقاء في المستوى 1 ليس علامة على الكسل أو نقص المهارة. العديد من الفرق تبقى هنا لأسباب وجيهة:

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

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

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

الخطوة الأولى ليست شراء أداة

الانتقال إلى ما بعد المستوى 1 لا يتطلب أدوات باهظة الثمن أو خطوط أنابيب معقدة. الخطوة الأولى أبسط وأصعب: الاعتراف بأن العملية الحالية غير موثوقة، والبدء في توثيق ما يحدث بالفعل أثناء النشر.

قبل أن تؤتمت أي شيء، تحتاج إلى معرفة ما تقوم بأتمتته. قبل بناء خط أنابيب، تحتاج إلى الاتفاق على الخطوات. قبل شراء منصة CI/CD، تحتاج إلى فهم سير العمل الخاص بك.

قائمة مراجعة عملية للانتقال إلى ما بعد العشوائية

إذا كنت تتعرف على فريقك في هذا الوصف، فإليك من أين تبدأ:

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

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

الخلاصة الملموسة

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