أعلم أن الافتراضي/التوصية لاستخدامها في إصدارات Discourse هو tests-passed، لكن فريقنا حتى الآن كان يحدد إصدار Discourse في ملف app.yml، مثل version: 2.7.0.beta1. نفعل ذلك لأننا نرغب في التحكم بشكل صريح في الإصدار الموجود على بيئة الإنتاج.
ومع ذلك، لاحظنا من هذا الموضوع وجود خطأ يمنعنا من القيام بذلك كما فعلنا دائمًا. هذه مشكلة بسبب طريقة قيامنا بالتوسع التلقائي (autoscaling) في منتدانا. على سبيل المثال، لنفترض أن الإصدار 2.7.0.beta1 هو حاليًا على بيئة الإنتاج. ثم نواجه زيادة مفاجئة في حركة المرور على المنتدى، ويصبح علينا تشغيل مثيل آخر للتوسع لمواجهة ذلك. إذا كان لدينا tests-passed في ملف app.yml وكان هناك إصدار جديد من Discourse منذ آخر تحديث للإنتاج، فسيتم تشغيل مثيل جديد (2.7.0.beta2) يتعارض مع المثيل الحالي. وبالتالي سيكون لدينا نسختان مختلفتان في البيئة، ربما مع تغييرات في قاعدة البيانات ومشاكل أخرى في التوافق، مما يؤدي إلى عدم عمل الإنتاج بشكل صحيح.
هناك أيضًا أسباب أخرى قد لا نرغب فيها في التحديث التلقائي بهذه الطريقة، مثل مشاكل توافق الإضافات، والرغبة العامة في اختبار الأشياء بالكامل على بيئة الاختبار (staging) قبل نشرها على الإنتاج.
كملاحظة، لقد حاولنا جعل هذا الحل يعمل حتى نتمكن من تحديد إصدار Discourse، لكنه يفشل حاليًا مع الإصدار 2.7.0.beta3. نحصل على خطأ bundler مشابه للخطأ الظاهر هنا، وأنا أعلم أن حل ذلك الشخص كان العودة إلى استخدام tests-passed.
إذن سؤالي هو - كيف يمكننا التحكم بفعالية في إصدارات Discourse لدينا، بالنظر إلى إعداد التوسع التلقائي لدينا والحاجة العامة لتحديد إصدار Discourse الذي يتم نشره على الإنتاج؟ أحب أن أسمع ما فعله الآخرون في هذه الحالة.