إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
قبل إنشاء الحلول، خذ بعض الوقت للتخطيط مسبقا لاستراتيجية البيئة واستراتيجية الحل الخاصة بك. ضع في اعتبارك الجوانب التالية:
| Aspect | Consideration |
|---|---|
| نطَاق التطبيق | هل يمتد تطبيقك على تطبيقات متعددة مثل المبيعات وخدمة العملاء والخدمة الميدانية والمالية وما إلى ذلك؟ |
| وتيرة الإصدار | ما مدى تكرار التخطيط لنشر التحديثات للإنتاج؟ هل تستند منهجية التسليم الخاصة بك إلى ممارسات مرنة مثل دورات السبرينت؟ |
| دعم الإنتاج | كيف يمكنك التعامل مع الإصلاحات العاجلة في الإنتاج دون إدخال ميزات جديدة قبل الأوان؟ |
| بنية الحل | كم عدد الحلول التي تديرها؟ هل تشترك هذه الحلول في المكونات أو تعتمد على بعضها البعض؟ |
| تخطيط البيئة | كم عدد بيئات Microsoft Dataverse التي تحتاجها لدعم دورة حياة التطوير؟ هل تحتاج إلى بيئات منفصلة للتطوير والاختبار والإنتاج؟ هل يعمل المطورون بشكل تعاوني في بيئة مشتركة، أم أنهم يحتاجون إلى بيئات معزولة للعمل بشكل مستقل؟ |
توضح الأقسام التالية ثلاث استراتيجيات، مرتبة من أبسط إلى أكثرها تعقيدا، وتسلط الضوء على مزاياها وعيوبها.
استراتيجية حل واحد
يتم تجميع جميع التخصيصات في حل واحد غير مدار أثناء عملية التطوير، ثم يتم تصديره لاحقاً كحل مدار واحد لمرحلة النشر.
يوصى به من أجل:
- تطبيقات صغيرة متوسطة الحجم
- السيناريوهات التي يكون فيها التوحيد المعياري في المستقبل غير محتمل
| الميزة | العيب |
|---|---|
| إدارة وإعداد البيئة بشكل مبسط. | يتطلب المزيد من الجهد لتوسيع النطاق أو التحجيم في وقت لاحق إذا لزم الأمر. |
| توزيع مبسط. مع حل واحد فقط لإدارة عملية التصدير والاستيراد عبر مختلف البيئات، تصبح العملية واضحة وأقل عرضة للخطأ. | قد يؤدي حل واحد يحتوي على عدد كبير من التخصيصات إلى أوقات توزيع أطول. لتقليل حجم الحل، استخدم تجزئة الجدول. لتقليل أوقات الاستيراد، انتقل إلى توصيات الأداء. |
| يسهل تحديد موقع التغييرات والتدقيق فيها وإدارتها. | عندما يعمل العديد من المطورين في نفس بيئة التطوير، فإنهم يخاطرون الكتابة فوق تغييرات بعضهم البعض. يمكن تقليل هذا الخطر من خلال تنفيذ إصدار التعليمات البرمجية المصدر، واعتماد استراتيجية تفريع، واستخدام بيئة تطوير مخصصة لكل فرع. توفر استراتيجية إصدار التعليمات البرمجية المصدر والتفريع تعقب التغييرات ودعم التعاون وآليات حل التعارض. مزيد من المعلومات: اعتماد استراتيجية تفريع Git. |
ملاحظة
أدت التحسينات الأخيرة في Microsoft Power Platform إلى تقليل أوقات الاستيراد للحلول المدارة، بما في ذلك الحلول التي تستخدم خيار الترقية. تتضمن هذه التحسينات معالجة أفضل لتبعيات المكونات وتقليل الحمل للمكونات التي لم تتغير. لمعرفة كيفية الاستفادة من هذه التحسينات، انتقل إلى توصيات الأداء.
حلول متعددة في نفس بيئة التطوير
يتم الحفاظ على حلول متعددة غير مدارة داخل بيئة تطوير واحدة، كل منها مخصص عادة للميزات أو الوحدات غير المرتبطة.
يوصى به من أجل:
- تطبيقات صغيرة متوسطة الحجم مع مجالات وظيفية متميزة ومستقلة لا تشترك في المكونات.
| الميزة | العيب |
|---|---|
| إعداد البيئة المبسطة وإدارتها. | يؤدي الحفاظ على حلول متعددة غير مدارة داخل نفس بيئة التطوير إلى زيادة احتمال تعارضات التبعية. على سبيل المثال، قد تواجه حالة لا يمكن فيها استيراد الحل أ لأنه يعتمد على الحل B، بينما لا يمكن استيراد الحل B لأنه يعتمد على الحل أ. |
| يمكن توزيع المناطق الوظيفية بشكل مستقل عن بعضها البعض. | قد يقوم العديد من المطورين الذين يعملون في نفس بيئة التطوير بالكتابة فوق تغييرات بعضهم البعض. لا يوفر العمل في حل غير مدار عزلا. يتم تطبيق كل تعديل مباشرة على البيئة، بغض النظر عن الحل الذي يتم تحريره. |
ملاحظة
عندما يكون لديك حلول متعددة في نفس بيئة التطوير، بعد استيراد الحلول المدارة إلى البيئة المستهدفة، فإنك غالبا ما تقوم بإنشاء طبقات. مزيد من المعلومات: طبقات الحل وسلوك الدمج
من المهم أن تقوم ب:
- لا تقم بتضمين نفس المكون غير المدار في أكثر من حل واحد.
- لديك حل واحد فقط يتضمن جميع الجداول الخاصة بك. ليس لديك حلان مختلفان حيث يحتوي كلاهما على جداول. وهذا بسبب وجود مخاطر وجود علاقة واحدة بين الجداول بشكل متكرر، مما يؤدي إلى إنشاء تبعية عبر الحلول والتسبب في ترقية الحل أو حذف المشكلات في البيئة الهدف في وقت لاحق.
- استخدم ناشر حلول واحد فقط. يمتلك ناشر الحل مكونات الحل المدار ولا يمكن تغيير اقترانه لاحقا. على سبيل المثال، إذا تم استيراد جدول مخصص كما هو مدار من خلال الحل A مع Publisher X، فلا يمكنك نقل هذا الجدول لاحقا إلى الحل B مع Publisher Y. الخيار الوحيد هو حذف الجدول وترقية الحل أ لإزالة الجدول من النظام الهدف، ثم إعادة إنشاء الجدول في الحل B باستخدام Publisher Y واستيراد الحل B. تؤدي هذه العملية إلى فقدان جميع البيانات المخزنة في الجدول المخصص ما لم يتم ترحيلها مسبقا.
- تجنب إنشاء تبعيات بين الحلول. تفرض التبعيات أمر استيراد ويمكن أن تسبب مشكلات. على سبيل المثال، إذا كان لديك حل واحد للجداول وآخر للتدفقات السحابية، ويعتمد التدفق على عمود مخصص، فإنه يعمل في التطوير لأن العمود موجود. ومع ذلك، إذا تم استيراد حل تدفق السحابة فقط إلى البيئة المستهدفة، فقد لا تتعرف عملية الاستيراد على التبعية على العمود المخصص. ونتيجة لذلك، يتم تثبيت حل التدفق بنجاح، ولكن التدفق نفسه لا يعمل. مزيد من المعلومات: أمثلة على التبعيات التي تم إنشاؤها بواسطة حلول متعددة
أمثلة على التبعيات التي تم إنشاؤها بواسطة حلول متعددة
- أشرطة التطبيق. عندما تقوم حلول متعددة بتعديل شريط التطبيق أو خريطة الموقع لنفس التطبيق.
- المكونات الإضافية أو تدفقات السحابة. إذا تم تشغيل المكون الإضافي أو التدفق على عمود مخصص أو تحديث جدول مخصص، يعتمد الكائن على تلك الجداول المخصصة.
- أدوار الأمان. عند وجود جداول مخصصة، تعتمد أدوار الأمان عادة على تلك الجداول لوصول المستخدم.
حلول متعددة مع بيئات تطوير مخصصة
تتضمن هذه الاستراتيجية تطوير كل حل غير مدار في بيئة تطوير Dataverse المعزولة الخاصة به. تستخدم هذه الاستراتيجية بشكل شائع في البنى النمطية حيث، على سبيل المثال، يتم إنشاء تطبيقات مختلفة - مثل المبيعات أو خدمة العملاء أو الخدمة الميدانية - وصيانتها بشكل مستقل. يتم إنشاء حل أساسي يحتوي على مكونات شائعة (على سبيل المثال، جداول الحساب والاتصال) ونشره كحل مدار في كل بيئة تطوير خاصة بالتطبيق. ثم يكون لكل تطبيق حله غير المدار الخاص به، على مستوى أعلى الحل المدار الأساسي، ما يسمح للفرق بتوسيع الوظائف دون تغيير الأساس الأساسي.
يوصى به من أجل:
- مشاريع المؤسسة واسعة النطاق.
- الفرق مع العديد من المطورين أو الشركاء
- السيناريوهات التي تتطلب حوكمة صارمة وتدفقات CI/CD.
| الميزة | العيب |
|---|---|
| أسهل في النمو وتطوير النظام الخاص بك عن طريق إضافة أو تحديث الوحدات دون التأثير على الآخرين. | ارتفاع عبء البنية التحتية والصيانة. |
| يمكن لفرق متعددة العمل بالتوازي على وحدات نمطية مختلفة دون تعارض مع تغييرات بعضها البعض. | يتطلب استراتيجية بيئة قوية وحوكمة. |
| أسهل في تنفيذ الاختبار التلقائي وممارسات DevOps. | توزيع أكثر تعقيدا. |
| تعد الحلول الأصغر أسرع في النشر، خاصة في مسارات CI/CD إذا كان عليك نشر تطبيق معين فقط. | |
| يسهل تتبع الأخطاء أو التراجعات عند عزل التغييرات إلى وحدات نمطية معينة. |
كيفية إنشاء طبقات الحل
ملاحظة
قبل إنشاء الحلول في الخطوات التالية، استخدم نفس الناشر لجميع الحلول الخاصة بك عبر بيئاتك. مزيد من المعلومات: ناشر الحلول.
- في بيئة التطوير "الأساسية"، لديك الحل الأساسي الخاص بك مع الجداول الشائعة غير المدارة ولا توجد جداول أخرى. بعد ذلك قم بتصدير هذا الحل كمدار.
- يمكنك إعداد بيئة تطوير ثانية لطبقة الملحق أو "التطبيق" التي ستقام لاحقا أعلى الطبقة الأساسية.
- يمكنك استيراد الطبقة الأساسية المدارة إلى بيئة تطوير طبقة التطبيق وإنشاء حل غير مدار لطبقة التطبيق.
- يمكنك الآن توسيع نموذج البيانات عن طريق إضافة جداول وأعمدة وعلاقات جداول ووظائف إضافية وتدفقات وما إلى ذلك، إلى حل "التطبيق" المحدد. بعد ذلك، قم بتصدير حل التطبيق كما هو مُدار. لاحظ أن حل التطبيق لا يزال يعتمد على حل الطبقة الأساسية، ولكن إدارة حلول متعددة بهذه الطريقة هي نهج أفضل. ضع في اعتبارك المثال المذكور قبل التدفق الذي يعتمد على عمود مخصص. في معظم الحالات، يوجد كل من العمود المخصص والتدفق في نفس حل التطبيق. ولكن حتى إذا كان العمود المخصص جزءا من الحل الأساسي، يجب إكمال ونشر هذا الحل الأساسي كما تتم إدارته أولا، وإلا، لا يمكن حتى إنشاء التدفق داخل حل التطبيق.
- في بيئة الإنتاج، قم باستيراد الطبقة الأساسية المدارة ثم قم باستيراد طبقة التطبيق المدارة. يؤدي هذا إلى إنشاء طبقتين مدارتين في البيئة مع تبعيات واضحة بين الحلول المدارة.
- كرر هذا النمط للحصول على العديد من الحلول المختلفة التي تحتاج إلى صيانتها. على الرغم من أننا نوصي بأن تحتفظ بعدد الحلول أصغر ما يمكن للحفاظ على إمكانية إدارة طبقات الحل الخاصة بك.