النشر المستمر لـ WordPress والتحكم في الإصدار باستخدام Bitbucket

حسنًا يا رفاق. حان الوقت للتعهد.

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

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

ومع ذلك ، إذا تعطل أحد المواقع وكان هناك شخص ما لرؤيته ، فمن المؤكد أنهم سيصدرون صوتًا.

تم النشر المستمر لـ WordPress بشكل خاطئ

أدخل مواقع التدريج ، وتثبيتات WordPress المكررة (على الأقل من الناحية النظرية) حيث يمكن إجراء التغييرات ، ثم إجرائها مرة أخرى على الموقع المباشر بمجرد تأكيد عمل كل شيء. بينما أدى هذا إلى تهدئة الزائرين ، بدأ في جعل المطورين يُحدثون بعض الضجيج. فجأة ، احتجنا إلى تتبع موقعين ، والتأكد من مزامنة الشفرة يدويًا بينهما ، واختبار كل شيء مرة أخرى للتأكد من أنه يعمل على الموقع المباشر. كانت القوائم الطويلة الفوضوية لـ "تأكد من تغيير هذا على الهواء مباشرة" و "تأكد من تبديل هذا على موقع التدريج قبل نسخ الكود" محطمة للأعصاب ، على أقل تقدير. كانت النسخ الاحتياطية لهذا النظام كابوسًا أيضًا - مجموعة كبيرة من المجلدات المسماة "my-theme-staging-1" و "my-theme-live-before-menu-restyle-3" وما إلى ذلك.

كان لابد من وجود طريقة أفضل ، وكان هناك.

كان هناك Git ، والذي يوفر تحكمًا مثاليًا بالمصادر وميزات أخرى للمطورين. أدى استخدام التحكم في الإصدار لتثبيتات WordPress إلى تسريع عملية التطوير والتنظيف على الفور ، حيث لم يعد يتم قضاء ساعات في النسخ الاحتياطي في نظام لكل مطور ولكن في الواقع على الترميز. تم حفظ التغييرات ويمكنني أخيرًا إضافة رسائل ذات مغزى إلى عملي ، عوالم مختلفة من "my-theme-4-v2."

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

بينما يمكن إجراء إعدادات مماثلة لهذا البرنامج التعليمي باستخدام GitHub / GitLab والخدمات الأخرى ، فقد وضعت بيضتي في سلة Atlassian في وقت مبكر بسبب مستودعاتها الخاصة المجانية (والتي كانت مجرد عرض حديث من GitHub). عندما قدمت Bitbucket خدمات خطوط الأنابيب والنشر الخاصة بها ، فقد سمحت بنشر كود جديد تلقائيًا في مواقع التدريج أو الإنتاج (أو أي موقع آخر بينهما) دون إعادة التحميل عبر FTP أو استخدام خدمة خارجية. يمكن للمطورين الآن استخدام جميع قيم التحكم بالمصادر في تطوير WordPress الخاص بهم وإرسال هذه التغييرات على الفور إلى الوجهات المناسبة دون نقرات أو ضغطات مفاتيح إضافية ، مع ظهور حالة كل شيء عبر لوحة تحكم واحدة. وهذا يضمن بقاء كل شيء في حالة تزامن ، ويتيح لك في لمحة سريعة معرفة الرمز الذي يعمل عليه كل موقع بالضبط. بالإضافة إلى ذلك ، فإن أسعار دقائق إنشاء Bitbucket ميسورة التكلفة بشكل لا يصدق - مع 50 دقيقة مجانية شهريًا وخيار خطة "مجانية مع تجاوزات".

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

روتين اليكسا Green WordPress Depoyment

يجب تنفيذ الخطوات الموضحة هنا حسب الحاجة:

على خادم العميل

قم بإعداد مجال للموقع المباشر (على سبيل المثال ، clientsite.com) ونطاق فرعي للتقسيم المرحلي (على سبيل المثال ، staging.clientsite.com).

