الانتقال من Copado إلى Serpent: دليل تنفيذي خطوة بخطوة

الإجابة باختصار: إنت مش محتاج تجميد للكود، وإنت مش بتنقل بيانات. الـ metadata بتاعتك عايشة أصلًا في Git، فالانتقال من Copado لـ Serpent هو تبديل لطبقة التحكم: بتعيد بناء تعريف الـ pipeline، وتشغّل الأداتين جنب بعض دورة إصدار كاملة، وبعدين تسيب الـ pipeline الجديد ياخد الترقية للإنتاج والقديم فاضل مثبت كخطة رجوع. خطط بدورات الإصدار، مش بأيام التقويم.

إيه اللي بيتحرك فعلًا، وإيه اللي بيفضل مكانه؟

الدقة في النقطة دي بتشيل معظم القلق من الأوضة:

• مفيش حاجة محتاجة ترحيل. مصدر الحقيقة عندك هو مستودع Git، وهو فاضل مكانه بالظبط بكل تاريخه.
• اللي بيفضل ورا هو السجلات اللي عايشة جوه الحزمة المُدارة بس: الـ user stories والترقيات وسجلات النشر وأي أتمتة مبنية عليها. Copado متثبت جوه الـ org بتاعتك، فالكائنات دي بتمشي مع الحزمة.
• اللي بتعيد بناءه هو تعريف الـ pipeline: البيئات وبياناتها، وترتيب المراحل، وقواعد الموافقة، وبوابات الجودة، والمهام المجدولة، والربط بنظام التذاكر.

القائمة الأخيرة دي هي المشروع كله. ده شغل إعدادات، وعشان كده الموضوع بيبقى تمرين مطابقة مش عملية ترحيل.

مفاهيم Copado بتتحول لإيه في pipeline قائم على Git؟

Copado بيمثّل الإصدار في سجلات Salesforce. الـ pipeline القائم على Git بيمثّله في المستودع. والترجمة تقريبًا واحد لواحد:

• الـ User Story بتبقى عنصر عمل مربوط بفرع.
• فرع الميزة لكل user story بيفضل فرع ميزة. وتقدر تحافظ على نفس تسمية الفروع عشان التاريخ يفضل متصل.
• الترقية وفرع الترقية بيبقوا pull request على فرع البيئة اللي بعدها.
• سجل النشر بيبقى تشغيلة pipeline، بسجل ونتيجة ونقطة رجوع خاصة بيها.
• البيئة أو المرحلة بتبقى بيئة مربوطة بفرع.
• الترقية العكسية بتبقى دمج راجع لتحت من الفرع الأعلى.
• بوابات الامتثال والجودة بتبقى فحوصات على الـ pull request: اختبارات وتحليل ساكن ومراجعة كود بالذكاء الاصطناعي.

إيه خطوات التنفيذ بالترتيب؟

1. الجرد، من يوم لاتنين. اكتب كل بيئة وفرع ومرحلة ومعتمد ومهمة مجدولة وبوابة جودة وتكامل، وقدام كل واحدة اسم المسؤول. لو في مرحلة مالهاش مسؤول، فدي أول ملاحظة عندك.
2. اعمل نسخة مطابقة للـ pipeline للقراءة بس. اربط نفس الـ orgs ونفس المستودع بـ Serpent من غير ما تنشر أي حاجة. الربط بياخد دقايق. وبعدين قارن: هل الأداتين متفقين على اللي موجود في كل بيئة دلوقتي؟ أي اختلاف ده انحراف كان موجود عندك قبل الانتقال أصلًا.
3. ظلّل دورة إصدار كاملة. كل تغيير بيعدي من Copado زي المعتاد، وكمان من الـ pipeline الجديد لبيئة اختبار احتياطية. قارن خطط النشر. الفروقات بتبقى قائمة ملاحظاتك، وغالبًا بتكون في الـ profiles وpermission sets والـ flows.
4. شغّل إصدار حقيقي بالتوازي. الـ pipeline الجديد بيرقّي لبيئة القبول، والقديم لسه ماسك الإنتاج. دي نقطة المنتصف المتحكَّم فيها، وهنا المعتمدين بيرتاحوا.
5. حوّل بالكامل. الـ pipeline الجديد بينفذ ترقية الإنتاج. سيب Copado متثبت ومن غير ما تلمسه، لأن ده خط الرجوع: لو الترقية فشلت، الإصدار اللي بعده بيرجع يعدي منه.
6. فكّك بعد إصدارين نضاف. صدّر التاريخ، وعطّل المهام المجدولة القديمة الأول، وبعدين شيل الحزمة المُدارة في بيئة اختبار قبل ما تقرب من الإنتاج.

