تجميع الـ scratch orgs المُسخَّنة مسبقًا: السقف الخفي لسرعة إصدار الـ ISV

الإجابة باختصار: تجمّع الـ scratch orgs المُسخَّنة مسبقًا هو مجموعة بيئات تُنشأ وتُجهَّز بالكامل قبل الطلب، فيسحب البناء أو المطوّر بيئة جاهزة بدل أن ينتظر إنشاء واحدة. الأمر يهم فرق الـ ISV أكثر من فرق الأورج إلى الأورج، لأن كل عملية تحقق من حزمة تدفع كامل تكلفة إنشاء البيئة وتثبيت سلسلة الاعتماديات قبل تشغيل أول اختبار. التجميع ينقل تلك التكلفة خارج المسار الحرج.

لا أحد يضع "زمن إنشاء الـ scratch org" على شريحة خارطة الطريق. ومع ذلك هو ما يحدد سقف عدد المرات التي يستطيع فيها الـ ISV التحقق من حزمة، ومعظم الفرق لا تراه لأن الانتظار موزّع على كل طلب دمج بدل أن يظهر كبند واحد واضح.

ما هو تجميع الـ scratch orgs المُسخَّنة مسبقًا؟

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

التعريف ممل، لكن النتيجة ليست كذلك: الزمن حتى الحصول على بيئة صالحة يهبط إلى زمن سحبها فقط، ويتوقف عن التغيّر مع تعقّد شجرة الحزم عندك.

لماذا يضع زمن الإنشاء سقفًا على سرعة إصدار الـ ISV؟

تأمّل ما تفعله عملية تحقق واحدة من حزمة:

1. إنشاء الـ scratch org والانتظار حتى توفّرها Salesforce.
2. تثبيت سلسلة الاعتماديات، حزمة مُدارة تلو الأخرى، بالترتيب.
3. تثبيت أو نشر الحزمة محل الاختبار.
4. تحميل بيانات التجربة، وإسناد مجموعات الصلاحيات، وتشغيل كود الإعداد.
5. تشغيل الاختبارات. هذه هي الخطوة الوحيدة التي تنتج معلومة.

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

والتكلفة تقع في المكان الذي يشعر به الـ ISV تمامًا: فحوصات طلبات الدمج، والانحدار الليلي عبر عدة إصدارات، والتشغيل السابق للإطلاق مقابل كل نسخة ما زلت تدعمها لدى المشتركين.

ما الذي يغيّره التجمّع الساخن فعلًا؟

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

كم بيئة يستطيع الـ ISV تجميعها فعليًا؟

هنا تلتقي الخطة بالحصة المتاحة. توثّق Salesforce حدود الشركاء: الـ Partner Business Org النشطة تحصل على 150 بيئة نشطة و300 يوميًا، وحساب التجربة يحصل على 20 نشطة و40 يوميًا (راجع وثائق حصص الشركاء). ومن هنا نتيجتان.

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

هل اللقطة (snapshot) هي نفسها التجمّع؟

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

وللّقطات قيودها: تنتهي صلاحيتها بعد 90 يومًا، والحصة تبدأ من 3 في Developer Edition وتصل إلى 100 في Unlimited وPerformance، ولا تُنسخ معها التطبيقات المتصلة ولا بيانات الاعتماد الخارجية والمسمّاة. وبالنسبة للـ ISV هذا يعني أن اللقطة تتقادم مع أول تغيّر في إصدار اعتمادية.

الاثنان يتكاملان جيدًا. ابنِ التجمّع انطلاقًا من لقطة، فتوفّر عمل الإعداد والانتظار معًا.

كيف تدير تجمّعًا دون أن تحرق حصتك؟

1. افصل التجمّعات حسب الغرض. تجمّع التكامل المستمر قصير العمر وتجمّع المطوّرين أطول عمرًا، ولكل محتوى ومدة صلاحية مختلفة.
2. ثبّت إصدارات الاعتماديات في تعريف التجمّع. التجمّع المبني على "الأحدث" ينحرف بصمت عمّا تطلقه فعلًا.
3. جدّد باستمرار لا مرة واحدة ليلًا. عوّض البيئات فور سحبها حتى لا يفرغ التجمّع في منتصف الصباح.
4. أنهِ الصلاحية بحزم. البيئات الساخنة القديمة بيئات متقادمة تحتجز حصة نشطة.
5. راقب العمق لا النجاح فقط. الرقم الذي يتنبأ بأسبوع سيئ هو عدد المرات التي وصل فيها التجمّع إلى الصفر.

من أين تحصل على التجميع؟

يمكنك بناؤه بنفسك عبر أدوات sfp مفتوحة المصدر التي يوثّقها مشروع flxbl، وهكذا بدأ أوائل المتبنّين. أما في Serpent فالـ scratch orgs متاحة في كل الخطط، والتجميع المُسخَّن مسبقًا متوفّر في خطتَي Scale وEnterprise، إلى جانب مسارات 1GP و2GP وحل الاعتماديات عبر الحزم وبوابات الإصدار على AppExchange التي تحتاجها فرق الحزم على المنصة نفسها. وأيًا كان الطريق، أصرّ على أن يفهم التجمّع شجرة اعتمادياتك؛ فتجمّع بيئات فارغة يحل النصف الأصغر من المشكلة.

لو كنت ISV وزحفت فحوصات طلبات الدمج عندك من أربع دقائق إلى عشرين، فانظر أين تذهب هذه العشرون قبل أن تحسّن اختبارًا واحدًا. Serpent مبني لهذا الفريق تحديدًا.

FAQ

ما الحجم المناسب لتجمّع الـ scratch orgs؟

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

هل تُحتسب البيئات المجمّعة ضمن حدود Salesforce؟

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

لقطات أم تجميع؟

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

هل يفيد التجميع فرق الأورج إلى الأورج أيضًا؟

بدرجة أقل. من دون سلسلة اعتماديات تُثبَّت، يصبح الإنشاء البارد أرخص بكثير، فيقل العائد مقارنةً بفرق الحزم.