قم بتثبيت WordPress على كل من الموقع المباشر والمجال الفرعي التدريجي. يمكن القيام بذلك عبر cPanel / Softaculous (إذا كان لدى استضافة العميل هذا) أو عن طريق التنزيل من wordpress.org. تأكد من وجود قواعد بيانات منفصلة عن البث المباشر والتشغيل المرحلي على التوالي.

على موقع Bitbucket.com

إنشاء مستودع جديد. قم بتضمين .README لتنشيطنا.

في المستودع ، الإعدادات> خطوط الأنابيب> الإعدادات ، ثم حدد تمكين خطوط الأنابيب .

في الإعدادات> خطوط الأنابيب> متغيرات المستودع ، أدخل ما يلي:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

ارجع إلى خطوط الأنابيب> الإعدادات وانقر فوق الزر تكوين bitbucket-pipelines.yml . حدد PHP كلغة في الصفحة التالية. سترغب في استخدام شيء مثل الكود التالي. تأكد من استبدال إصدار PHP بكل ما تستخدمه على خادم العميل ، وخوادم URLs / FTP بموقع العميل الفعلي (الإنتاج والتشغيل) عناوين URL / خوادم FTP.

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

انقر فوق Commit file . سيتم الآن الالتزام بإعداد خطوط الأنابيب وتشغيلها.

إذا تم نشر كل شيء بنجاح ، فارجع وقم بتحرير ملف bitbucket-pipelines.yml (يمكنك الوصول إليه من خلال خطوط الأنابيب> الإعدادات وعرض bitbucket-pipelines.yml ). ستحتاج إلى استبدال كلا المكانين اللذين تقول git ftp init بـ git ftp push وحفظ / الالتزام. سيضمن ذلك تحميل الملفات التي تم تغييرها فقط ، مما يوفر لك دقائق الإنشاء. يجب أن يقرأ ملف bitbucket-pipelines.yml الخاص بك الآن:

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

أضف فرعًا يسمى main-dev .

على جهازك المحلي

انسخ المستودع في دليل فارغ تريد استخدامه للتثبيت المحلي. تحقق من فرع main-dev .

قم بإعداد تثبيت WP محلي في هذا الدليل. هناك العديد من الأدوات لهذا - محلي بواسطة Flywheel و MAMP و Docker وما إلى ذلك. تأكد من أن كل شيء هو نفسه (إصدار WordPress ، إصدار PHP ، Apache / Nginx ، إلخ) مثل ما يتم تشغيله على خادم العميل.

أضف ملف .gitignore يبدو شيئًا كهذا. نريد بشكل أساسي أن يتجاهل Git كل شيء باستثناء wp-content (لمنع مشكلات التثبيت بين عمليات التثبيت). قد ترغب أيضًا في إضافة القواعد الخاصة بك لتجاهل ملفات النسخ الاحتياطي الكبيرة والأيقونة التي أنشأها النظام وملفات DS_Store.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

حفظ والالتزام .gitignore .

قم بإجراء التغييرات والالتزام وفقًا لذلك.

في أي وقت تلتزم فيه بـ main-dev ، سيطلق تحميل FTP إلى موقع التدريج. في أي وقت تلتزم فيه بالإتقان ، سيطلق تحميل FTP إلى موقع الإنتاج. لاحظ أن هذا سيستخدم دقائق الإنشاء ، لذلك قد ترغب في إجراء معظم التغييرات المحلية على فرع من main-dev ، ثم دمجها في main-dev بمجرد الانتهاء من اليوم.

سيؤدي دمج main-dev في Master إلى عرض جميع تغييرات التدريج. يمكنك التحقق من حالة خطوط الأنابيب وعمليات النشر في الريبو على Bitbucket.org.

مزامنة قواعد بيانات WordPress عبر التثبيتات

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

