DevOps في سيلزفورس للأدمن: إزاي تنشر من غير ما تلمس Git

الإجابة باختصار: مش لازم أدمن سيلزفورس يتعلم Git عشان ينشر تغييراته بأمان. اللي محتاجه فعلاً هو خط نشر متتبَّع النسخ، وأداة DevOps شغالة بنظام التذاكر تقدر تديره بدالك: أنت بتختار تغييراتك من واجهة، والأداة بتعمل الـ commit، وتفتح الـ pull request، وتشغّل الاختبارات، وتنقل الشغل بين بيئاتك. Git لسه شغال تحت، بس ما بقاش هو الواجهة اللي بتتعامل معاها.

هل تحتاج Git فعلاً لعمل DevOps في سيلزفورس؟

لا. أنت محتاج النتيجة اللي بيقدمها Git، وده شيء مختلف. تلات مفاهيم بتحمل تقريباً كل القيمة، ومفيش واحد فيهم بيحتاج سطر أوامر.

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

سير عمل من غير Git مش معناه سير عمل من غير تتبّع نسخ، لكنه سير عمل بيتم فيه تتبّع النسخ آلياً نيابة عنك.

ليه الـ change sets بتقف عند حد معين مع فريق الأدمن؟

الـ change sets هي المنافس الحقيقي على أرض الواقع، وبتنفع تماماً لحد ما شخص تاني يبدأ يعدّل. حاجتين بيعملوا معظم الضرر. الأولى إن الـ change set محتاج deployment connection وما بيتحركش غير بين المؤسسات المرتبطة بنفس مؤسسة الإنتاج، يعني المؤسسات غير المرتبطة خارج المتناول أصلاً (مساعدة سيلزفورس). والتانية إنه طرد لمرة واحدة: من غير سجل، ومن غير تراجع، ومش قابل للتعديل بعد الرفع، فأي إصدار مرفوض معناه إعادة بناء قائمة المكوّنات يدوياً.

وأكتر عطل بيوجع مش هو النشر اللي بيفشل، لكنه الكتابة الصامتة فوق شغل غيرك: اتنين بيعدّلوا نفس الـ flow أو نفس الـ page layout في ساندبوكسين مختلفين، واللي بينشر تاني بيكسب من غير ما حد ياخد باله.

شكل النشر بنظام التذاكر من أول خطوة لآخر خطوة؟

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

1. اربط المؤسسات مرة واحدة. صرّح للإنتاج ولكل ساندبوكس عبر OAuth. المنصة اللي بتعتمد على واجهات سيلزفورس القياسية بس مش بتثبّت أي حزمة جوه مؤسستك، فمفيش حاجة تشيلها بعدين.
2. عرّف خط النشر. سمّي بيئاتك ورتّب تسلسل الترقية بينها. ده إعداد لمرة واحدة، وبعد كده يبقى هو الطريق الوحيد للإنتاج.
3. افتح تذكرة. تذكرة لكل تغيير، ويفضل لكل user story. التذكرة، مش الساندبوكس، هي وحدة الإصدار دلوقتي.
4. اشتغل في الساندبوكس زي ما بتعمل بالظبط. إعدادات بالضغط، وFlow Builder، وpage layouts. طريقتك في تهيئة سيلزفورس ما بتتغيرش.
5. اختار تغييراتك. الأداة بتعرض اللي اتغيّر في الساندبوكس من آخر مزامنة. تعلّم على المكوّنات، تكتب وصف قصير، وتربطهم بالتذكرة.
6. مراجعة قبل ما يتحرك أي حاجة. اختبارات Apex والتغطية بتشتغل أوتوماتيك، ومراجعة بالذكاء الاصطناعي بتقرا الفرق وتدوّر على انحراف الحوكمة ومشاكل الأمان ومخالفات أفضل الممارسات. وزميل بيعتمد التذكرة.
7. رقّي نفس الاختيار. التذكرة المعتمدة بتنتقل لـ UAT وبعدين للإنتاج. عمرك ما بتعيد بناء القائمة، وده بالظبط المكان اللي بتضيع فيه مكوّنات إصدارات الـ change sets.
8. أطلق واحتفظ بزرار التراجع. نشر الإنتاج بيتسجّل، فلو الإصدار عمل مشاكل بترجع لآخر حالة سليمة بحركة واحدة، من غير ما تحاول تستنتج اللي اتنشر.

Git بيعمل إيه وأنت بتضغط؟

كل خطوة فوق ليها مقابل في Git بتنفذه المنصة بدالك:

• فتح التذكرة بينشئ فرعاً جديداً.
• اختيار المكوّنات بيكتب commit ووصفك بيبقى رسالته.
• طلب المراجعة بيفتح pull request ويشغّل عليه الفحوص الآلية.
• الاعتماد والترقية بيدمجوا الـ pull request ويبدأوا نشراً عبر Metadata API.
• التراجع بيلغي الـ commit ويعيد نشر الحالة السابقة.

وده مهم لسبب عملي واحد: المطورين عندك بيفضلوا على نفس المستودع ونفس الفروع ونفس الـ CLI اللي بيستخدموه، والأدمن بيشتغل في واجهة فوق نفس السجل. مفيش مصدر حقيقة تاني محتاج توفيق.

هل DevOps Center كفاية لوحده؟

سيلزفورس بتوفر خيارها المجاني، وبالنسبة لفريق صغير خارج من الـ change sets ده تقدّم حقيقي. بس اعرف الحدود قبل ما تلتزم. DevOps Center بيشتغل مع خطط GitHub.com السحابية بس، ومنها GitHub Enterprise Cloud، أما GitHub Enterprise Server المستضاف محلياً فغير مدعوم. وكل مستخدم محتاج حساب GitHub.com خاص بيه، وكل مستودع مشروع لازم يحتوي على مشروع Salesforce DX (مساعدة سيلزفورس).

يعني الأدمن ما بيكتبش أمر Git أبداً، لكن لسه في حد بيدير GitHub، والنسخ الاحتياطي والتراجع وأتمتة الاختبارات كلها بره المنتج. لو ده وصف فريقك، فمنصة بتغطي المسار كامل هتبقى أخف عليك.

الأدمن يجهّز إيه في أول أسبوع؟

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

Serpent بينفذ المسار ده وGit شغال في الخلفية، وما بيثبّتش أي حاجة في مؤسسة سيلزفورس عندك، وبيشمل مراجعة كود بالذكاء الاصطناعي في كل الخطط بما فيها الخطة المجانية. الإعداد بياخد أقل من 15 دقيقة وفريقنا بيعمله معاك.

FAQ

هل يقدر أدمن سيلزفورس يعمل DevOps من غير مطوّر؟

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

هل سير العمل من غير Git بيديني إمكانية التراجع؟

بس لو الأداة بتحتفظ بسجل النسخ. التراجع ممكن لأن كل نشر اتعمل له commit الأول، وده بالظبط اللي الـ change sets ما بتعملهوش.

هل واجهة الأدمن هتبطّئ المطورين عندي؟

لا، طالما الطرفين على مستودع واحد. المطورون بيفضلوا على الـ CLI وفروعهم، والواجهة مجرد باب تاني لنفس السجل.

أعمل إيه في الـ change sets الموجودة عندي؟

سيبها لإصدار واحد وأنت بتشغّل خط النشر الجديد بالتوازي، وبعدين أوقفها. وما تنقلش إصدار في نص الطريق.

تلاقي أدلة عملية أكتر خطوة بخطوة عن DevOps في سيلزفورس داخل مكتبة SF Guides.