ممارسات التنمية الموصى بها للعمل مع Siebel CRM؟

Question

قد أعمل مع Siebel CRM قريبًا ، وأنا أبحث عن نصيحة بشأن استخدام ممارسات التطوير الحديثة وأفضل الممارسات للمؤسسات.

على وجه التحديد ، أود المشورة في المجالات التالية:

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

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

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

Answer 1

كيف يجب علينا إعداد التحكم في الإصدار (على وجه التحديد مع التخريب)؟

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

ما نوع الهيكل الذي يجب أن يكون لدى مستودعنا؟ كيف يجب أن نتعامل مع الفروع والعلامات؟

لم يتم تصميم أو إدارة رمز تطوير Siebel في SVN ، لذا يعد هذا أمرًا عديمة الفائدة. فقط لاحظ التاريخ الذي قمت بإنشائه SRF وقمت بتصدير الريبو الخاص بك وتطابق مع علامة أو فرع في SVN.

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

استخدم أدوات Siebel للقيام بذلك. يحتوي على أداة "التحقق" المضمنة للأخطاء الواضحة (يجب أن تستخدم جميع devs هذا قبل تسجيل الوصول) وأداة Diff (ستحتاج إلى التحقق من إصدار أقدم من نفس الكائن - والتي يمكنك سحبها من SVN إن أردت). عادةً ما أقوم بأتمتة أداة الفحص مرة واحدة يوميًا ومراجعة سجلات الإخراج ، وأتمتة البناء من Siebel Server 5 مرات في اليوم وأبحث عن أخطاء أثناء الترجمة. قد تكون Diffs عبر SVN وأداة Diff القياسية ممكنة ، ولكن يتم تخزين كائنات Siebel كملفات تشبه XML في SVN وبالتالي يصعب قراءتها أحيانًا.

أي نوع من إدارة التغيير تعمل بشكل جيد مع Siebel؟ كيف نتحقق من أن الأشياء المدرجة فقط في سجل التغيير لدينا تتغير بالفعل عندما نقوم بنشر جديد؟

?

كيف يمكننا أتمتة اختبار تطبيقنا؟ هل اختبار الوحدة ممكن حتى مع سيبل؟ رأيت سؤالًا آخر يقترح QTP لاختبار الويب ، ولكن هل هناك خيارات أخرى تعمل؟

QTP هي الطريقة القياسية للذهاب - تحقق من موقع Oracle على الويب للبائعين الآخرين الذين قد يوصون به. يمكنك أيضا تجربة سيكولي.

هل هناك أشياء أخرى يمكننا القيام بها لتنفيذ ممارسات التكامل المستمر من خلال جهود تطوير Siebel لدينا؟

ليس صحيحا.

ما هي التوصيات التي لديك لتسمية الاتفاقيات وغيرها من الأشياء التي من شأنها أن تندرج تقليديا تحت إرشادات "أسلوب الترميز"؟

الخروج عن القسم المناسب من Siebel Whishelf للحصول على إرشادات التسمية الحالية واستخدمها دائمًا.

كيف يجب أن نفصل أدوار التنمية عن أدوار مسؤول Siebel؟

لست متأكدا مما تقصده.

كيف ينبغي أن تبدو دورة البناء/الاختبار/النشر؟

بناء SRF جديد وتصدير ريبو جديد من ديف مرة واحدة في الليلة. بمجرد فحص جميع أعمال DEV واختبار الوحدة ، خذ SRF و REPO التالي ودفع إلى بيئة الاختبار. في هذه المرحلة من تطوير البرمجيات العادية ، كنت تتفوق على SVN الخاص بك وتستمر في التطور على الجذع ولكن Siebel مختلف لأنه لا يمكنك البناء من SVN ولا يمكنك بسهولة استعادة الكثير من الملفات من SVN إلى بيئة البناء الخاصة بك ، لذلك أنت " من الأفضل إجراء إصلاحات ساخنة للاختبار إما في Dev (وتوقف تطوير Dev Mainline إلى أن يتم ذلك) أو في بيئة الاختبار ، والقيام بتبريد قبيح لبيئة التنمية (هذا ما يفعله معظم الناس في الواقع). قم بإنشاء SRF جديد وتصدير ريبو جديد من الاختبار مرة واحدة في الليلة وبمجرد أن يكون ذلك جيدًا ، قم بإلقاء نسخة لإصدار الإنتاج الخاص بك. حاول التمسك بدورات ما لا تزيد عن 4 أسابيع (أسبوع واحد للاطلاع على/النماذج الأولية. أسبوع واحد لـ DEV ، أسبوع واحد للاختبار ، أسبوع واحد لإصلاحات الأخطاء ونشرها) - أي وقت أطول من ذلك وسيصبح النفقات العامة للتخطيط أيضًا رائعة.

