لماذا تفشل دورة حياة تطبيقات Power Platform (وكيف تصلحها)

By Mirko Peters · 2026-08-11

مرحباً بعودتكم يا صناع البودكاست ومطوّري الأتمتة! إذا قضيتم ساعات طويلة في استكشاف أخطاء حل Power Apps الذي نُشر بسلاسة في بيئة التطوير sa…

Automatically translated with AI from the original post. Read the English original

مرحباً بعودتكم يا صناع البودكاست ومطوّري الأتمتة! إذا قضيتم ساعات طويلة في استكشاف أخطاء حل Power Apps الذي عمل بسلاسة في بيئة التطوير التجريبية، ثم انهار تماماً حين نُقل إلى بيئة الاختبار أو الإنتاج، فأنتم بالتأكيد لستم وحدكم. تأتي إدارة دورة حياة التطبيق (ALM) في Microsoft Power Platform بمجموعة فريدة من الخصائص والتبعيات المخفية ونقاط الفشل الصامتة التي نادراً ما يواجهها مطوّرو البرمجيات التقليديون. في منشور المدونة هذا، سنتعمق في أسباب تعطّل ALM في Power Platform بهذه الكثرة، والأهم من ذلك، كيف يمكنكم بناء خط أنابيب CI/CD متين وموثوق باستخدام GitHub Actions للقضاء على هذه المشكلات مرة واحدة وإلى الأبد. للاطلاع على شرح شامل لهذه المفاهيم، تأكدوا من مشاهدة حلقة البودكاست ذات الصلة: Set Up Power Platform ALM with GitHub Actions.

ما ستتعلمه

• لماذا يفشل ALM في Power Platform (مراجع الموصلات الخفية، ومتغيرات البيئة، والانحراف، وDLP)
• كيفية هيكلة GitHub Actions: المشغّلات، والوظائف، والبيئات، والموافقات
• تأمين الهوية والأسرار: مبادئ الخدمة، وأسرار البيئة المحددة النطاق، وإعادة ربط المتغيرات
• خطوات البناء والاختبار التي تكشف المشكلات مبكرًا (التحقق من الحلول، وفحوص التبعيات)
• نمط نشر نظيف مع آثار جاهزة للتراجع

متاهة ALM: ما الذي يختلف فعلًا؟

• المصدر ≠ الكود: تتضمن الحلول ملفات XML/JSON ومنطقًا مخفيًا؛ ولا تظهر التغييرات إلا بعد التصدير.
• الموصلات خاصة بكل بيئة: تشير المراجع إلى كائنات غير موجودة في بيئات أخرى افتراضيًا.
• متغيرات البيئة مهمة: يجب استبدال نقاط النهاية والمفاتيح وقت النشر، لا تضمينها في الحل.
• عمليات النشر اليدوية تُخفق في التدقيق: استخدم مبادئ الخدمة لضمان الاتساق وإمكانية التتبع.

النظام الأساسي: المصدر ← البناء ← الاختبار ← النشر (لـ Power Platform)

المصدر

• احتفظ بالحلول في Git بصيغة غير مضغوطة (pac CLI) لتسهيل مراجعة الفروقات في طلبات السحب.
• ارفع كلًا من عمليات التصدير المُدارة (للإصدار) وغير المُدارة (للتطوير)، ووسمها برقم إصدار الحل.
• احتفظ بمجلد /config لكل بيئة (متغيرات البيئة، وتعيينات مراجع الموصلات).

البناء

• استخدم GitHub Actions من أجل التجميع/التحقق:
  • فك الضغط وإعادة التجميع باستخدام PAC CLI
  • شغّل Solution Checker (وأوقف العملية عند وجود أخطاء حرجة)
  • أنشئ تقرير التبعيات (تدفقات فرعية، وPCF، ومراجع الموصلات)
  • انشر الآثار: ملف managed.zip مع التقارير

الاختبار

