تطوير أدوات DEV قبل الإصدار

Question

نحن نقوم بتطوير موقع ويب. تحتوي إحدى أدوات التطوير التي نستخدمها على إصدار ألفا متاح لإصداره التالي والذي يتضمن عددًا من الميزات التي نحن هل حقا يريدون استخدام (أي أنهم سيوفروننا من الاضطرار إلى تنفيذ آلاف الخطوط للقيام بنفس الشيء تمامًا على أي حال).

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

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

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

ما رأيك؟ هل يستحق المخاطرة؟ هل لديك أي تجارب (جيدة أو سيئة) من المواقف المماثلة؟

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

EDIT2] شكرًا لمارجان على الرد المفيد للغاية. كنت آمل في الحصول على مزيد من الردود ، لذلك أنا أضع مكافأة على هذا.

Answer 1

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

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

باختصار: ليس فقط تقييم المنتج ، وتقييم المنتجين.

يعتبر.

Answer 2

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

بعد قولي هذا ، هناك طريقة واحدة أراها يمكنك أن تحاول الحصول على كعكتك وتناولها أيضًا.

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

Answer 3

هذا يعتمد.

بالنسبة لبيئات OpenSource ، فإنه يعتمد على جودة الإصدار أكثر من الملصق (Alpha/Beta/Estable). لقد عملت مع كود ألفا الذي يتسم الصخور مقارنة برمز الإنتاج المزعوم من منتج آخر.

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

لذلك في وضعك ، سأقوم بتقييم جودة إصدار Alpha ، ثم قرر ما إذا كان يمكن أن يدخل ذلك في الإنتاج.

بالطبع لا ينطبق كل ما سبق على أي شيء حتى حرجة السلامة عن بعد.

Answer 4

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

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

هل تستخدم التكامل المستمر ، أليس كذلك؟