إزاي تكتب runbook لتحديث الـ sandbox فريقك هيمشي عليه فعلا

الـ runbook اللي فريقك هيمشي عليه فعلا لتحديث الـ sandbox بيكون قصير، ومحفوظ جنب الكود، وكل خطوة فيه ليها مسؤول ووقت متوقع وفحص بيثبت إنها خلصت. أغلب مستندات التحديث بتفشل لأنها صفحات wiki طويلة مالهاش صاحب. اكتب بتاعك كـ checklist من أربع مراحل، وخلّي الخطوات اللي الناس بتنساها أوتوماتيك، وجرّبه مرة قبل ما تعتمد عليه.

يعني إيه runbook لتحديث الـ sandbox؟

هو الإجراء خطوة بخطوة اللي فريقك بينفذه كل مرة sandbox في Salesforce بيتعمله refresh من الإنتاج: تحفظ إيه قبل، وترجّع إيه بعد، ومين بيعمل كل خطوة، وتعرف إزاي إنها نجحت. ده مش استراتيجية الـ sandbox، اللي بتحدد أنهي sandboxes موجودة وليه. الـ runbook هو الجزء اللي الناس بتنفذه صباح يوم التحديث.

ليه الفرق بتتجاهل الـ runbooks؟

• مفيش مسؤول لكل خطوة. لما الفريق كله مسؤول عن رجوع التكاملات، محدش بيعملها.
• مفيش تعريف لكلمة خلصت. إعادة ضبط التكاملات مش حاجة تتفحص. لكن callout تجريبي عن طريق الـ named credential رجّع 200 حاجة تتفحص.
• محفوظ في المكان الغلط. صفحة الـ wiki بتبعد عن الـ org مع الوقت. ملف Markdown في الـ repo بيتراجع لما الـ org تتغير.
• خطوات يدوية كتير. كل خطوة يدوية هي خطوة حد هيفوّتها وهو مضغوط.

تقدر تعمل refresh لكل نوع sandbox كل قد إيه؟

‏Salesforce بتحدد الإيقاع بتاعك، فحط الحدود دي في أول الـ runbook. حسب دليل Salesforce Ben للـ sandbox:

• ‏Developer وDeveloper Pro: مرة في اليوم، metadata بس.
• ‏Partial Copy: كل خمس أيام، metadata وجزء من البيانات.
• ‏Full: كل 29 يوم، كل metadata وبيانات الإنتاج.

تحديث Full بايظ ممكن يكلفك شهر، عشان كده الـ runbook بتاعه محتاج أكبر قدر من الدقة.

إيه اللي يتكتب في كل مرحلة من الـ runbook؟

اكتب كل خطوة بنفس الشكل: step | owner | automated? | minutes | done when. وبعدين قسّم الخطوات على أربع مراحل.

1. قبل التحديث

• بلّغ المطورين والـ QA ومختبري البيزنس بموعد التحديث، وخد تأكيد منهم.
• اعمل commit أو deploy لكل تغيير شغّال على version control. التحديث بيمسح الـ sandbox، وأي حاجة مش في Git بتروح.
• صدّر الإعدادات المحفوظة كبيانات، زي سجلات الإعدادات اللي بعض حزم AppExchange بتحفظها برا الـ metadata.
• اعمل قائمة بالـ endpoints والـ named credentials والـ connected apps اللي هتحتاج توجّهها من جديد.

2. أثناء التحديث

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

3. بعد التحديث

• خلّي إعداد إرسال الإيميل على System email only، وده الافتراضي للـ sandboxes الجديدة واللي اتعملها refresh حسب Apex Hours، لحد ما البيانات تتخفي.
• شيل لاحقة .invalid بس للمستخدمين اللي محتاجين إيميل في الـ sandbox. ‏Salesforce بتضيفها لإيميلات المستخدمين مع كل refresh أو clone، زي ما مقالة المساعدة بتشرح.
• اخفي أو امسح البيانات الشخصية قبل ما توسّع الصلاحيات.
• وجّه التكاملات لـ endpoints الـ sandbox واعمل authentication من جديد.
• اعمل deploy تاني للشغل اللي سابق الإنتاج من version control، وبعدين حمّل بيانات الاختبار.

4. التحقق والتسليم