تعمل إيه في تاريخ الـ user stories؟

ده السؤال اللي بيوقف عمليات الانتقال، والإجابة الصريحة: ما تحاولش تستورده.

• السجلات التاريخية ليها معنى في الأداة اللي أنشأتها بس. user stories مستوردة من غير pipeline حي وراها بتبقى ديكور، وهتضلل حد بعد سنة.
• صدّرها بدل كده. الـ user stories والترقيات وعمليات النشر في ملفات CSV، ومعاها مرجع الـ commit لو موجود. واحفظها مع باقي أدلة الإصدارات عندك.
• التاريخ الباقي هو Git. الـ commits والـ pull requests وعمليات الدمج والوسوم هي اللي المدققين بيقبلوها فعلًا، وكل حاجة بعد التحويل بتتسجل هناك تلقائيًا.
• لاستمرارية التدقيق احتفظ بالتصدير مع روابط الـ commits. أرشيف مؤرخ وفرع قابل للتتبع أحسن بكتير من لقطات شاشة من نظام متوقف.

تتعامل إزاي مع استراتيجية الفروع؟

غيّر حاجة واحدة في المرة. الأداة الأول، والعملية بعدين.

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

تتجنب إزاي التوقف وتجميد الكود؟

• جمّد إعدادات الـ pipeline مش الشغل. خلال التشغيل المتوازي محدش يعدل مراحل ولا موافقات ولا قواعد فروع في أي من الأداتين.
• حط التحويل في بداية دورة عمل، مش في آخرها، ولا في ويك إند إصدار.
• اكتب خطة الرجوع قبل ما تحتاجها. جملة واحدة: لو ترقية الإنتاج فشلت على الـ pipeline الجديد، اللي بعدها بتعدي من الأداة القديمة والاتنين يفضلوا متصلين إصدار زيادة.
• سيب الأداتين متصلين لكام إصدار بس. نظامين بيكتبوا على نفس الفروع للأبد مش شبكة أمان، ده تعارض دمج بمواعيد.

المدة بتحددها دورات الإصدار مش التركيب. ربط الـ orgs والمستودعات شغل يوم واحد، وتأهيل Serpent بيشمل جلسة عملية للفريق كله من غير تكلفة، فمطابقة الـ pipeline بتتعمل معاك مش بتتسلملك كمهمة. أدلة أكتر عن Salesforce DevOps.

FAQ

هل محتاجين تجميد كود عشان نغيّر الأداة؟

لأ. الأداة الحالية بتفضل متثبتة وهي المرجع لحد إصدار التحويل، فالتطوير بيكمل عادي.

نقدر نحتفظ بمستودع Git وأسماء الفروع؟

أيوه. المستودع ما بيتلمسش، والاحتفاظ بنفس تسمية الفروع بيخلي التاريخ متصل قبل وبعد الانتقال.

الـ user stories بتاعتنا بيحصلها إيه لما نشيل الحزمة؟

بتمشي معاها، وعشان كده بتصدّرها CSV الأول. الـ commits والـ pull requests والوسوم في Git بتفضل، ودي هي سلسلة التدقيق الباقية.

الانتقال كله بياخد قد إيه؟

فكّر بدورات الإصدار: دورة تظليل، ودورة توازي، ودورة تحويل. لـ pipeline عادي من org لـ org ده أسابيع، معظمها انتظار لإصداراتك إنت.

نقدر ننقل pipeline حزم أو ISV بنفس الطريقة؟

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