قطط الرعي - الدروس المستفادة أثناء التطوير لبيئة WordPress

عندما تم إصدار Elementor 3.0 منذ أكثر من عام ، في عام 2020 ، رأينا أنه خطوة مهمة نحو محرر أسرع وأكثر قوة بشكل ملحوظ. في حين أن هذا صحيح ، كان لهذا الإصدار أيضًا عواقب مهمة وغير متوقعة - فقد تسبب في توقف عدد كبير من المواقع عن العمل ، وبصراحة تامة ، أضر بسمعتنا. بعد هذا الإصدار ، احتجنا إلى الخروج بسلسلة من الإصلاحات من أجل تشغيل هذه المواقع مرة أخرى. علاوة على ذلك ، أظهرت لنا التجربة بأكملها أننا بحاجة إلى إصلاح إجراء الاختبار والتحرير بالكامل. على الرغم من كونها مؤلمة ، إلا أن هذه العملية تؤتي ثمارها اليوم كما يتجلى في الانخفاض الاستثنائي في المشكلات ، خاصة القضايا الحرجة ، بين إصدار إصداراتنا v3.0 و v3.4:

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

Elementor وتحدي WordPress

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

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

أصبح التعامل مع هذه المشكلات أكثر صعوبة بسبب التحدي العام الذي تشكله طبيعة بيئة WordPress.

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

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

بالإضافة إلى ذلك ، فإن بساطة عملية الإصدار ونقص أدوات النشر القوية تعني أن مطوري WordPress غير قادرين على الاستفادة من مفاهيم الإصدار الحديثة مثل CI / CD و Canary Deployment و Feature Flags.

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

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

تطوير ميزات جديدة دون كسر القديم

تركتنا جميع العوامل المذكورة أعلاه مع معضلة كيف يمكننا الاستمرار في التطوير والتحسين دون التأثير سلبًا على عمل أولئك الذين كانوا يعتمدون بالفعل على Elementor؟

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

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

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

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

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

• التحقق من توافق الإصدار مع عدد لا يحصى من إعدادات الموقع
• ضمان التوافق مع الإصدارات السابقة مع أكثر من خمسة ملايين موقع قائم
• التحقق من توافق مئات من ملحقات Elementor التابعة لجهات خارجية

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

حلقة التغذية الراجعة

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

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

على سبيل المثال ، قمنا بفحص النظام الذي طورته Google لمتصفح Chrome. في أي وقت ، يمكن للمطورين الوصول إلى ثلاثة إصدارات من المتصفح - إصدار تجريبي وإصدار مطور وإصدار ليلي. هذا يعني أن المطورين يلقون نظرة مبكرة على ميزات Chrome الجديدة ويمكنهم البدء في تقديم التعليقات إلى Google قبل وقت طويل من طرح الإصدار رسميًا.

من خلال تطبيق هذه الدروس على المكون الإضافي الخاص بنا ، بدأ Elementor في إصدار إصدار المطور الخاص به - Elementor Beta (إصدار المطور) ، المتاح من مستودع WordPress ويستهدف المطورين المهتمين بمراجعة ميزاتنا الجديدة "خارج المطابع" إذا جاز التعبير.

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

وتجدر الإشارة إلى أن إصدارات إصدار المطور تعمل بالتوازي مع العادي - alpha و beta و RC والإنتاج - وهي العملية المستخدمة لتطوير إصدارات Elementor. عندما نطور ميزة جديدة ، بمجرد استقرارها بدرجة كافية لاستخدامها ، ولكن بينما لا تزال في مرحلة ألفا ، فإننا نضيفها إلى إصدار المطور. بهذه الطريقة ، يمكن لمطورينا تزويدنا بتعليقات ، حتى قبل أن تصل الميزة إلى مرحلة تجريبية. هذا يعني أيضًا أن إصدار المطور يتضمن ميزات لم تصل إلى المرحلة التجريبية.

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

منذ طرحه ، أثبت إصدار المطورين نجاحًا كبيرًا ، حيث حصد أكثر من 40 ألف عملية تثبيت في أقل من عام.

تقديم الميزات "التجريبية"

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

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

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

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

علامات التوافق

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

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

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

نحو مستقبل أفضل

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

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