تدريب إصدار Salesforce: نهج عملي لإدارة الإصدار

إدارة الإصدار ، كما يوحي الاسم ، هي عملية الإدارة والتخطيط والجدولة والتحكم في بناء البرنامج عبر مراحل وبيئات مختلفة ؛ بما في ذلك اختبار ونشر إصدارات البرامج (Humble & Farley، 2011).

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

ولكن ما هو قطار الاطلاق؟

قطار التحرير هو أسلوب تقديم ميزة تزايدي ويمكن التنبؤ به. يتطلب من المطور إعداد عملية رسمية لأخذ أي تغييرات يتم إجراؤها في بيئة التطوير ونشرها في الإنتاج.

يمكن تقسيم قطار التحرير على نطاق واسع إلى ثلاثة أجزاء:

• إدارة البيانات الوصفية
• بناء التكامل المستمر
• إدارة Sandbox

إدارة البيانات الوصفية

البيانات الوصفية هي البيانات التي توفر معلومات حول البيانات الأخرى. توفر Salesforce نموذج بيانات وصفية غنيًا وقويًا عبر Metadata API . تصف البيانات الوصفية للتطبيق وتتضمن مجموعة من الأساليب التي توفر وصولاً برمجيًا إلى التعليمات البرمجية المصدر وتكوين مؤسستك.

تعد Metadata API أفضل طريقة لإدارة التخصيصات في Salesforce. وهو يدعم طرق create read update delete . يمكنك استخدام مجموعات التغيير ، و Force.com IDE ، وأداة Ant Migration Tool لترحيل البيانات الوصفية من مؤسسة إلى أخرى ، نظرًا لأنها توفر جميعها عمليات ترحيل عبر واجهة برمجة التطبيقات.

لكل أداة مزاياها الخاصة ، وهناك العديد من الأشياء التي يجب مراعاتها عند اختيار واحدة:

الجدول 1: مقارنة الأدوات لترحيل البيانات الوصفية

تعد Metadata API رائعة في خدمة غرضها عند تطوير وترحيل التغييرات على منصة Force.com. ولكن هناك مشكلة بسيطة - ليست كل البيانات الوصفية لـ Salesforce مدعومة بواسطة Metadata API. توفر الوثائق الرسمية قائمة بالمكونات غير المدعومة.

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

قد تكون هذه قائمة عامة جيدة بالأعمدة التي يمكن للمرء استخدامها لتتبع هذه التغييرات في جدول البيانات:

• اسم المكون
• نوع المكون
• تغير المالك
• وصف الوظيفة
• تخطيط القدرة
• الاعتماد على المكونات الأخرى
• اسم المراجع / المراجعة
• URL
• اسم المؤسسة / المعرف
• تعليقات أخرى

التحكم في الإصدار والتكامل المستمر

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

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

يوضح مخطط التدفق التالي هيكلًا عمليًا للتحكم في الإصدار و CI. سنحاول أن نقدم لك وصفًا سريعًا لما يمثله الرسم التخطيطي.

1. سيتحقق المطور من تغييره في نظام التحكم في الإصدار.
2. سينشر خادم CI / Jenkins أحدث إصدار في وضع الحماية CI وتشغيل فئات الاختبار.
3. إذا كان النشر في الخطوة 2 ناجحًا ، فسيتم دمج التغييرات في فرع ضمان الجودة.
4. ستقوم CI بعد ذلك بنشر آخر التزام من فرع ضمان الجودة إلى صندوق حماية ضمان الجودة.
5. إذا رفضت ضمان الجودة التغييرات بسبب فشل الاختبار ، فيجب إجراء الخطوات من 1 إلى 3 مرة أخرى حتى مسح QA التغييرات.
6. بعد اجتياز التغييرات للاختبار في ضمان الجودة ، يتم دمج التغييرات في الفرع الرئيسي.
7. يتم نشر أحدث التغييرات من الفرع الرئيسي في وضع الحماية الرئيسي.

يمكن للمرء أن يختار إضافة المزيد من الفروع حسب احتياجات المنظمة. لكن الهيكل أعلاه يعمل بشكل جيد لهياكل تطوير المستوى المتوسط ​​إلى مستوى المؤسسة.

إدارة Sandbox

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

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

يوجد أدناه جدول بالحدود التي فرضتها Salesforce على صناديق الحماية المختلفة.

الجدول 2: مقارنة الحد

يمكننا أن نرى أن السعر ليس هو الفرق الوحيد بين صناديق الحماية.

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

يعمل الجدول أدناه كقاعدة عامة لاختيار صناديق الحماية:

الجدول 3: حالات الاستخدام لاختيار Sandbox

يوجد أدناه الهيكل التنظيمي النموذجي المعتمد للمشاريع المتوسطة الحجم. بالنسبة للعملاء على مستوى المؤسسة ، يصبح الهيكل التنظيمي أكثر تعقيدًا ولكنه يتبع النموذج أدناه على نطاق واسع.

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

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

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

تساعدنا هذه العملية في التأكد من أن التغييرات تمر بجولات متعددة من الاختبار وأزواج من العيون. يأتي مع جانب سلبي كبير يتطلب الكثير من الوقت لتطوير واختبار ونشر التغييرات.

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

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

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

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

ما يجب مراعاته عند النشر

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

تعد إدارة Sandbox أمرًا بالغ الأهمية للمشاريع الكبيرة أو المعقدة. لكن Sandboxes مكلفة في نظام Salesforce ، سواء من حيث الموارد المالية أو الوقت. تعد صياغة إستراتيجية لإدارة وضع الحماية دائمًا أمرًا بالغ الأهمية لعملية إدارة الإصدار.

سنترك لك بعض النقاط الإضافية التي من الجيد وضعها في الاعتبار أثناء النشر التالي:

1. يمكن نشر 10000 ملف فقط ، أو ملف ZIP بحجم 39 ميغابايت دفعة واحدة. بطبيعة الحال ، إذا كانت الحمولة كبيرة جدًا ، فيجب عليك تقسيم الحزمة إلى أجزاء متعددة ثم القيام بالنشر.
2. إذا فشل النشر بسبب خطأ request timeout ، فحاول إزالة الكائنات والحقول المخصصة وملفات التعريف من الحزمة. تستغرق هذه المكونات وقتًا أطول لنشرها.
3. إذا تم تغيير نوع الحقل ، أو كانت هناك تغييرات في التسلسل الهرمي للأدوار ، فقد يكون هناك تأخير طويل بسبب إعادة حساب البيانات ، مما يتطلب بعض الوقت لإكماله.
4. يقوم Salesforce بتأمين أي مكون يتم استخدامه حاليًا من قبل مستخدم في النظام. إذا حاولنا النشر بينما كان هذا هو الحال ، فسيفشل النشر.

نأمل أن تساعدك هذه النظرة العامة خلال إصدار Salesforce التالي.

مصادر