استلام مشروع تطبيق يعني أن الجهة المستلمة تملك الوصول المصرح به والمواد اللازمة، وتستطيع تنفيذ العمل التشغيلي المتفق عليه دون اعتماد خفي على جهاز المورد أو حسابه الشخصي. لذلك اجعل التسليم تجربة تشغيل موثقة، لا مجلداً مضغوطاً واجتماع شرح فقط. اكتب متطلباته قبل نهاية المشروع حتى لا تتحول أهم أسئلة الملكية إلى تفاوض طارئ.
ضمن تطوير التطبيقات، يجب تحديد الشيفرة والخصائص والاختبارات ومخرجات التسليم. أما الملكية الفكرية وحقوق الاستخدام ومكونات الطرف الثالث فتحتاج مراجعة العقد من الشخص المؤهل لدى المنشأة؛ وجود نسخة من الشيفرة لا يحسم كل الحقوق القانونية تلقائياً.
افصل الملكية عن الوصول وعن القدرة
قد تكون الشركة صاحبة حساب المستودع لكن لا تملك صلاحية إعداد النشر. وقد تملك الوصول إلى الشيفرة دون معرفة النسخة المستخدمة حالياً. وقد يعمل التطبيق في حساب المورد مع فاتورة يدفعها العميل. هذه أوضاع مختلفة، ويجب تسجيل كل أصل وصاحبه ومديره وطريقة استعادته.
يشمل سجل الأصول المستودعات وبيئات الاختبار والإنتاج والنطاقات وحسابات التوزيع والخدمات الخارجية وأماكن حفظ الأسرار. لا تضع كلمات المرور أو مفاتيح الوصول داخل قائمة الأصول؛ سجّل موقع الإدارة والمالك والطريقة المأذونة للحصول على الوصول. استخدم حسابات مؤسسية وأدواراً محددة عندما تسمح الخدمة بذلك.
حدّد أيضاً ما الذي لا يشمله التسليم: خدمات خارجية مرخصة، أدوات خاصة بالمورد، أو عناصر تحتاج اشتراكاً مستقلاً. الغرض ليس مطالبة المورد بأصل لا يملك حق نقله، بل كشف التبعية والحق والتكلفة قبل القبول.
اختبر البناء من نقطة نظيفة
اطلب أن يبني شخص من الفريق المستلم النسخة المتفق عليها في بيئة نظيفة مناسبة، باستخدام المستودع والتعليمات وبيانات الوصول المأذونة. إذا لم تنجح العملية إلا على جهاز المطور الأصلي، فهناك متطلبات غير موثقة أو اعتماد غير منقول يحتاج معالجة.
يجب أن تتضمن التعليمات نسخة الأدوات المطلوبة، وطريقة تثبيت التبعيات، ومتغيرات البيئة بأسمائها ووظائفها دون قيم سرية، وخطوات إعداد البيانات التجريبية، وكيفية تشغيل الاختبارات. لا يشترط ادعاء تطابق ثنائي دقيق للملفات ما لم يكن مطلوباً ومثبتاً؛ المطلوب هنا بناء قابل للتكرار يؤدي الوظائف المتفق عليها.
حدد العلاقة بين المستودع والإصدار المشغّل برقم إصدار أو مرجع واضح. امتلاك آخر نسخة في المستودع لا يثبت أنها النسخة الموجودة على الإنتاج أو التي اختبرها الفريق.
مثال افتراضي: نقل مسؤولية تطبيق حجوزات
لنفترض أن منشأة تستلم تطبيقاً بعد تطويره. تضم تجربة التسليم ثلاث خطوات: بناء نسخة اختبار من مرجع معتمد، ونشرها في بيئة تجريبية مملوكة للمنشأة، وإعادة النسخة السابقة عند تجربة تغيير غير مقبول. هذه خطوات تعليمية وليست تصريحاً بتجربة تعطل على الإنتاج.
ينجح البناء، لكن النشر يتوقف لأن مهمة آلية تستخدم رمز وصول مرتبطاً بحساب موظف لدى المورد. يسجل الفريق ذلك كعائق تسليم، وينقل إعداد الوصول بالطريقة المصرح بها إلى هوية مناسبة يملكها العميل، ثم يعيد التجربة. لا ينسخ الرمز في محادثة ولا يبقيه سراً غير مسجل بدعوى أن النظام يعمل الآن.
بعد النشر، ينفذ الفريق المستلم رحلة إنشاء حجز وتعديله، ويحدد مكان السجلات والتنبيه، ثم يشرح ماذا يفعل عند فشل نشر لاحق. إذا بقي سؤال من يوافق على العودة أو من يصحح بيانات تغيرت بلا إجابة، لا توصف خطة التعافي بأنها مكتملة.
النشر يحتاج قواعد وصاحب قرار
تربط البنية التحتية ككود وأتمتة النشر الإعدادات والفحوص ونقاط الاعتماد وخطوات التعافي. اطلب بياناً لما يفعله المسار الآلي وما يحتاج موافقة بشرية، ومن يستطيع تعديل قواعده. لا تجعل نجاح زر النشر بديلاً عن فهم الصلاحيات.
توضح وثائق بيئات النشر في GitHub إمكان ربط البيئة بقواعد حماية، مع اختلاف الإتاحة بحسب الخطة ونوع المستودع. إذا استُخدمت هذه المنصة، تحقق من القدرات في الحساب الفعلي؛ لا تفترض أن كل حساب يملك ضوابط المراجعة نفسها.
إذا كان التطبيق يعتمد على بنية سحابية، تدخل خريطة الموارد والتبعيات والافتراضات التشغيلية ضمن نطاق تصميم ومراجعة البنية السحابية المناسب. لا يتضمن تسليم مخطط وحده تشغيل البنية أو التزام توافر دائم دون اتفاق إضافي.
حزمة قبول وحدود دعم واضحة
يشمل اختبار وضمان جودة البرمجيات أدلة النسخة المقبولة والرحلات المختبرة والعيوب المتبقية وقراراتها. اجعل اختبار التسليم جزءاً من القبول، بحيث يتأكد الفريق المستلم من الوصول والبناء والتشغيل، وليس فقط من العرض النهائي للمورد.
دوّن بداية فترة الدعم ونهايتها وقنوات البلاغات وتعريف العيب والتغيير الجديد وساعات التغطية ومسؤول الخدمات الخارجية. لا تستخدم عبارة «دعم مجاني» دون حدود. وبعد إثبات انتقال المسؤولية، راجع صلاحيات المورد وأزل ما لم يعد مطلوباً بتفويض مناسب، مع حفظ سجل الإجراءات وعدم تعطيل خدمة لازمة دون تنسيق.
أسئلة شائعة
هل يكفي أن نستلم ملف الشيفرة؟
لا. تحتاج معرفة النسخة المعتمدة وتعليمات البناء والتبعيات والإعدادات والوصول المأذون إلى الخدمات. اختبر قدرة الفريق على تشغيل ما استلمه.
هل يجب أن تكون كل الحسابات باسم الشركة؟
حدد الأصول التي ينبغي أن تديرها الشركة بحسب الخدمة والعقد، وراجع ما يمكن نقله فعلياً. المهم ألا تبقى تبعية حرجة لشخص غير معلوم دون قرار واعٍ.
هل استعادة النسخة السابقة تعيد البيانات أيضاً؟
لا تفترض ذلك. قد تتغير البيانات أو بنيتها بشكل يحتاج إجراء مختلفاً. يجب أن توضح خطة التعافي حدود استرجاع التطبيق والبيانات وتختبر الخطوات المناسبة.
متى نخفض صلاحيات المورد؟
بعد إثبات وصول الفريق المستلم واستمرار الوظائف اللازمة، وبحسب اتفاق الدعم. تجنب القطع العشوائي الذي يوقف مهمة آلية قبل نقل مسؤوليتها.
اطلب جلسة تسليم يقودها المستلم ويُجيب فيها المورد عند الحاجة. القدرة المثبتة على البناء والنشر والمتابعة أقوى من وثائق لم يجرّبها أحد.
المصدر الفني
- GitHub: إدارة بيئات النشر، روجع في 26 أكتوبر 2026. الملكية والحقوق وشروط الدعم تُراجع تعاقدياً.