• شغّل وظيفة اختبار على البيئة المستهدفة:
  • تحقق من وجود متغيرات البيئة وتعبئتها
  • حدّد مراجع الموصلات إلى الموصلات المعتمدة
  • تشغيلات اختبار تدفق "بلا عملية" اختيارية (حيثما يكون التنفيذ آمنًا)

النشر

• استورد الحل المُدار باستخدام مبدأ خدمة محدد النطاق على تلك البيئة.
• أعد ربط متغيرات البيئة ومراجع الموصلات من /config/test|prod.
• فحوص ما بعد النشر السريعة (تشغيل التدفق الرئيسي، وفتح التطبيق، والتحقق من صلاحيات الأدوار).

GitHub Actions: المشغّلات والوظائف والبيئات

المشغّلات الموصى بها

• push إلى feature/* ← التجميع والتحقق فقط
• pull_request إلى main ← بناء كامل + Solution Checker + الأثر
• workflow_dispatch على release/* ← النشر إلى الاختبار
• environment: production مع مراجعين مطلوبين ← النشر إلى الإنتاج

فصل الوظائف

1. build: التجميع والتحقق وSolution Checker ونشر الآثار
2. prepare-env: جلب إعدادات البيئة وتعيين المتغيرات والمراجع
3. deploy-test/prod: استيراد الحل المُدار، وتطبيق التعيينات، وفحوص سريعة

حماية البيئات

• استخدم GitHub Environments مع أسرار محددة النطاق: DEV وTEST وPROD
• اشترط الموافقات على PROD، وقيّد من يمكنه قراءة تلك الأسرار
• لا تعِد استخدام الأسرار عبر البيئات، وسمِّها ببادئة البيئة (مثل PROD_DATAVERSE_URL)

الأسرار ومبادئ الخدمة والموصلات

مبادئ الخدمة

• تسجيل تطبيق واحد لكل مستأجر؛ ومبدأ خدمة واحد لكل بيئة (بأقل قدر من الصلاحيات).
• امنح أدوار Dataverse بما يناسب مهام ALM، وخزّن معرّف العميل والسر لكل بيئة كأسرار في GitHub.
• قم بتدوير الأسرار بشكل دوري، وفضّل استخدام بيانات الاعتماد الاتحادية (federated credentials) متى كانت متاحة.

متغيرات البيئة

• خزّن نقاط النهاية وأسماء الجداول وأعلام الميزات، ولا تُضمّنها أبدًا في الكود بشكل ثابت.
• احتفظ بالملف /config/{env}/envvars.json؛ ويقوم خط الأنابيب بحقنه عند الاستيراد.

مراجع الاتصالات

• احتفظ بالملف /config/{env}/connections.json الذي يربط مراجع الحل بالموصلات المستهدفة.
• تحقّق من وجود المراجع والتزامها بسياسة DLP قبل الاستيراد، وأوقف العملية فورًا إذا تعذّر حل أي مرجع.

ضوابط حماية تمنع الأعطال «الصامتة»

• بوابة Solution Checker (تمنع النشر عند وجود مشكلات بخطورة عالية أو حرجة).
• فحص الاعتماديات: تأكد من تضمين التدفقات الفرعية ومكونات PCF والمراجع ضمن الحل.
• تدقيق الإعدادات: تأكد من أن لكل متغير بيئة مطلوب قيمةً في البيئة المستهدفة.
• فحص DLP ومصادر البيانات: امنع الموصلات الشخصية أو غير المعتمدة، وطبّق قوائم السماح.
• انحراف المخطط (Schema drift): قارن تغييرات Dataverse، واشترط الحصول على موافقة للفروقات المدمّرة.

الاسترجاع والمراقبة

الاسترجاع (Rollback)

• انشر دائمًا الملف managed.zip السابق كأداة أثر (artifact)، وأعد استيراده عند الفشل.
• للمشكلات الخطيرة، استعد نسخة احتياطية للبيئة (لقطة Dataverse).
• مارِس عمليات الاسترجاع في بيئة معزولة (sandbox)، ووثّق الأوقات والمسؤولين عن كل خطوة.

المراقبة (Observability)

• سجّل مخرجات كل خطوة (تقرير Solution Checker، وملخص الربط، ونتيجة الاستيراد).
• أرسل علامات النشر (معرّفات التشغيل وإصدارات الحل) إلى جدول تدقيق أو لوحة متابعة.
• تتبّع مؤشرات الأداء الرئيسية: معدل فشل التغييرات، ومتوسط زمن الاستعادة (MTTR)، ونسبة الإخفاقات التي أُوقفت قبل النشر.

مخطط مرجعي لسير العمل (بصيغة YAML مبسّطة)

• on: طلب دمج (PR) إلى main ← بناء والتحقق؛ workflow_dispatch يدويًا ← نشر.
• jobs.build: سحب المستودع (checkout) ← pac unpack/pack ← Solution Checker ← نشر المخرجات (artifacts)
• jobs.prepare-env: تنزيل الأدوات ← تحميل /config/${{ env }} ← التحقق من الربط
• jobs.deploy: استخدام الأسرار المحددة بنطاق البيئة ← pac auth (SP) ← استيراد managed ← تطبيق الربط ← اختبارات الدخان (smoke tests)

أخطاء شائعة وحلول سريعة

• يعمل في بيئة التطوير ويفشل في بيئة الاختبار ← غياب ربط مرجع الاتصال
  • الحل: أضف /config/{env}/connections.json، وستمنع خطوة التحقق المتابعة إذا بقي أي مرجع غير محلول.
• نقطة نهاية خاطئة في بيئة الإنتاج ← لم يتم تبديل متغيرات البيئة
  • الحل: اربطها عند الاستيراد، وامنع نقاط النهاية المدرجة بشكل ثابت عبر سكربت فحص (linter).
• مشكلات التدقيق ← استُخدم حساب بشري لعملية النشر
  • الحل: انتقل إلى كيانات الخدمة (SPs)، وقيّد أسرار البيئة بموافقات.
• انحراف الفك والتجميع (Unpack/pack drift) ← التزم بالملفات المفكوكة فقط، وأعد بناء الحل المُدار في CI.
• عمليات الاستيراد الجزئية ← استخدم خيار "Stage for upgrade" والاسترجاع التلقائي إلى آخر أداة عند الفشل.

قائمة مراجعة للبدء السريع (هذا الأسبوع)

• أنشئ كيانات الخدمة وبيئات GitHub (DEV/TEST/PROD) مع أسرار محددة النطاق.
• فكّك الحل إلى Git، وأضف Solution Checker إلى طلبات الدمج (PRs).
• أضف قوالب /config/{env}/envvars.json وconnections.json.
• مهمة البناء: التجميع ← التحقق ← نشر managed.zip
• مهام النشر: الاستيراد باستخدام كيان الخدمة، وإعادة ربط المتغيرات والمراجع، والاختبار السريع، وموافقات لبيئة الإنتاج.
• احفظ managed.zip السابق كأداة استرجاع، واختبر عملية استرجاع في بيئة معزولة.

الخاتمة

إتقان ALM في Power Platform ليس بالأمر الهيّن، لكن الانتقال من عمليات التصدير اليدوية المعرّضة للأخطاء إلى خطوط CI/CD آلية يغيّر كل شيء. فمن خلال اعتماد التحكم بالمصدر للملفات المفكوكة، والحوكمة الصارمة لكيانات الخدمة، والربط الآلي للإعدادات، يمكنك التحكم الكامل في دورة حياة تطبيقاتك من التطوير وصولًا إلى الإنتاج. وللاستزادة من الرؤى والنصائح والتحليلات المعمارية حول أتمتة منظومة Microsoft، استمع إلى النقاش الكامل في الحلقة Set Up Power Platform ALM with GitHub Actions. نتمنى لكم نشرًا موفقًا!