قائمة فحص تسليم الشفرة المصدرية للعملاء والوكالات

ما الذي يجب أن يحققه تسليم الشفرة المصدرية

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

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

ما يُعتبر قابلاً للتسليم يجب أن يكون صريحًا. على الأقل، يتضمن التسليم الكامل عادةً:

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

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

طريقة عملية لتعريف النجاح هي اختبار تحقق: شخص لم يبنِ التطبيق يمكنه تصدير الشفرة (على سبيل المثال من منصة مثل Koder.ai)، اتباع الوثائق، ضبط متغيرات البيئة، تشغيل الهجرات، بناء، ونشر إلى البيئة المتفق عليها.

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

قبل التصدير: اتفق على الملكية والتوقيت

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

حدد تاريخ التسليم وفترة تجميد قصيرة

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

وضّح ملكية الحسابات والفوترة

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

طريقة سريعة لجعل هذا ملموسًا:

• سمّ صاحب الحساب لـ DNS، الاستضافة، والبريد الإلكتروني
• أكد من يدفع كل فاتورة ابتداءً من يوم التسليم
• قرر ما إذا كانت الحسابات ستُنقل أو تُنشأ من جديد باسم العميل
• سجّل جهة الدعم لكل مزود

اكتب هذا بلغة بسيطة حتى يتتبعه الطرفان.

عدّد البيئات ومواقع تشغيلها

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

اجمع الوصول مبكرًا

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

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

أساسيات المستودع والتوثيق المطلوب تضمينه

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

اجعل البنية متوقعة. اهدف إلى مجلدات علوية واضحة مثل frontend/, backend/, mobile/, infra/, scripts/, وdocs/. إذا كان المشروع monorepo، اشرح كيف ترتبط الأجزاء وكيف تشغّل كل منها.

يجب أن يكون README قابلاً للاستخدام من قبل شخص لم يبنِ المشروع. يجب أن يغطي المتطلبات المسبقة وأسرع طريق لتشغيل بيئة تطوير عاملة، بدون تخمين.

ما الذي يجب توثيقه (الحد الأدنى)

ضمّن قسم README قصير يجيب عن:

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

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

أخيرًا، ضمّن سجل تغييرات مُنسق للإصدار الذي يُسلم. يمكن أن يكون CHANGELOG.md أو ملف "ملاحظات إصدار التسليم" يذكر الـ commit/tag بالضبط، ما الذي شُحن، والمشكلات المعروفة.

إذا صُدر الكود من منصة مثل Koder.ai، اذكر نوع المشروع المُولَّد (ويب، خادم، موبايل)، سلسلة الأدوات المتوقعة (على سبيل المثال React, Go, PostgreSQL, Flutter)، وإصدارات نظام التشغيل/الأدوات المدعومة التي يجب أن يستخدمها العميل لتكرار البناء.

متغيرات البيئة: الجرد والتوثيق

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

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

طريقة بسيطة لعرض الجرد:

• اسم المتغير، ما الذي يتحكّم به، وصيغة مثال
• مطلوب أم اختياري، وسلوك الافتراضي إن وُجد
• أين يتم تعيينه (CI، لوحة الاستضافة، ملف محلي .env)
• أي بيئات تحتاج قيمًا مختلفة (dev، staging، production)
• من يملك تغييره (العميل، الوكالة، أو مشاركة)

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

وثّق أين توجد كل قيمة اليوم. كثير من الفرق توزّع القيم عبر أماكن: ملفات .env المحلية للتطوير، متغيرات CI للبناء، وإعدادات الاستضافة وقت التشغيل. إذا صدّرت التطبيق من منصة مثل Koder.ai، ضمّن ملف .env.example وملاحظة قصيرة عن المتغيرات التي يجب تعبئتها قبل أول بناء.

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

مثال ملموس: قد يحتاج واجهة React إلى API_BASE_URL للتطبيق الويب، والـ backend إلى DATABASE_URL وJWT_SIGNING_KEY. إذا كان الاستيجنغ يستخدم دومينًا مختلفًا، اكتب كلا القيمتين وبيّن مكان تغييرها، حتى لا يرسل الفريق إعدادات الاستيجنغ إلى الإنتاج بالخطأ.

