إدارة إصدارات العملاء المخصصة

Question

كبديل ل هذا السؤال ما هي أفضل طريقة لإدارة الإصدارات المخصصة من البرامج لعملاء معين؟

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

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

لذا بافتراض أن السؤال المرتبط ليس هو الطريق للذهاب، ما هي أفضل طريقة لإدارة هذه الإصدارات؟

Answer 1

"هذا أصبح الألم للإدارة، وسوف يزداد سوءا فقط لأن المزيد والمزيد من العملاء يبدأون باستخدام برنامجنا."

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

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

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

من الصعب أن نقول المزيد من التفاصيل دون معرفة منصةك، لكنك أبقت بلطف هذا السؤال الأذرع.

Answer 2

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

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

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

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

Answer 3

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

/project
   /trunk 
   /branches
      /release-v1
   /customer-branches
      /release-v1-google
      /release-v1-microsoft
 ....

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

Answer 4

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

يبدو أنه إذا كنت تقوم دائما بتسليم إصدارات مخصصة (ISH) من تطبيقك لكل عميل، فسيكون الأمر يستحق الوقت اللازم لتوسيع التطبيق بهذه الطريقة.

Answer 5

قمت بإعداد ملف رأس يسمى العلامة التجارية التي تحتوي على مجموعة من #IFDEFS مثل المثال التالي لتغيير أي بت تحتاج إلى تغيير. في Visual Studio، من السهل إعداد إنشاءات متعددة مع رمز العميل المناسب المحدد.

#if defined BRAND_CLIENT1
#  define COMPANY_NAME  "Client 1"
#  define PRODUCT_NAME  "The Client 1 Widget App"
#  define LOGO_FILE     "res/logoClient1.ico"

#elif defined BRAND_CLIENT2
#  define COMPANY_NAME  "Client 2"
#  define PRODUCT_NAME  "The Client 2 Super Widget App"
#  define ENABLE_EXTRA_MENU
#  define LOGO_FILE     "res/logoClient2.ico"

#endif

هذا هو كل شيء على افتراض C ++ بالطبع.