وفقاً لـ هذا الدليل. هنا أقوم بتطوير Discourse، والقوالب، والإضافات.
كما قمت بتثبيت Discourse آخر على جهاز افتراضي باستخدام Docker وفقاً لـ هذا الدليل
هذه التثبيتات تعمل بشكل رائع.
لا أفهم ما هو Docker ولماذا تختلف الملفات على الجهاز الافتراضي عن الملفات على جهاز الكمبيوتر المحلي.
ماذا سيحدث إذا قمت بإيقاف Docker على الجهاز الافتراضي باستخدام الأمر d/shutdown_dev؟
وجود Docker أو عدمه أمر غير ذي أهمية تقريبًا في تطوير مكونات الإضافات والقوالب. هذا شأن منفصل. أنا لا أشغل مثيل Docker في بيئة التطوير.
عند تطوير إضافات لـ Discourse، لا ينبغي أن تقلق بشأن النسخة الدقيقة أو إعدادات مثيل التطوير مقارنة بالبيئة الإنتاجية، لأنك عادةً لا تملك سيطرة على معظم المثيلات التي سيُستخدم فيها الإضافة في أي حال إذا كان مفتوح المصدر. الأهم هو اتباع الممارسات الجيدة لجعل الإضافة أكثر متانة تجاه التغييرات في نواة Discourse. حتى لو كنت تطور فقط لمثيل Discourse الخاص بك، فلا تزال لا تملك سيطرة على التغييرات في النواة، لذا فإن نفس المنهجية تنطبق.
الاختلافات الطفيفة في الإصدارات لا ينبغي أن تتسبب عادةً في فشل الإضافة أو مكون القالب. قد يحدث ذلك لكنه ليس متسقًا. إضافاتي ومكونات القوالب (TCs) يمكن أن تمر شهور دون الحاجة إلى تعديلات، لذا أعمل على التزامات النواة التي تفصلها شهور.
عادةً ما أقوم بتحديث مثيل التطوير إلى أحدث إصدار من الفرع master عند العمل على تغييرات الإضافة (إصلاحات أو تحسينات) حتى أستطيع معالجة أي تغييرات كاسرة. ويتم ذلك ببساطة عبر أمر git pull، ثم bundle install، ثم db:migrate.
يجب تحديث مثيلات الإنتاج فقط عبر الواجهة الأمامية أو عبر أمر إعادة البناء من سطر الأوامر.
نصيحتي هي أن تنشر الإضافة للعامة وتجذب المستخدمين، وتتعلّم العقبات من خلال التجربة. لا تؤجل الأمر كثيرًا: ابدأ! ولا تقلق بشأن ارتكاب الأخطاء لأنها تساعدك على التعلم.
يجب طرح مثل هذه الأسئلة في موضوع مطوري Docker. بالنسبة للوقت الحالي، لا أنصح بتغيير السكريبتات الافتراضية المستخدمة لإدارة بيئة التطوير باستخدام Docker إلا إذا كان لديك سبب وجيه، فمن المرجح أنها موجودة لمساعدتك.