لمزامنة قواعد البيانات عبر تثبيتات WordPress ، توجد عدة خيارات. تقليديا ، يمكنك تحديث قواعد البيانات عن طريق الاستيراد / التصدير عبر phpmyadmin . هذا أمر صعب ، لأنه لا يمكن تحديث بعض الأشياء التي تحتاج إلى تحديث ، مثل الروابط الثابتة في محتوى المنشور. باستخدام هذه الطريقة ، فإن الأداة المفضلة هي المكون الإضافي Velvet Blues Update URLs ، والذي يمكنك استخدامه بعد ذلك للبحث / استبدال أي مثيلات لعنوان URL للموقع القديم (على سبيل المثال ، https://staging.clientsite.com) إلى عنوان URL الجديد للموقع ( على سبيل المثال ، https://clientsite.com). يمكنك أيضًا استخدام هذا مع المسارات والسلاسل النسبية. تنتهي هذه الطريقة بترك مساحة كبيرة للخطأ البشري - إذا تمت كتابة سلسلة مستبدلة بشكل خاطئ ، فقد يتسبب ذلك في تعطل الموقع بالكامل وعدم القدرة على استخدام المكون الإضافي / الوصول إلى لوحة القيادة.

بينما يوفر مكون إضافي مثل All-in-One WP Migration ميزة بحث / استبدال خارج الصندوق وهو سهل الاستخدام بشكل لا يصدق ، فإنه يجلب أيضًا الملفات ، وبالتالي التراجع عن قيم سير عمل خطوط الأنابيب بالكامل. بالإضافة إلى ذلك ، نظرًا لأنه يعيد استيراد جميع تحميلات wp ، يمكن أن ينتج عنه ملفات ضخمة وأوقات تحميل (وبالتالي فهو غير مناسب لنقل التغييرات عبر التثبيتات). من الأفضل حجز مكون إضافي مثل هذا للنسخ الاحتياطية للموقع بأكمله لأغراض الأرشفة / الأمان.

يبدو أن VersionPress حلاً مثيرًا للاهتمام ، لكن لم يتم إثباته في الكثير من بيئات الإنتاج حتى الآن. في الوقت الحالي ، يبدو أن المكونات الإضافية مثل WP Sync DB أو WP Migrate DB Pro هي أفضل الحلول لإدارة قواعد البيانات. إنها تسمح بسحب / دفع قواعد البيانات عبر عمليات التثبيت مع إعطاء خيار تحديث عناوين URL والمسارات تلقائيًا. يمكنهم ترحيل جداول معينة فقط ، مثل wp_posts لمحتوى النشر فقط ، وعدم إضاعة الوقت في إعادة استيراد المستخدمين والإعدادات على مستوى الموقع. أحب دائمًا الانسحاب من البث المباشر للتأكد من عدم الكتابة فوق أي بيانات إنتاج. فيما يلي مثال على الإعداد إذا كنت تستخدم WP Sync DB (يتوفر المزيد من الإرشادات على WP Sync DB github):

1. على الموقع المباشر: قم بإعداد WP Sync DB مع تمكين إعداد "السماح بالسحب من هذا المستودع".
2. على موقع التدريج: قم بإعداد WP Sync DB مع السحب من الإعدادات المباشرة. أطلق عليها اسم "من الحي إلى المسرح".
3. في إعداد المطور المحلي لديك: قم بإعداد WP Sync DB مع السحب من الإعدادات المباشرة. أطلق عليها اسم "العيش للتطوير".

قد ترغب أيضًا في إعداد قاعدة دفع "dev-to-staging" ، والتحقق من إعداد موقع التدريج للسماح بالكتابة فوق قاعدة البيانات.

تغليف

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

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

في حين أن هناك بالتأكيد مجال للتحسين لجلب المزيد من سير عمل التحكم بالمصادر إلى إدارة قاعدة البيانات ، حتى يتم استخدام أداة مثل VersionPress بشكل أكبر في بيئات الإنتاج ، يبدو أن طريقة السحب / الدفعات الانتقائية لقاعدة البيانات عبر WP Sync DB أو WP Migrate DB Pro لتكون الطريقة الأكثر أمانًا للتعامل مع هذا الأمر. من الغريب معرفة ما يصلح لسير عمل WordPress الخاص بك ، أو إذا كنت تفضل بعد كل هذا الحصول على رمز lasso و Cowboy الخاص بك!