GitHub Actions المصنوعة داخليًا لـ Salesforce: يحصل إيه لما اللي بناها يمشي؟

الإجابة باختصار: أول أسبوعين مش بيحصل حاجة. وبعدين ريليز من Salesforce بيغير نسخة API، وشهادة بتنتهي، وصورة runner بتشيل اعتمادية، والنشر بيفشل برسالة خطأ محدش ساب عنها ملاحظة. الـ pipeline اللي بتتبني بالإيد نادرًا ما تكون بنية تحتية. دي مشروع شخصي بعامل حافلة يساوي واحد، والفاتورة بتوصل بعد حوالي تمنتاشر شهر.

ليه الـ pipeline المصنوعة داخليًا بتبان مجانية في الأول؟

لأن البناء نفسه فعلًا رخيص. الشروحات المتاحة كويسة: مصادقة JWT على connected app، وأسرار في الريبو، وملف workflow لكل فرع، وsfdx-git-delta عشان تنشر المتغير بس، وتشغيل اختبارات بحد أدنى للتغطية (عند Salesforce Ben شرح متكامل). مهندس كويس بيشغّل ده في أسبوعين، وأول سنة بيشتغل تمام.

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

ليه الـ pipeline بتقع بعد حوالي تمنتاشر شهر؟

لأن كل اللي تحتيها بيتحرك، والـ YAML لأ.

• تلات ريليزات Salesforce في السنة. نسخ الـ API بتتقدم، وأشكال الميتاداتا بتتغير، والنسخ المثبتة في الـ workflow بتتأخر في صمت.
• الـ CLI بتتغير. أوامر بتتسمى من جديد وبتتلغي. السكربتات المكتوبة بالأسماء القديمة بتفضل شغالة لحد ما تقف فجأة.
• الشهادات والأسرار بتنتهي. الشهادة الموقّعة ذاتيًا ورا الـ connected app ليها تاريخ انتهاء محدش حطه في تقويم.
• صور الـ runner بتتغير. الـ runners المستضافة بتحدّث نظام التشغيل وNode وJava على جدولها هي، مش جدولك.
• الـ actions الخارجية بتنجرف. أداة الدلتا والماسح وactions المجتمع المثبتة على tag، كلها ليها دورات إصدار وتغييرات كاسرة خاصة بيها.
• الأورج بتكبر. الـ pipeline اتصممت لساندبوكسين وأربع مساهمين. دلوقتي بتخدم خمس بيئات وحزمة وناس عمرها ما فتحت ترمينال.

ولا واحدة من دي صعبة لوحدها. هي صعبة لأنها بتيجي يوم تلات بعد الضهر، في نافذة ريليز، في ريبو صاحبه مشي في مارس.

الصيانة بتكلف كام فعلًا؟

الإجابة الأمينة إنها وظيفة نصف دوام دائمة وغير مدرجة في أي ميزانية. أدبيات المزودين متفقة على الشكل حتى لو الأرقام جاية من أماكن مختلفة: Gearset، نقلًا عن Harvard Business Review، بتحط تجاوزات مشاريع البرمجيات المبنية داخليًا عند 70% (build or buy)، وCopado بتقول إن مزودي DevOps المستقرين بيصرفوا من 10 لـ 15% من طاقتهم التطويرية بس عشان يلحقوا تغييرات منصة Salesforce (the hidden costs of building your own). لو قريت الاتنين مع بعض، الخلاصة مزعجة لكنها بسيطة: المزود المتخصص بيتعامل مع توافق المنصة كبرنامج هندسي بدوام كامل. أما الـ pipeline بتاعتك فبتاخد اللي فاضل من يوم جمعة عند شخص واحد.

والتكاليف اللي عمرها ما بتدخل في دراسة الجدوى:

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

إزاي تختبر عامل الحافلة عندك؟

خمس أسئلة. جاوبها بأمانة الأسبوع ده، مش وقت الاستقالة.

