مرحبًا بالجميع. واجهت مشكلة أثناء تطوير discourse
عادةً ما أقوم بنسخ الملفات من Git
إجراء تعديلات
إجراء commit على Git
يقوم زميلي بـ git pull
ويحصل على جميع تعديلاتي
كيف يمكنني تنفيذ شيء مشابه في discourse؟
كيف يمكنني إجراء تعديلات بحيث يتمكن الآخرون من تثبيتها في بيئاتهم المحلية؟
إذا كنت تُطور سمة أو إضافة لـ Discourse، فيمكن أن يعيش أي منهما في مستودع Git دون أي مشكلة.
شكرًا لك على الرد. نعم، أنت محق بشأن الموضوع. ماذا عن مزامنة المكونات والإعدادات؟
يمكن لرمز الإضافة الخاص بك تحديد عمليات الترحيل و/أو محتوى البذر حسب الحاجة. كما يمكنه أيضًا التأكد من أن إعدادات الموقع تحتوي على القيمة المناسبة.
أريد استنساخ التثبيت الخاص بي بالكامل
يمكنك عمل نسخة احتياطية واستعادتها عند الحاجة.
أحب استخدام S3 للنسخ الاحتياطي، بحيث يمكن لجميع المواقع مشاركة مجموعة النسخ الاحتياطي نفسها. وعند إجراء نسخة احتياطية في بيئة الإنتاج، يمكنك استعادتها فورًا في مواقع الاختبار (Staging) للتأكد من أنها تعمل بشكل صحيح مع البيانات الحالية.
ما هو S3؟ أود استخدام هذا
استخدام التخزين الكائني للرفع (S3 وما شابهه) وإعداد رفع الملفات والصور إلى S3 هما نقطة البداية. أما بالنسبة للنسخ الاحتياطي فقط، فالأمر بسيط للغاية.
تُعد خدمات Backblaze وWasabi رخيصة. كما أن Storj.io لديها منتج استخدمته للنسخ الاحتياطي.
هذا مجرد رأي شخصي، وليس بغرض التقليل من التعليقات المفيدة هنا حول النسخ الاحتياطي، ولكن إذا نظرنا إلى الصورة الأوسع: لست متأكداً حقاً مما إذا كان «مزامنة» تثبيتات Discourse يستحق الكثير من الجهد.
ما لم تكن تنوي تقديم طلبات دمج (PRs) إلى نواة Discourse، فإن تطوير الإضافات أو مكونات السمات (TCs) هو الخيار الأمثل، حيث يوفر لك الحل الأكثر متانة وكفاءة للتخصيص.
النقطة الأساسية في تطوير الإضافات ومكونات السمات هي أنها سيتم نشرها على عدة نسخ من Discourse قد لا يكون لديك أي سيطرة عليها في النهاية.
لذلك، فإن وجود نسخة محلية فريدة قليلاً من Discourse لأغراض التطوير أمر مقبول تماماً (ضمن حدود معقولة).
يجب أن تتضمن سير العمل الرئيسي الحفاظ على تحديث الإضافة أو مكون السمة في مستودع مشترك، وغالباً ما يكون ذلك على Github.
أوافق تمامًا. لدي بعض العملاء لديهم تخصيصات لا يمكن التحقق منها (أو يسهل التحقق منها) إلا باستخدام بياناتهم الفعلية، لذا فهم يفضلون حقًا رؤية الموقع مع البيانات الحالية.
نعم، هذا منطقي. يعتمد الأمر على ما تحاول إنجازه وعلى قاعدة العملاء (هدف واحد أم عملاء متعددين؟) وعلى مقدار التحكم الذي تتوقعه.
شكرًا لكم جميعًا على نصائحكم. على الأرجح، سأقوم بدمج التغييرات (PR) في نواة Discourse. لذلك، أحتاج إلى القدرة على رفع التجميع إلى Git، ومن Git إلى الخادم.
إذا كنت تقوم بإنشاء طلب دمج (PR) للنواة الأساسية في Discourse، فإن التكوين الدقيق للتثبيت المحلي ليس أمرًا حاسمًا (فقط تأكد من أنك تستخدم أحدث إصدار)، لأن مساهمة الكود عملية خاضعة لرقابة شديدة على أي حال، خاصة مع حالات الاختبار، لذا فإن وجود اختلاف بسيط في الإعدادات أو المحتوى من غير المرجح أن يشكل مشكلة.
عادةً، إذا كنت تعمل على مساهمات مشتركة، هل تقوم بإنشاء نسخة (fork) إلى مستودع منظمتك وتعمل عليه قبل تقديم طلب الدمج (PR)؟
لا، أنا لا أعمل على مساهمات مشتركة. أعمل للاستخدام الشخصي
لم أقصد ذلك بهذه الصيغة
كيف يمكنني تثبيت Discourse من نسخة مُفرعة (fork) على Git؟
سأقوم بإجراء تعديلات على نواة Discourse وإضافتها إلى مستودعي على Git
لذلك أنا مرتبك، لماذا تحتاج إلى مزامنة تثبيتاتك؟
ما عليك سوى استخدام git clone لاستنساخ fork الخاص بك.
عادةً لا يُستخدم Docker لأغراض التطوير، ولكن إذا كنت تستخدمه، فيمكنك الدخول إلى الحاوية الخاصة بك والتحقق من fork الخاص بك.
على سبيل المثال.
الآن قمت بإعداد Discourse
ثم، عندما يكون كل شيء جاهزًا، أقوم بتحديث بنائي.
بعد ذلك، أستمر في التطوير مرة أخرى. أقوم بتغيير بعض الإعدادات في لوحة التحكم. قد يكون هناك الكثير منها.
عندما أرغب في تحديث بنائي، سأحتاج أيضًا إلى تحديث الإعدادات
في هذه الحالة، سأضطر إلى تعيين الإعدادات يدويًا
الإعدادات دائمة، وأنت تعمل بمفردك، فلماذا الحاجة للتركيز على النسخ الاحتياطي/المزامنة؟
(كما أن عنوان الموضوع محير إذن، لماذا “في فريق”؟)
عند استنساخ المشروع أو استرداده، لا يتم مسح قاعدة البيانات (حيث تُحفظ الإعدادات).
أنت تتحكم في توقيت تشغيل عمليات الترحيل (إن وجدت). وإلا، فيجب أن تكون قاعدة البيانات مستقرة.
