سكربت PowerShell بسيط لتسريع نشر Laravel على Hostinger

يفترض أن يكون نشر مشروع Laravel على استضافة مشتركة إجراءً روتينيًا. بالنسبة إليّ، لم يكن الأمر كذلك غالبًا.

كان كل تحديث صغير يتبع الخطوات نفسها:

• بناء المشروع.
• مراجعة الملفات يدويًا.
• فتح WinSCP.
• رفع الملفات عبر SFTP.
• انتظار اكتمال النقل.
• التأمل ألا يكون ملف مهم قد نُسي.

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

المشكلة

لم تكن المشكلة في إمكانية النشر، بل في الاحتكاك الذي تضيفه العملية إلى كل إصدار.

أردت أداة تستطيع:

• نشر مشروع Laravel بسرعة.
• تجنب رفع الملفات المحلية غير الضرورية.
• العمل جيدًا مع استضافة Hostinger المشتركة.
• إعادة استخدام آلية عملي الحالية المعتمدة على WinSCP.
• التشغيل بأمر واحد.

لم أكن أبحث عن مسار CI/CD كامل؛ فهو عبء غير ضروري لبعض المشاريع الصغيرة. أردت حلًا خفيفًا وعمليًا يسهل الوثوق به.

ما الذي يفعله السكربت؟

يجهز السكربت حزمة نشر نظيفة من مشروع Laravel المحلي ويرفعها إلى Hostinger باستخدام SFTP.

ويدعم:

• قراءة إعدادات النشر من ملف .env.
• المصادقة بمفتاح SSH.
• استخدام WinSCP عند تثبيته محليًا.
• الرجوع إلى OpenSSH sftp عند غياب WinSCP.
• استبعاد الملفات والمجلدات المحلية من الرفع.
• تجاوز مجلد vendor اختياريًا.
• إعادة بناء vendor اختياريًا لتجهيز اعتماديات الإنتاج.

عمليًا، يحوّل مجموعة خطوات يدوية متكررة إلى أمر واحد قابل للتكرار.

لماذا يهم SFTP؟

يُستخدم تعبير «النشر عبر FTP» أحيانًا دون دقة، لكن هذا السكربت يستخدم SFTP عبر SSH وليس FTP العادي.

هذا الفرق مهم؛ فـ SFTP مشفر ويلائم بيئات الاستضافة الحديثة ويعد اختيارًا أنسب لأتمتة النشر.

لماذا حافظت على البساطة؟

هناك أساليب أكثر تقدمًا، منها مسارات CI/CD ومجلدات الإصدارات والتراجع وتجهيز الخوادم، ولكل منها موضعه.

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

بنيت الحل لحالة محددة:

• المشروع على استضافة Hostinger المشتركة.
• التطبيق يتلقى تحديثات منتظمة.
• يستغرق الرفع اليدوي وقتًا أطول مما ينبغي.
• آلية عمل خفيفة أنفع من حل معقد هندسيًا.

سير العمل المعتاد

أصبح مسار النشر مباشرًا:

1. إجراء التعديلات محليًا.
2. بناء ملفات الواجهة إذا احتاجها المشروع.
3. التأكد من إعدادات النشر.
4. تشغيل السكربت.
5. التحقق من التطبيق المنشور.

الأمر بسيط:

.\deploy.ps1

يختصر هذا التغيير قدرًا ملحوظًا من العمل المتكرر.

ما الذي يستبعده السكربت؟

من أهم الفوائد تجنب رفع الملفات التي ينبغي أن تبقى محلية، ومنها:

• .git
• .github
• .vscode
• node_modules
• tests
• ملفات .env المحلية.
• ملفات السجلات.
• مجلدات الذاكرة المؤقتة.
• الملفات المساعدة مثل README.md وdeploy.ps1.

يحافظ ذلك على نظافة حزمة النشر ويقلل احتمال إرسال ملفات التطوير إلى الإنتاج.

التعامل مع اعتماديات Composer

تختلف طريقة التعامل مع اعتماديات Composer بين المشاريع، لذلك أضفت مرونة لمجلد vendor.

بحسب بيئة النشر يمكنني:

• رفع مجلد vendor المحلي.
• تجاوزه بالكامل.
• إعادة بناء اعتماديات الإنتاج قبل الرفع.

يجعل ذلك السكربت مناسبًا لقيود استضافة وتفضيلات نشر مختلفة.

لماذا استحق البناء؟

لم يحل السكربت كل مشكلات النشر، ولم يكن هذا هدفه. لكنه عالج صعوبة إرسال التحديثات اليومية إلى الاستضافة المشتركة عبر:

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

أفضل الأدوات الداخلية ليست دائمًا الأكثر تعقيدًا، بل التي تزيل أكبر قدر من الاحتكاك في العمل اليومي.

إذا كنت في الموقف نفسه

إذا كنت تنشر Laravel على استضافة Hostinger المشتركة بالرفع اليدوي، فقد يكفي سكربت كهذا لتحسين العملية بوضوح.

لا تحتاج دائمًا إلى نظام نشر كبير؛ أحيانًا يكون سكربت متخصص هو المستوى المناسب من الأتمتة.

رابط المشروع

السكربت متاح في مستودع GitHub.

يوضح ملف README متغيرات البيئة الدقيقة وخطوات الإعداد المطلوبة لوجهة النشر.

أفكار ختامية

بنيت هذه الأداة لأنني سئمت قضاء وقت غير ضروري في النشر اليدوي.

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

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