عمليات النشر الحديثة لمواقع WordPress الخاصة بك

إذا كنت مثلي ، فإن تجربتك الأولى في دفع الملفات إلى خادم ويب كانت إما من خلال مدير ملفات على شبكة الإنترنت مثل cPanel أو عميل بروتوكول نقل الملفات (FTP) مثل Transmit أو Filezilla. اتصل بالخادم ، واسحب ملفك (ملفاتك) ، وانتظر حتى يكتمل النقل.

قراءة سهلة؟

ومع ذلك ، بمجرد أن بدأت العمل مع أي شيء أكثر تعقيدًا من ملفات HTML الثابتة ، أصبح نشر الكود الخاص بي أكثر تعقيدًا بكثير: ماذا يحدث إذا فاتني ملف مطلوب من قبل الآخرين ، أو فاصلة منقوطة في تضمين عام وشاشات بيضاء الموقع بأكمله؟ ماذا لو ضاعت خطوة حاسمة أثناء العملية؟

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

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

تتبع التغييرات مع التحكم في الإصدار

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

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

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

تحديد ما يجب تتبعه

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

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

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

عندما يتعلق الأمر بالتبعية (المكتبات ، إضافات WordPress ، إلخ) ، استفد من أدوات مثل Composer و WPackagist بدلاً من تجميع التعليمات البرمجية التي لست مسؤولاً عنها في المستودع الخاص بك.

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

هيكلة المستودع الخاص بك

عند إعداد مستودع Git لموقع WordPress أو WooCommerce ، من الأفضل عمومًا التعامل مع wp-content / باعتباره جذر المستودع ، نظرًا لأنك عمومًا لن تلمس الملفات الموجودة أعلى هذا الدليل.

يجب بعد ذلك تحميل المكونات الإضافية والسمات التي يستخدمها موقعك ولكنك لا تحتفظ بالشفرة الخاصة بها عبر Composer ، لأنها تبعيات خارجية. وبالمثل ، يجب استبعاد ملفات CSS و JavaScript التي تمت معالجتها عبر ملف .gitignore ، حيث سيتم إنشاء هذه القطع الأثرية لنا كجزء من عملية الإصدار لدينا.

لدينا قالب مستودع مجاني متاح على GitHub لتبدأ.

مقدمة إلى CI / CD

عندما يتعلق الأمر بنشر البرامج ، هناك مصطلحان مهمان يجب فهمهما: التكامل المستمر (CI) والتسليم المستمر (CD).

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

1. إنشاء الإصدار: تثبيت التبعيات (Composer و npm وما إلى ذلك) ، ثم إنشاء الأدوات (Webpack و Grunt و Sass وما إلى ذلك)
2. اختبار البنية: قم بتشغيل اختبارات الوحدة ، والتحقق من معايير الترميز ، وإجراء تحليل الكود الثابت ، وما إلى ذلك.
3. انشر الإصدار في بيئة واحدة أو أكثر

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

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

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

• فحوصات معايير الترميز (PHP_CodeSniffer، PHP Coding Standards Fixer)
• تحليل الكود الثابت (PHPStan ، Psalm)

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

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

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

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

نشر موقع WordPress أو WooCommerce باستخدام CI / CD

الآن بعد أن أصبح لدينا فهم للمصطلحات الأساسية ، دعنا نلقي نظرة على نشر موقع WordPress أو WooCommerce نموذجي:

في هذا التمرين ، سنستخدم أداة Branch ، وهي أداة CI / CD مصممة لتلبية احتياجات مطوري WordPress من نفس الأشخاص الذين يقفون وراء WP Pusher. والأفضل من ذلك كله ، أن الفرع لديه دعم مدمج للنشر في Nexcess!

للبدء ، قم بالتسجيل في الفرع عن طريق ربط حسابك على GitHub أو GitLab أو Bitbucket ، ثم إنشاء موقعك الأول.

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

بمجرد تحديد الخطوات اللازمة لبناء موقعنا ، يمكننا الانتقال إلى المرحلة التالية من خط الأنابيب لدينا: الاختبار.

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

الآن بعد أن قمنا بتثبيت تبعياتنا ، وقمنا ببناء كل شيء ، واجتازنا اختباراتنا ، فقد حان الوقت لبدء إنتاج الكود الخاص بنا!

يحتوي الفرع على وصفات للنشر إلى Nexcess (بالإضافة إلى مزودي الاستضافة الرئيسيين الآخرين) ، وربط النظامين الأساسيين غير مؤلم:

1. حدد موقعك في لوحة معلومات الفرع ، وانقر فوق "الإعدادات" ، ثم احصل على مفتاح SSH العام لموقع الفرع الخاص بك
2. أضف هذا المفتاح العام إلى قائمة المفاتيح داخل بوابة Nexcess

بمجرد أن يتمكن الفرع من التواصل مع موقع Nexcess الخاص بك ، يمكننا تحديد وصفة نشر "Nexcess" وملء بعض التفاصيل:

1. اسم المضيف واسم المستخدم للموقع (متاحان عبر بوابة Nexcess على شاشة "الوصول" بموقعك)
2. جذر الويب الذي ننشره. إذا كان المقصود من git repo أن يكون بمثابة دليل wp-content / ، فيجب أن تكون هذه القيمة "public_html / wp-content".
3. الملفات التي نرغب في نشرها (تكون القيمة الافتراضية "*" كافية بشكل عام)
4. فرع git الذي سيتم نشره في هذه البيئة

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

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

في هذه المرحلة ، يجب تكوين الفرع لبناء ونشر مستودع git الخاص بك إلى Nexcess! يمكنك تشغيل أول عملية نشر إما عن طريق النقر فوق الزر "تشغيل النشر" في صفحة "خطوط الأنابيب" الخاصة بموقعك أو عن طريق الدفع إلى مستودع Git الخاص بك.

تخصيص عملية الإصدار الخاصة بك

إحدى الميزات الرائعة حقًا لـ Branch هي القدرة على تكوين خطوات إضافية بعد النشر الناجح ، مثل المسح التلقائي لذاكرة التخزين المؤقت للكائن في موقعك بعد النشر. يمكن تحقيق ذلك باستخدام وصفة WP-CLI ضمن "أخرى".

سيكون المضيف واسم المستخدم بشكل عام نفس الشيء الذي استخدمناه في خطوة النشر ، ويمكنك ربط أكبر عدد ممكن من الأوامر حسب الضرورة.

استنتاج

إذا كنت لا تزال تكافح مع تصرفات رعاة البقر الغريبة و / أو الإصدارات المليئة بالقلق ، فقم بإلقاء نظرة على الفرع واجعل عمليات النشر أمرًا سهلاً!