1. لو الـ pipeline فشلت دلوقتي، كام شخص يقدر يقرا الـ log ويحدد السبب؟
2. فين دليل التشغيل، وآخر مرة كان صح فيها كانت إمتى؟
3. مين بيدوّر بيانات الاعتماد، وإيه تاريخ انتهاء الشهادة الحالية؟
4. هل حد مش مطور يقدر يبدأ نشر ويفهم النتيجة؟
5. لو سلّمت ده لمقاول بكرة، هياخد قد إيه عشان يبقى منتج؟

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

إمتى يفضل البناء الداخلي هو القرار الصح؟

لما الـ pipeline تتعامل كمنتج مش كخدمة شخصية. يعني مالك بالاسم مش لوحده، وشخص تاني صلّحها فعلًا قبل كده، وتوثيق اتجرب على إيد حد اتبعه خطوة خطوة، واعتماديات مثبتة ومراجعة، وسطر في ميزانية. في فرق كتير بتوصل للمستوى ده، خصوصًا اللي عندها وظيفة platform engineering حقيقية ومتطلبات مالهاش تغطية عند أي مزود. لو عندك قدرة DevOps داخلية عميقة واستعداد تموّلها، البناء الداخلي قرار مدافَع عنه.

اللي مش بينفع هو الوسط: نظام مخصص من غير مالك، في فريق شغله الحقيقي إنه يسلّم مزايا على Salesforce.

تعمل إيه في أسبوع تقديم الاستقالة؟

1. اقعد معاه واكسر الـ pipeline بقصد في ساندبوكس. اتفرج على طريقته في التشخيص وسجّلها.
2. اعمل جرد لكل سر وشهادة وحساب خدمة، ومعاه تاريخ الانتهاء.
3. خلي شخص تاني يعمل نشر كامل من غير مساعدة، والمؤلف قاعد يتفرج من غير ما يلمس الكيبورد.
4. اكتب أكتر تلات أعطال بتتكرر، ومعاها الحل بتاع كل واحد.
5. قرر بوضوح هتكمّل بيها ولا هتستبدلها. الانجراف ناحية القرار هو اللي بيكلّف فلوس.

والقرار الأخير ده بالظبط هو المكان اللي المنصة المدعومة بتثبت فيه قيمتها. Serpent موجودة عشان الـ pipeline بتاعت Salesforce ما تبقاش مشروع جانبي لشخص واحد: النشر بيتم عن طريق تذاكر وGit شغال تحتيها، فالأدمنز والاستشاريين يقدروا يطلبوا الريليزات ويتابعوها من غير CLI، وتوافق المنصة بقى مشكلتنا إحنا مش مشكلة الزميل اللي ماشي. Serpent مش بتثبّت أي حاجة في الأورج وبتتصل عن طريق الـ APIs القياسية، والتسعير ثابت لكل شركة بعدد مستخدمين غير محدود، وفيه باقة Essentials مجانية تجربها على الأورج بتاعتك. الإعداد بياخد أقل من 15 دقيقة، وفريقنا بيعمل جلسة التأهيل معاك.

FAQ

هل GitHub Actions اختيار وحش لـ CI/CD في Salesforce؟

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

الـ pipeline المبنية بالإيد بتعيش قد إيه؟

عادةً بتشتغل كويس أول سنة، وبعدين تبدأ تاكل وقت حقيقي مع تراكم ريليزات Salesforce وتغييرات الـ CLI وانتهاء بيانات الاعتماد وتحديثات الـ runners.

إيه أول حاجة بتقع لما صاحبها يمشي؟

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

إزاي نقلل عامل الحافلة من غير ما نستبدل الـ pipeline؟

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

هل الشراء دايمًا أرخص من البناء؟

مش دايمًا. البناء له وجاهة لو عندك قدرة platform engineering حقيقية ومالك ممول. وبيبقى غالي لما الـ pipeline تكون جميل من حد شغله الأساسي تسليم مزايا.