• اعمل smoke test: ادخل كمختبر، شغّل flow أساسي واحد، واعمل callout تجريبي واحد.
• شغّل اختبارات الـ Apex، أو على الأقل الجزء اللي بيغطي التكاملات.
• ابعت رسالة إن الـ sandbox جاهز ومعاها المشاكل المعروفة، وصلّح في الـ runbook نفسه أي حاجة باظت.

أنهي خطوات تحديث تعملها أوتوماتيك الأول؟

ابدأ بالخطوات المتكررة اللي فيها أخطاء كتير والمملة. واجهة SandboxPostCopy في Salesforce بتخليك تكتب كلاس Apex بيشتغل لوحده لما الـ sandbox يتعمل، وأفضل ممارسات Salto للتحديث بتذكر إخفاء الإيميلات وتحديث الـ custom settings والـ custom metadata كاستخدامات معتادة. مرشحين كويسين للبداية:

1. إخفاء البيانات الشخصية على الـ contacts والـ leads.
2. رجوع الـ custom settings وإعدادات الـ endpoints لقيم الـ sandbox.
3. رجوع الإيميل للمجموعة الصغيرة من المستخدمين اللي محتاجاه.
4. إعادة تحميل بيانات الاختبار الأساسية. دليلنا عن إزاي تملا sandbox في Salesforce ببيانات واقعية بيغطي الاختيارات.

خلّي الكلاس idempotent وسجّل كل حاجة غيّرها، عشان لو تشغيلة فشلت تقدر تعيدها بأمان.

الـ runbook بيدخل إزاي في الـ release pipeline بتاعك؟

التحديث بيرجّع الـ sandbox لحالة الإنتاج، فأي حاجة بين الـ sandbox ده والإنتاج بتختفي إلا لو الـ pipeline رجّعها. فيه عادتين بيمنعوا الخسارة دي. الأولى: خلّي Git هو مصدر الحقيقة، عشان الشغل اللي لسه ماخلصش يتعمله deploy تاني مش يتبني من الأول. التانية: جهّز الـ back-promotion في Salesforce DevOps pipeline عشان الـ hotfixes اللي في الإنتاج تنزل للبيئات الأقل بين التحديثات. بعد التحديث شغّل نفس الفحوصات اللي بتشغلها مع كل pull request. دليلنا عن أتمتة اختبارات Salesforce في الـ CI بيفصل اللي يتشغل مع كل pull request عن اللي يتشغل بالليل.

لو الـ deploy بعد كل تحديث لسه بياخد بعد الضهر كله يدوي، منصة DevOps بتشيل عنك أغلبه. خطة Essentials المجانية من Serpent فيها delta deployments وrollback بضغطة واحدة؛ قارن الخطط على صفحة أسعار Serpent.

إزاي تخلّي الفريق يمشي عليه فعلا؟

• خلّي كل مرحلة في شاشة واحدة، وحط روابط للتفاصيل.
• احفظ الـ runbook في الـ repo وراجع تعديلاته زي الكود.
• جرّبه على Developer sandbox، اللي تقدر تعمله refresh كل يوم، قبل تحديث الـ Full الجاي.
• حدّثه في نفس اليوم اللي حاجة تبوظ فيه. الـ runbook اللي يطلع غلط مرة بيتساب على طول.
• حدد مسؤول احتياطي لكل خطوة.

لأدلة عملية تانية زي ده، اتفرج على مكتبة SF Guides.

FAQ

الـ runbook بتاع تحديث الـ sandbox المفروض يكون طوله قد إيه؟

قصير كفاية إن كل مرحلة تبقى في شاشة واحدة. خلّي الـ runbook هو الـ checklist وحط التفاصيل في مستندات مربوطة.

‏SandboxPostCopy بيُستخدم في إيه؟

هي واجهة Apex لكلاس بيشتغل لوحده لما الـ sandbox يتعمل، وغالبا بيُستخدم لإخفاء البيانات ورجوع الإعدادات.

ليه إيميلات المستخدمين بتنتهي بـ .invalid بعد التحديث؟

‏Salesforce بتضيف .invalid عشان مستخدمي الإنتاج ما يوصلهمش إيميلات من الـ sandbox. شيلها بس للمستخدمين اللي محتاجين إيميل في الـ sandbox.

تقدر تعمل refresh لـ Full sandbox كل قد إيه؟

مرة كل 29 يوم. الـ Partial Copy كل خمس أيام، والـ Developer كل يوم.