التشريد باستخدام Zinnector®: اربط، تحقق، ادفع

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

تسجيل الدخول باستخدام مفتاح API

أنشئ مفتاحاً في لوحة التحكم ضمن Settings → API keys، ثم:

zinnector login

يتم كتابة المفتاح عند ظهور موجه الأوامر — وهو لا يُقبل أطلاْقاً على سطر الأوامر، لئلا ينتهي به المطاف في سجل الصدفة (shell history) أو قائمة العمليات. في التكامل المستمر (CI)، قم بتمريره عبر الأنابيب: echo "$ZINN_API_KEY" | zinnector login --profile ci، أو قم بتعيين ZINNECTOR_TOKEN وتخطَ أمر login تماماً. يتم التحقق من المفتاح قبل تخزينه، ويُخزن بصلاحيات ملف 600. يوضح الأمر zinnector whoami --scopes المؤسسة التي سجلت الدخول إليها والصلاحيات التي يحملها المفتاح؛ ويتم تصنيف مفتاح البيئة التجريبية (sandbox) على هذا الأساس.

ربط المشروع بفتحة استضافة

zinnector link                                   # اختر موقعاً من القائمة
zinnector link example.com --repo acme/site --branch main

يكتب الأمر link معرف الموقع في ملف zinnector.json، وما لم تقتمرر --no-repo، فإنه يربط مستودع git الخاص بالمشروع بالموقع على المنصة بحيث يؤدي النشر إلى تحديثه. قم بإدراج ملف zinnector.json في نظام التحكم بالإصدارات: سيتمكن الزميل الذي يقوم باستنساخ المستودع من النشر إلى نفس المكان دون الحاجة لإخباره بذلك. فهو لا يحتوي على أي سر.

قراءة الفحص المسبق

zinnector check

هذا هو الأمر الأساسي الذي وجِدت واجهة سطر الأوامر (CLI) من أجله. فهو يقارن مشروعك بفتحة الاستضافة التي على وشك النشر إليها ويطبع كل اختلاف — وكل مقارنة تعذر إجراؤها:

• إصدار PHP، حيث يتم تصنيف فجوة الإصدار الرئيسي على أنها عالية لأنها تؤدي حتماً إلى تعطل الموقع، بينما تُصنف الفجوة الفرعية بدرجة أدنى، لأن اعتبار كل شيء حرجاً يعلم المستخدمين تخطي التحذير.
• ما إذا كان بإمكان الفتحة الانتقال إلى الإصدار الذي بنيت عليه، وما إذا كان إصدار PHP الخاص بالفتحة قد تجاوز فترة الدعم، وما إذا كان الجهاز قد طبق الإصدار فعلياً أم أنه تبلغ به فقط.
• حجم مشروعك وعدد ملفاته مقابل مساحة القرص الثابت والـ inodes المتبقية فعلياً على الفتحة — إذ يمكن لشجرة ملفات WordPress أن تنفد مساحتها بينما تكون أقل بكثير من الحد الأقصى المسموح به للقرص.
• إصدارات WordPress على كلا الجانبين، وما إذا كانت الفتحة قد أنهت إعدادها، وما إذا كان المستودع متصلاً لإجراء النشر إليه.

إنه يطلق تحذيرات فقط، ولا يقوم بالحظر أبداً. يمكن تجاوز كل نتيجة باستخدام الأمر zinnector push --force، لأنك تعلم أموراً تتعلق بموقعك الخاص لا يعرفها أداة الفحص. تُبلغ عن أي مقارنة تعذر إجراؤها على أنها غير معروفة (unknown)، وليس كحالة نجاح أبداً، ويُظهر الملخص دائماً عدد تلك الحالات. بشكل افتراضي، يكون إصدار PHP المحلي هو الإصدار المحدد في ملف zinnector.json؛ بينما يقوم --probe بتمكين بيئة التشغيل المحلية وقياسها بدلاً من ذلك. يؤدي --strict إلى إنهاء التنفيذ برمز خطأ غير الصفر عند وجود حالات غير معروفة أيضاً، وهو ما تتطلبه بوابات التكامل المستمر (CI).

النشر

zinnector push

يقوم الأمر push بتشغيل الفحص المسبق، ودفع الالتزامات (commits) الخاصة بك، وبدء عملية النشر ومراقبتها حتى اكتمالها، مع طباعة الحالة النهائية والالتزامات المنشورة. ينفذ --dry-run كل شيء باستثناء النشر الفعل؛ بينما يبدأ --no-wait عملية النشر ويخرج فوراً؛ ويقوم --no-git بنشر ما تمتلكه المنصة بالفعل دون الحاجة للدفع. إذا لم تكن الالتزامات المنشورة هي التي تم دفُعها للتو، فسيتم الإشارة إلى ذلك.

عند حدوث خطأ ما

zinnector deploys example.com        # سجل النشر — الحالة، الالتزام، المُشغِّل، الرسالة
zinnector logs example.com --build   # سجل البناء لأحدث عملية نشر
zinnector logs example.com --error   # سجل الأخطاء الخاص بالموقع
zinnector deploy example.com         # إعادة نشر ما تمتلكه المنصة بالفعل
zinnector ai "why is my deploy failing?"

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

ذات صلة

• البدء · التطوير المحلي · مرجع الأوامر · استكشاف الأخطاء وإصلاحها