تلميحات لحياة أسهل: تجنب eScript إلا في خدمات الأعمال (وإلا فإنها تصبح غير قابلة للإدارة) ؛ استخدم جميع الأدوات المدمجة في Siebel بدلاً من المتداول الخاص بك ؛ حاول تجنب أي وظيفة لفة (يبدو دائمًا فكرة جيدة ولكنها تدمر الأداء دائمًا) ؛ الحفاظ على عدد الشاشات ووجهات النظر إلى الحد الأدنى المطلق ؛ لا تبني وجهات النظر عندما يجب أن تبني تقارير بدلاً من ذلك ؛ تأكد دائمًا من أن طاولات EIM تتطابق مع امتدادات المخطط التي تصنعها - حتى لو لم تستخدم EIM الآن ؛ حاول إنشاء كائنات تكامل لتتناسب مع مخططك المنطقي - فهي دائمًا مفيدة (لخدمات الويب ، ونشر XML) وجحيم وظيفة للبناء بعد الحقيقة ؛ تفضل سياسات سير العمل على أحداث وقت التشغيل ؛ لا تضيف مواصفات جديدة أو مواصفات بحث بدون فهارس - من أي وقت مضى ؛ لا تصنع روابط مرجعية إلى جدول LOV ؛ دائما التصحيح إذا لم يقل البائع أنه يمكنك فعل شيء ما ، فلا تفعل ذلك أبدًا.

Answer 2

لقد أنشأنا مجموعة أدوات تكامل مستمرة كاملة لأنظمة Siebel الخاصة بنا التي تتكون من Subversion و Hudson و Jira و Siebel Adm وبعض الأشياء المكتوبة الذاتي التي تدمج كل شيء.

هذه الطائرات كثيرًا ، على الرغم من أن "كود المصدر" Siebel ليس مناسبًا لنهج CI القياسية ، على سبيل المثال ، بعض المشروع القائم على Java.

ونعم ، من الممكن وضع ملفاتك - بما في ذلك SIF - في مستودع التخريب الخاص بك واستخدام هذا كـ مصدر لنشراتك.

أخطط للتدوين حول هذا http://siebel-ci.blogspot.de/ - ابقوا متابعين.

Answer 3

SVN/CVS ليست مناسبة لـ Siebel ، وهي بعض الأسباب
أ) كائنات Siebel هي كائنات DB و SVN/CVS وما إلى ذلك تخزين SIF المكافئ للتغييرات.
من المستحيل الاستعلام عن هذه التغييرات باستثناء بعض الاستفسارات الأساسية.
ب) التكامل بين أدوات Siebel و SVN هو تكامل مقترن بشكل فضفاض.
يجب أن يكون التكامل المثالي مع مستودع Siebel وأدوات Invidual.

ألقِ نظرة على كائن الأداة الخاص بنا ، وهو يعالج العديد من القوانين القصيرة للتحكم في الإصدار القائم على الملفات.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
لقد كانت HOBER HIVE من الألف إلى الياء خصيصًا للتحكم في إصدار Siebel ، بعض ميزاتها هي:
1) مستودع قائم على الكائن يشبه مستودع Siebel الذي يخزن جميع سجل الإصدار.
هذا يجعل من السهل للغاية الاستعلام عن التغييرات وإجراء مراجعات رمز بناءً على التغييرات
2) واجهة المستخدم الرسومية المستندة إلى المتصفح تشبه أدوات Siebel للاستعلام عن تاريخ الإصدار (لا تمشيط ملفات SIF للتغييرات).
3) تكامل سلس - يتكامل مباشرة مع مستودع Siebel.
لا تركيب فوضوي للمطور Invidual. 4) الإبلاغ القوي (الوقت الحقيقي والدفعة) لتحديد التغييرات بسهولة خلال أي فترة زمنية.
5) Oracle EXA Ready معتمد.