تدوير الأسرار: انقل بأمان، ثم تحقق من العمل

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

ابدأ بعمل جرد كامل. لا تتوقف عند كلمات مرور قاعدة البيانات؛ شمل مفاتيح API الخارجية، أسرار عملاء OAuth، أسرار توقيع الويب هوك، مفاتيح توقيع JWT، بيانات اعتماد SMTP، مفاتيح الوصول للتخزين، وأي رموز مؤقتة موجودة في CI.

إليك قائمة فحص بسيطة ليوم التدوير:

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

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

ركّز على التدفقات التي تعتمد على الأسرار:

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

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

أخيرًا، وثّق مكان احتفاظ الأسرار مستقبلاً (خزانة، متغيرات CI، أو إعدادات الاستضافة)، من يمكنه تغييرها، وكيفية التراجع بأمان إذا سبّب التدوير أخطاء.

هجرات قاعدة البيانات وإدارة البيانات

قد يبدو التسليم "مكتملًا" بينما تكون قاعدة البيانات أول جزء يتعطل. عامل الهجرات والبيانات كمنتج قائم بذاته: مُعنَّون، قابلون للتكرار، ومجربون.

ابدأ بكتابة نسخة من إصدار قاعدة البيانات الحالي وأين توجد الهجرات في المستودع. كن محددًا: مسار المجلد، نمط التسمية، وآخر معرف هجرة (أو طابع وقت). إذا كنت تستخدم PostgreSQL (شائع مع backends المكتوبة بـ Go)، اذكر أي امتدادات مطلوبة.

ما الذي يجب توثيقه (حتى يستطيع الآخر تشغيله)

ضمّن دليل تشغيل قصير يجيب عن الأسئلة التالية:

• أي أمر يشغّل الهجرات، وما ترتيب تنفيذ الأشياء (إنشاء قاعدة، تطبيق الهجرات، ثم البيانات التجريبية)
• كيف يختلف الأمر حسب البيئة (محلي، استيجنغ، إنتاج)، بما في ذلك أي أعلام "وضع آمن"
• هل تُطبَّق الهجرات تلقائيًا عند النشر أم يجب تشغيلها يدويًا، ومن المسموح له تشغيلها
• استراتيجية بيانات البذور: لا شيء، للعرض فقط، أو سجلات مطلوبة بسيطة (مستخدم مشرف، إعدادات افتراضية)
• خطة التراجع: ما الذي يمكن عكسه، وما الذي لا يمكن (مثل حذف أعمدة مدمِّر)

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

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

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

البناء وCI: اجعلها قابلة للتكرار

التسليم يكتمل فقط عندما يستطيع شخص آخر إعادة بناء التطبيق من الصفر على جهاز نظيف. يجب أن تتضمن قائمة الفحص أوامر البناء الدقيقة، الإصدارات المطلوبة، والمخرجات المتوقعة (مثل: "حزمة الويب في /dist"، "ثنائي الـ API باسم"، "موقع APK للـ Flutter").

دوّن الأدوات ومديري الحزم الذين تستخدمهم فعلًا، لا ما تظن أنك تستخدمه. لستاك نموذجي قد يكون Node.js (وnpm أو pnpm) لواجهة React، أداة Go للخادم، أدوات عميل PostgreSQL للإعداد المحلي، وFlutter SDK للموبايل.

اجعل تثبيت الاعتماديات متوقعًا. تأكد من الالتزام بملفات القفل (package-lock.json, pnpm-lock.yaml, go.sum, pubspec.lock) وقم بتثبيت نظيف على كمبيوتر جديد أو حاوية نظيفة لإثبات عملها.

وثّق ما يفعله CI خطوة بخطوة حتى يمكن نسخه إلى مزود CI آخر إذا لزم:

