كيف تُعِد الترقية العكسية في خط إصدار DevOps على Salesforce

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

ما المقصود بالترقية العكسية في خط إصدار Salesforce؟

الترقية المعتادة تنقل التغيير إلى أعلى: من dev إلى integration إلى uat إلى main. أما الترقية العكسية فتسير في الاتجاه المقابل، إذ تأخذ ما هو موجود بالفعل في بيئة أعلى وتدمجه نزولًا حتى تتطابق البيئات الأدنى.

هناك شيئان يجب أن ينتقلا، ومعظم الفرق تكتفي بالأول:

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

لماذا تحتاج الإصلاحات العاجلة إلى طريق للعودة إلى أسفل السلسلة؟

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

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

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

ما الذي يصنع فوضى الدمج فعلًا، وكيف تتجنبها؟

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

1. ادمج نزولًا ولا تستخدم cherry-pick. فالـ cherry-pick ينشئ إسنادًا جديدًا بمعرّف مختلف، فيظل Git يعتبر الأصل غير مدموج ويعيد إظهار التعارض نفسه في كل دمج لاحق. ادمج الفرع.
2. انزل درجة واحدة في كل مرة وبترتيب خط الإصدار. main في uat، ثم uat في integration، ثم integration في dev. ودمج main مباشرة في dev يترك الفروع المتجاوَزة لتتعارض لاحقًا.
3. نفّذها في اليوم نفسه الذي يُطلَق فيه الإصلاح. التباعد رخيص بالساعات وباهظ بالأسابيع.
4. افتح طلب دمج ولا تدفع مباشرة. فالأتمتة التي تدمج بصمت تُلغي المراجعة وسجل التدقيق، وهما أكثر ما يحتاجه الإصلاح العاجل.
5. افشل بصوت عالٍ عند التعارض وأسنده إلى كاتب الإصلاح. فهو صاحب السياق. أما التعارض الذي يصل إلى من في المناوبة فيُحَل بالتخمين.

الترقية العكسية ليست مشكلة نشر، بل مشكلة نظافة فروع تظهر بعد ثلاثة أسابيع في هيئة مشكلة نشر.

كيف تُعِد الترقية العكسية خطوة بخطوة؟

1. اكتب ترتيب خط الإصدار. قائمة مرتبة واحدة بالبيئات والفرع المقابل لكل منها. فبدونها لا معنى للترقية العكسية.
2. امنح الإصلاحات العاجلة فرعًا خاصًا من الإنتاج. تفرّع من main لا من dev، حتى لا يحمل الإصلاح معه شيئًا غير مُطلَق.
3. مرّر الإصلاح عبر البوابات المعتادة. الاختبارات نفسها والمراجعة نفسها والموافقة نفسها، لكن بمسار أقصر.
4. شغّل التتابع عند الدمج في main. يفتح خط الإصدار تلقائيًا طلب دمج للترقية العكسية نحو الفرع الأدنى مباشرة.
5. انشر كل فرع مدموج إلى بيئته. فتطابق الشيفرة دون تطابق البيئة يترك الانحراف في مكانه تمامًا.
6. تحقق بفحص انحراف. قارن كل بيئة أدنى بفرعها بعد انتهاء التتابع. وأي فرق يعني أن شيئًا غُيِّر في البيئة ولم يُسجَّل في المستودع.
7. وثّقها على بند العمل. الإصلاح العاجل لا ينتهي بإصلاح الإنتاج، بل ينتهي حين تحمله كل بيئة.

هل تحديث بيئة الاختبار بديل عن الترقية العكسية؟

لا، واعتباره بديلًا خطأ شائع ومكلف. فالتحديث يستبدل بيئة الاختبار بنسخة من الإنتاج، وهو ما ينزل بالإصلاح فعلًا، لكنه يدمّر في طريقه كل تغيير غير مُطلَق داخل تلك البيئة. كما أن التحديثات محدودة الوتيرة: بيئة Full لا تُحدَّث إلا كل 29 يومًا (Salesforce Help)، فهي حدث مجدول لا استجابة لعطل.

استخدم التحديثات لإعادة ضبط البيانات والانحراف طويل الأمد، واستخدم الترقية العكسية لإبقاء الشيفرة والبيئات متوافقة فيما بينهما. ومعظم منصات DevOps على Salesforce تدعم هذا الشكل بصورة أو بأخرى، ومنها Copado وGearset وAutoRABIT وFlosum وBlue Canvas وSalto. والمتغير هو ما إذا كان التتابع تلقائيًا، وما إذا كان يصل في صورة طلب دمج قابل للمراجعة.

FAQ

ما الفرق بين الترقية والترقية العكسية؟

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

هل ينبغي أن تكون الترقية العكسية تلقائية بالكامل؟

المُشغِّل وطلب الدمج نعم. أما الدمج نفسه فيجب أن يظل خاضعًا للموافقة، لأن تعارضًا يُحَل دون مراجعة هو الطريق إلى إلغاء الإصلاح مرتين.

كيف نتعامل مع تعارض أثناء الترقية العكسية؟

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

هل نحتاج الترقية العكسية إذا لم يعدّل أحد الإنتاج مباشرة؟

نعم، لكن بوتيرة أقل. فالفروع الطويلة العمر والإصدارات المتراجَع عنها وإصدارات الترقيع للحزم تضع جميعها تغييرات في البيئات الأعلى لا تملكها الأدنى.

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