• تثبيت الاعتماديات (مع ملفات القفل)
• تشغيل الاختبارات وفحوصات lint
• مخرجات البناء (حزمة الويب، ثنائي الخادم، بناء الموبايل)
• إنتاج أرشيفات (zip، صورة Docker، حزمة إصدار)
• تخزين السجلات وبيانات بناء (الإصدار، الالتزام، التاريخ)

فصل تهيئة وقت البناء عن تهيئة وقت التشغيل. تهيئة وقت البناء تغير ما يتم تجميعه (مثل URL لواجهة برمجية مخبوزة داخل حزمة الويب). تهيئة وقت التشغيل تُحقن عند بدء التطبيق (مثل روابط قاعدة البيانات، مفاتيح API، وعلامات الميزات). الخلط بينهما سبب شائع لظاهرة "يعمل على CI" لكن يفشل بعد النشر.

قدّم وصفة تحقق محلية بسيطة. حتى مجموعة أوامر قصيرة تكفي:

# Web
pnpm install
pnpm test
pnpm build

# API
go test ./...
go build ./cmd/server

# Mobile
flutter pub get
flutter test
flutter build apk

إذا صدّرت من منصة مثل Koder.ai، ضمّن أي ملفات CI مولَّدة أو إعدادات بناء كانت مستخدمة أثناء النشر حتى يتمكن العميل من إعادة إنتاج نفس البناء خارج المنصة.

سكربتات النشر وعملية الإصدار

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

ابدأ بكتابة كيف تتم النشرات اليوم: يدوية بالكامل (يقوم شخص بتشغيل أوامر على الخادم)، مدفوعة بـ CI (خط أنابيب يبني وينشر)، أم عبر منصة مستضافة. اذكر أين توجد التهيئات، وما البيئات المتاحة (dev، staging، production).

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

ما الذي يجب تضمينه مع حزمة النشر

زود العميل بما يكفي للنشر في اليوم الأول:

• أوامر البناء والتشغيل (إصدارات Node, Go, Flutter الدقيقة)
• سكربتات النشر (shell scripts، أهداف Makefile، أو إعدادات خط الأنابيب)
• الوصول المطلوب: أدوار حسابات السحابة، سجل الحاويات، DNS، مسؤول قاعدة البيانات
• ملاحظات إعداد البيئة: أين تُضبط متغيرات البيئة وكيف تختلف حسب البيئة
• تسمية الإصدارات: الوسوم/الإصدارات وكيفية معرفة ما الذي يعمل

اتفق على توقعات وقت التوقف. إذا كان مطلوبًا "صفر توقف"، بيّن ما يعنيه عمليًا (blue-green، نشر تدريجي، نافذة قراءة-فقط للهجرات). إذا كان السماح بالتوقف مقبولًا، حدّد نافذة واضحة.

الأصول الساكنة والتخزين المؤقت نقاط فشل شائعة. اذكر كيف تُبنى الأصول وتُقدّم، متى تُفرَغ الكاشات، وما إذا كان CDN متورطًا.

تراجع يمكنك تنفيذه فعلاً

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

إذا وُلد التطبيق على Koder.ai ثم صدر، اذكر آخر لقطة معرفة-جيدة ونسخة التصدير الدقيقة حتى يتمكن العميل من مطابقة الكود بإصدار يعمل بسرعة.

خطوة بخطوة: تحقق من البناء بعد التصدير

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

قبل البدء، سجّل ما يبدو "صحيحًا": نسخة التطبيق العاملة، commit/tag الحالي (إن وُجد)، وشاشة أو رد API أو اثنين لمقارنتهما. إذا جاء التصدير من منصة مثل Koder.ai، اذكر الطابع الزمني للتصدير أو اللقطة حتى تثبت أنك اختبرت أحدث حالة.

1. أكد أن التصدير يطابق الإنتاج: تحقّق من سجل الالتزامات، ملاحظات الإصدار، أو بيانات بناء الميتاداتا. قارن سلسلة إصدار مرئية أو سلوك صغير (مثل تسمية واجهة مستخدم معينة) بالتطبيق الجاري.
2. اضبط متغيرات البيئة والأسرار: أنشئ تهيئة البيئة المستهدفة (محليًا واستيجنغ). استخدم جرد متغيرات البيئة المقدم وتأكد من عدم وجود قيم مخبوزة في المستودع.
3. ثبت الاعتماديات وشغّل الاختبارات: قم بتثبيت نظيف (بدون node_modules/ أو مجلدات vendor مخبأة). شغّل اختبارات الوحدة وأي فحوص lint كما هو موثق.
4. شغّل الهجرات وابدأ محليًا: شغّل قاعدة البيانات، طبق الهجرات بالترتيب، وابدأ التطبيق. تأكد من أن التطبيق يستطيع القراءة/الكتابة لبيانات أساسية ولا توجد هجرات معلقة.
5. انشر إلى الاستيجنغ، اختبر بسرعة، ثم رُقِّ إلى الإنتاج: انشر باستخدام نفس السكربتات/خط الأنابيب المخطط استخدامها في الإنتاج. ارقَ فقط بعد أن يتطابق الاستيجنغ مع التوقعات.

لاختبارات الدخان، اجعلها قصيرة ومتصلة بالمخاطر:

• تسجيل الدخول/الخروج (أو إنشاء مستخدم اختبار)
• سير عمل أساسي واحد من الطرف إلى الطرف (إنشاء-تعديل-حفظ)
• رسالة بريد إلكتروني/ويب هوك/رد دفع واحد إن وُجد
• التعامل مع الأخطاء الأساسية (إدخال خاطئ، سجل مفقود)
• السجلات لا تُظهر انهيارات متكررة أو أخطاء متعلقة بالأسرار

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

الأخطاء الشائعة في التسليم وكيفية تجنبها

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

الأخطاء التي تسبب معظم مشاكل التسليم

معظم المشكلات تقع في أنماط متكررة:

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

كيفية منعها (دون إضافة أسابيع للعمل)

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

لمتغيرات البيئة، قم بجرد بسيط من ثلاثة أماكن: المستودع، نظام CI، وواجهة الاستضافة. ثم تحقق من ذلك بتشغيل بناء نظيف من جهاز جديد أو حاوية.

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

مثال واقعي: بعد تصدير مشروع من Koder.ai، ينشر العميل بنجاح لكن تفشل المهام الخلفية لأن عنوان صف الانتظار أُعد فقط في لوحة الاستضافة. تدقيق بسيط لمتغيرات البيئة كان سيكشف ذلك. اقترن ذلك بوسم إصدار وتوثيق تراجع (مثال: "أعد نشر الوسم v1.8.2 واستعد آخر لقطة") ويتجنب الفريق وقت التوقف.

قائمة فحص نهائية، مثال مبسط، والخطوات التالية

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

فحوص سريعة (قم بها من استنساخ نظيف)

شغّل هذه الفحوص على لابتوب لم يرَ المشروع من قبل (أو في حاوية/VM نظيفة). هذه أسرع طريقة لاكتشاف ملفات مفقودة، افتراضات مخفية، وبيانات اعتماد قديمة.

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

مثال تسليم بسيط

تسلّم وكالة واجهة React، API مكتوبًا بـ Go، وقاعدة بيانات PostgreSQL. ينسخ فريق العميل المستودع، ينسخون .env.example إلى متغيرات حقيقية، وينشئون بيانات اعتماد جديدة لقاعدة البيانات، موفر البريد، وأي APIs طرف ثالث. يشغّلون go test (أو أمر الاختبار المتفق عليه)، يبنون واجهة React، يطبقون الهجرات على مثيل Postgres جديد، ويشغلون الخدمتين. أخيرًا، ينشرون باستخدام السكربت الموثق ويتأكدون أن الالتزام نفسه يمكن إعادة بناؤه لاحقًا.

الخطوات التالية

اجعل التسليم قصيرًا ومملوكًا. جولة توضيحية مدتها 30 إلى 60 دقيقة غالبًا ما تفوق وثيقة طويلة.

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