WEBVTT

00:00:00.000 --> 00:00:05.240
هل أنت مستعد لعشرة أيام من مايكروسوفت 365 وكوبايلوت والذكاء الاصطناعي وأشر

00:00:05.240 --> 00:00:07.560
ولقاء الأشخاص الذين يشكلون مستقبل العمل

00:00:07.560 --> 00:00:12.260
في يناير القادم يعود مؤتمر M365 كون بحجم أكبر

00:00:12.260 --> 00:00:15.000
انضم إلينا في جلسات مباشرة وعروض توضيحية واقعية

00:00:15.000 --> 00:00:18.300
ومعرفة عملية يقدمها خبراء مايكروسوفت وأبرز المتخصصين حول العالم

00:00:18.300 --> 00:00:19.960
لا شرائح عرض تقليدية

00:00:19.960 --> 00:00:22.220
لا مصطلحات رنانة لا تنتهي

00:00:22.220 --> 00:00:23.920
نحن نعالج تحديات حقيقية

00:00:23.920 --> 00:00:33.300
سواء كنت متخصص تقنية معلومات أو مطورا أو قائدا للأعمال

00:00:33.300 --> 00:00:35.200
هناك جلسات مصممة خصيصا لك

00:00:35.200 --> 00:00:40.460
مع عشر أيام كاملة يمكنك استكشاف تقنيات متعددة والتواصل مع مجتمع عالميا

00:00:40.460 --> 00:00:44.700
شاهد الجلسات مباشرة واكتسب رؤى عملية لتطبيقها في مؤسستك

00:00:44.700 --> 00:00:49.380
يناير 2027 عشرة أيام ومجتمع مايكروسوفت واحد

00:00:49.380 --> 00:00:51.420
باب التسجيل مفتوح الآن

00:00:51.420 --> 00:00:54.520
أحجز مكانك اليوم

00:00:54.520 --> 00:00:59.360
الموقع هو m365.net

00:00:59.360 --> 00:01:02.440
انضم الآن عبر m365.net

00:01:02.440 --> 00:01:04.680
ونراكم في البث المباشر في يناير

00:01:04.680 --> 00:01:08.400
هل تشعر أحياناً أن عمليات نشر Power Platform هي صندوق أسود غامض

00:01:08.400 --> 00:01:10.380
هل ترسل تحديثاً وتنتظر بقلق

00:01:10.380 --> 00:01:13.700
وتأمل فقط أن يعمل عبر بيئات التطوير والاختبار والإنتاج

00:01:13.700 --> 00:01:17.880
ماذا لو كان بإمكانك التحكم ورؤية كل مرحلة من عملية أوم

00:01:17.880 --> 00:01:20.940
باستخدام GitHub Actions دون تخمين أو عمل يدوي

00:01:20.940 --> 00:01:25.160
دعونا نكشف الستارة عن كيفية ترابط المكونات والتحكم في المصدر

00:01:25.160 --> 00:01:28.080
والأتمتة والمتغيرات الآمنة بشكل فعلي

00:01:28.080 --> 00:01:30.400
هذا ليس مجرد شرح تقليدي آخر

00:01:30.400 --> 00:01:32.680
هذا هو السبب الذي تغفله معظم الأدلة

00:01:32.680 --> 00:01:34.840
حتى لا تضطر للتخمين في عملية النشر القادمة

00:01:34.840 --> 00:01:38.880
إذن لماذا تبدو إدارة دورة حياة التطبيقات أوم في Power Platform كالمتاهة؟

00:01:38.880 --> 00:01:42.160
إذا حاولت يوما نشر تطبيق Power App وشعرتي بعدم اليقين

00:01:42.160 --> 00:01:45.820
وكأن شيئا مهما قد سقط سهونا فأنت لست وحدك

00:01:45.820 --> 00:01:48.980
نظريا تعد Power Platform بتطوير سهل للتطبيقات

00:01:48.980 --> 00:01:50.880
ولكن خلف هذه الواجهة الودية

00:01:50.880 --> 00:01:53.100
عملية أوم ليست مباشرة على الإطلاق

00:01:53.100 --> 00:01:55.840
يتم نشر تطبيقات الويب من نظام التحكم في المصدر

00:01:55.840 --> 00:01:59.820
وتبنى في خط أنبيب وتستقر في بيئة الإنتاج بسلوك متوقع

00:01:59.820 --> 00:02:04.100
أما Power Platform فهي تخفي نصف المنطق داخل واجهات السحب والإفلات

00:02:04.100 --> 00:02:08.320
وشاشات الموصلات وصيغة لا يمكنك رؤيتها في أي مستودع جد

00:02:08.320 --> 00:02:11.880
لذا حتى لو اتبعت كل خطوة في أدلة الإدارة عالية المستوى

00:02:11.880 --> 00:02:16.980
ستظل تواجه أعطالا غريبة يصعب تشخيصها بمجرد خروج التطبيقات الهامة عن بيئة التطوير

00:02:16.980 --> 00:02:19.700
لنلقي نظرة على أدلة أوم المنتشرة حاليا

00:02:19.700 --> 00:02:23.540
معظمها يواجهك لتصدير ملف حل مضغوط زب واستيراده في مكان آخر

00:02:23.540 --> 00:02:27.940
الأمر بسيط أليس كذلك لكن كيفية القيام بذلك هي مجرد طبقة واحدة

00:02:27.940 --> 00:02:29.900
ما تتجهله تلك الأدلة هو السبب

00:02:29.900 --> 00:02:33.640
لماذا تتعطل عمليات نشر Power Platform بطرق لا تحدث أبدا مع الكود البرمجي العادي

00:02:33.640 --> 00:02:36.100
هذا هو ما يسبب حالة من الارتباك المستمر

00:02:36.100 --> 00:02:41.820
جذر المشكلة هو أن المنطقة والاتصالات والإعدادات في Power Apps لا تخزن مثل الكود البرمجي التقليدي

00:02:41.820 --> 00:02:45.640
أنت لا تقوم فقط بنسخ مستودع برمجيات ومراقبة اختبارات الوحدة

00:02:45.640 --> 00:02:54.060
لذا عند محاولة نقل تطبيقك فإن كل تلك التبعيات المخفية والاتصالات بأوتلوك والشيربوينت وواجهات برمجة التطبيقات المخصصة لا تنتقل دائما بسلاسة داخل ملف

00:02:54.060 --> 00:02:55.380
إليك السيناريو

00:02:55.380 --> 00:02:58.140
لديك تطبيق جديد ومميز يعمل في بيئة التطوير

00:02:58.140 --> 00:03:01.880
تقوم بتصدير الحل واستيراده للاختبار وفجأة يتوقف التدفق عن العمل

00:03:01.880 --> 00:03:03.900
نادرا ما تكون المشكلة مجرد ملف

00:03:03.900 --> 00:03:11.720
بدلا من ذلك تشير الاتصالات إلى المكان الخطأ ولا تتوافق الأذونات وتحضر سياسات البيانات اتصالات بدأت جيدة قبل دقائق

00:03:11.720 --> 00:03:21.320
الآن تخيل القيام بذلك عبر ثلاث بيئات التطوير والاختبار والإنتاج حيث تستخدم كل منها اتصالات مختلفة وسياسات حماية بيانات وموافقين وحواجز إدارية

00:03:21.320 --> 00:03:24.220
لا يمكنك حل هذه المشكلة عن طريق النسخ واللسق

00:03:24.220 --> 00:03:27.520
الأبحاث تدعم ما يراه المسؤولون والمطورون كل أسبوع

00:03:27.520 --> 00:03:34.160
غالبية عمليات النشر الفاشلة في Power Platform تنجم عن فقدان مراجع الموصلات أو سوء إدارة متغيرات البيئة

00:03:34.160 --> 00:03:40.200
فقدان مرجع الموصل يعني ببساطة أن التدفق لا يمكنه العثور على اتصال Outlook أو Dataverse الخاص به

00:03:40.200 --> 00:03:46.840
لذا في اللحظة التي تحاول فيها تشغيل تطبيقك أو تدفقك في بيئة أخرى تحصل على أخطاء وقت التشغيل

00:03:46.840 --> 00:03:52.940
ولأن متغيرات البيئة تعمل بشكل مختلف في Power Platform مقارنة بمنتجات Microsoft 365 الأخرى

00:03:52.940 --> 00:03:55.180
فإنها توقع حتى المطورين ذوي الخبرة في أخطاء

00:03:55.180 --> 00:04:00.000
من المفترض أن تتعامل المتغيرات مع نقاط النهاية أو المفاتيح أو تكونات خاصة بالمستأجر

00:04:00.000 --> 00:04:06.420
ولكن إذا نسي شخص ما تحديثها بعد تصدير الحل فقد يؤدي تغيير يبدو غير ضر إلى كسر تطبيق مباشر

00:04:06.420 --> 00:04:09.120
كثيرون منا يقعون في نفس الفخ في البداية

00:04:09.120 --> 00:04:11.900
قد تعتقد أن تصدير ملف زقل الحل يجمع كل ما يلزم

00:04:11.900 --> 00:04:14.720
لكنه في الواقع يتجاهل مراجع الموصلات الديناميكية

00:04:14.720 --> 00:04:19.720
على سبيل المثال لنقل أن لديك تطبيق يستخدم موصل HTTP لخدمة خارجية في بيئة التطوير

00:04:19.720 --> 00:04:22.180
عند الاستيراد إلى بيئة الاختبار أو الإنتاج

00:04:22.180 --> 00:04:24.000
لن توجد نسخة الموصل تلك

00:04:24.000 --> 00:04:27.120
يشير مرجع الموصل داخل تطبيقك إلى كائن مفقود

00:04:27.120 --> 00:04:34.660
وتتوقف التدفقات داخل الحل بصمت حتى يقوم مستخدم أو مسؤول بإعادة إنشاء الاتصالات وإعادة تعيينها يدويا

00:04:34.660 --> 00:04:36.780
إذا كان لديك أكثر من مطور أو مسؤول

00:04:36.780 --> 00:04:39.620
فمن السهل فقدان تتبع أي مرجع يذهب إلى أين

00:04:39.620 --> 00:04:44.020
ولا أحد يريد مراجعة ما بعد الحادث لتبرير أنه كان يعمل في بيئة التطوير

00:04:44.020 --> 00:04:45.020
تعقيد آخر

00:04:45.020 --> 00:04:46.220
مدير الخدمة

00:04:46.220 --> 00:04:53.300
يبدأ معظم الأشخاص باستخدام حسابات المستخدمين لتصدير واستيراد الحلول لأنها أسرع في البدء

00:04:53.300 --> 00:04:56.840
ولكن عند محاولة الأتمتة باستخدام إجراءات بذهب أو أي نظام تكامل مستمر

00:04:56.840 --> 00:04:59.900
فإن استخدام بيانات اعتماد شخص ما يؤدي بسرعة إلى طريق مسدود

00:04:59.900 --> 00:05:03.540
ستصطدم بجدان الأذونات أحيانا بدون رسائل خطأ واضحة

00:05:03.540 --> 00:05:10.220
أو قد تثير عمليات تدقيق الامتثال لأنك تشغل عمليات نشر حيوية تحت حساب شخصي بدلا من حساب مخصص للأتمتة

00:05:10.220 --> 00:05:11.320
تتولى كيانات الخدمة

00:05:11.320 --> 00:05:14.900
وهي في الأساس هويات تطبيقات يتم إنشاؤها في أشر أيدي

00:05:14.900 --> 00:05:18.940
إدارة كافة الأذونات والسجلات وعمليات التدقيق التي يحتاجها مسار العمل الخاص بك

00:05:18.940 --> 00:05:23.320
بدونها تتحول سلسلة الأتمتة لديك إلى مجموعة متفرقة من عمليات التسليم بين الأفراد

00:05:23.320 --> 00:05:25.280
ولن تعرف أبدا من قام بتغيير ماذا

00:05:25.280 --> 00:05:27.940
يتحول التحكم في المصدر أيضا إلى أمر غير متوقع

00:05:27.940 --> 00:05:30.440
مع التعليمات البرمجية العادية لديك سجلات الالتزام

00:05:30.440 --> 00:05:32.400
كوميت هستوريز وأدوات تتبع التغييرات

00:05:32.400 --> 00:05:34.920
تمثل ملفات خلول باور بلاتفورم لقطات فقط

00:05:34.920 --> 00:05:37.320
مما يعني أنك تفتقد تتبع التغييرات الدقيقي

00:05:37.320 --> 00:05:39.560
المنطق المخفي في صياغ شاشات تطبيقات كنفس

00:05:39.560 --> 00:05:44.100
أو في التدفقات فلوز الموثقة بشكل بسيط لا يظهر إلا عند التصدير مجددا

00:05:44.100 --> 00:05:46.760
إذا قام شخص ما بتعديل أعداد تدفق في واجهة المستخدم

00:05:46.760 --> 00:05:49.940
فمن الصعب معرفة سبب تصرف البيئات اللاحقة بشكل مختلف فجأة

00:05:49.940 --> 00:05:52.500
النتيجة النهائية هي أن إدارة دورة حياة التطبيق

00:05:52.500 --> 00:05:55.700
تبدو كحل لغز ينقصه نصف القطع

00:05:55.700 --> 00:05:57.460
أو على الأقل مخفية تحت الصندوق

00:05:57.460 --> 00:06:00.820
الاعتمادات غير المرئية والموصلات الخاصة بالبيئة

00:06:00.820 --> 00:06:03.680
والمتغيرات التي لا يمكنك رؤيتها في الكودي

00:06:03.680 --> 00:06:06.060
كلها تعيق سير عمل المطور المعتاد

00:06:06.060 --> 00:06:08.660
وهذا قبل التعامل مع حقيقة أن بيئات الإنتاج

00:06:08.660 --> 00:06:11.140
تحتوي دائما تقريبا على أذونات أكثر صرامة

00:06:11.140 --> 00:06:12.980
وسياسات بيانات مختلفة

00:06:12.980 --> 00:06:16.480
ومتطلبات تدقيق غير واضحة في بيئات التطوير أو الاختبار

00:06:16.480 --> 00:06:18.420
لكن إليك الجانب الإيجابي

00:06:18.420 --> 00:06:20.420
هذا التعقيد ليس عشوائيا

00:06:20.420 --> 00:06:23.360
هناك سبب عملي لتعامل باور بلاتفورم

00:06:23.360 --> 00:06:27.020
مع المصدر والمتغيرات والموصلات بهذه الطريقة الفريدة

00:06:27.020 --> 00:06:29.240
إنها تسعى للسماح لمستخدم الأعمال

00:06:29.240 --> 00:06:32.160
ببناء تطبيقات قوية دون القلق بشأن البرمجة

00:06:32.160 --> 00:06:36.840
النتيجة الجانبية هي أنه يتعين عليك بصفتك الشخص الذي يقوم بأعداد الأتمتة

00:06:36.840 --> 00:06:38.700
تتبع ما يختبئ خلف الكواليس

00:06:38.700 --> 00:06:41.040
إذا عرفت مسار تلك الأسلاك غير المرئية

00:06:41.040 --> 00:06:46.440
يمكنك إصلاح أو تجنب معظم الأخطاء الفادحة التي تعرقل إدارة أوم في باور بلاتفورم

00:06:46.440 --> 00:06:50.100
الآن إذا كان كل هذا يبدو كعبء كبير فأنت لست مخطئا

00:06:50.100 --> 00:06:53.700
لكن هناك أربع ركائز لإدارة أوم تساعد بالفعل في فك هذا التشابك

00:06:53.700 --> 00:06:56.260
المصدر والبناء والاختبار والنشر

00:06:56.260 --> 00:06:58.620
لكل منها سماتها الخاصة في باور بلاتفورم

00:06:58.620 --> 00:07:01.800
لكنها معاً تعيد الهيكلة لما يبدو خلاف ذلك فوضى عارمة

00:07:01.800 --> 00:07:03.120
نظام أوم الأساسي

00:07:03.120 --> 00:07:05.680
المصدر والبناء والاختبار والنشر

00:07:05.680 --> 00:07:09.560
في كل مرة يطلب فيها أحدهم مسار عمل لام باور بلاتفورم يعمل بسلاسة

00:07:09.560 --> 00:07:12.720
فإن أول ما يتبادر إلى الذهن هو تلك الركائز الأربع لام أوم

00:07:12.720 --> 00:07:15.160
المصدر والبناء والاختبار والنشر

00:07:15.160 --> 00:07:18.820
في عالم التطوير التقليدي يمكنك القيام بهذه المهام وأنت مغمض العينين

00:07:18.820 --> 00:07:21.360
لكن باور بلاتفورم لا تمنحك هذه السهولة

00:07:21.360 --> 00:07:24.400
فجأة لم يعد المصدر يعني الكود البرمجي

00:07:24.400 --> 00:07:26.360
بل يعني التعامل مع ملفات الحلول

00:07:26.360 --> 00:07:29.720
وتصدير حزم مضغوطة مليئة بالتطبيقات والتدفقات

00:07:29.720 --> 00:07:33.140
وأحياناً المواصلات التي تتظاهر بأنها جزء من المصدر

00:07:33.140 --> 00:07:34.220
لنبدأ بالأساسيات

00:07:34.220 --> 00:07:38.060
ثم نحلل ما يجعل كل ركيزة تبدو غريبة بعض الشيء في هذا العالم

00:07:38.060 --> 00:07:40.240
لديك ملف الحل المضغوط الخاص بك

00:07:40.240 --> 00:07:42.120
إنه ليس كوداً بالمعنى المعتادي

00:07:42.120 --> 00:07:45.500
افتح الملفة وستجد أمامك ملفات شرح بصغتي XML وجيسن

00:07:45.500 --> 00:07:48.300
وليس المنطق البرمجي الذي قد تراه في TypeScript أو C-H

00:07:48.300 --> 00:07:50.960
لكن هذا هو المصدر الخاص باور بلاتفورم

00:07:50.960 --> 00:07:53.120
غالباً ما تتعثر الفرق في هذه النقطة

00:07:53.120 --> 00:07:55.620
يبدو الأمر قابلاً للنقل حتى تلك أن معظم التغييرات

00:07:55.620 --> 00:07:58.500
مثل تحديث معادلة في شاشة أو تعديل منطق تدفق العمل

00:07:58.500 --> 00:08:02.320
لا تظهر بوضوح إلا بعد تصدير ملف حل سولوشن جديد بصغتي زب

00:08:02.320 --> 00:08:05.160
لذا نعم يمكنك إدارة إصدارات ملفات الحل هذه في جت

00:08:05.160 --> 00:08:07.980
ولكن ما لم تكن منضبطاً بشأن التصدير بعد كل تعديل مهم

00:08:07.980 --> 00:08:10.360
فسيحتوي تاريخ إصداراتك على فجوات واضحة

00:08:10.360 --> 00:08:12.100
الآن ننتقل إلى التكوين

00:08:12.100 --> 00:08:13.720
بالنسبة للتطبيقات العادية

00:08:13.720 --> 00:08:17.120
قد تخزن سلاسل الاتصال في ملف أعدادات وتنتهي المهمة

00:08:17.120 --> 00:08:21.360
أما باور بلاتفورم فيقوم بتهريب بيانات خاصة بالبيئة داخل هذه الحلول

00:08:21.360 --> 00:08:23.420
الأمر لا يقتصر على متغيرات البيئة

00:08:23.420 --> 00:08:27.300
بل يشمل مراجع الموصلات ونقاط النهاية الديناميكية والأدوار

00:08:27.300 --> 00:08:29.500
والأذنات المجمعة بجانب منطق العمل

00:08:35.160 --> 00:08:36.300
إلى أماكن خاطئة

00:08:36.300 --> 00:08:39.620
لقد رأيت فرقاً تلتزم بدقة برفع ملفات الحلول بصيغة زب

00:08:39.620 --> 00:08:41.520
لتكتشف بعد النشر أن نصف تطبيقاتهم

00:08:41.520 --> 00:08:43.360
لا تزال تتصل بقاعدة بيانات التطوير

00:08:43.360 --> 00:08:45.220
ديتا فيرس بدلاً من بيئة الإنتاج

00:08:45.220 --> 00:08:47.620
لأن أحداً لم يقم بإعادة تعيين مراجع الموصلات

00:08:47.620 --> 00:08:49.440
ثم نأتي إلى مرحلة البناء

00:08:49.440 --> 00:08:52.760
كلمة بناء تستحضر عادة صور تجميع الأكوادي

00:08:52.760 --> 00:08:55.340
ورؤية علامات الاختيار الخضراء في مهام التكامل المستمر

00:08:55.340 --> 00:08:56.900
مع باور بلاتفورم

00:08:56.900 --> 00:08:59.580
تدور عملية البناء حول تخزين تلك الحزم المضغوطة

00:08:59.580 --> 00:09:02.320
ومراجعة المخططات والتحقق من التبعيات

00:09:02.320 --> 00:09:04.020
في خط أنابيبي جيت هاب أكشونز

00:09:04.020 --> 00:09:06.280
تلتقط مهمة البناء ملف الحل الخاص بك

00:09:06.280 --> 00:09:09.420
ثم تستخدم واجهة سطر أوامر باور بلاتفورم من مايكروسوفت

00:09:09.420 --> 00:09:11.820
لفك ضغط الحل والتحقق منه وإعادة ضغطه

00:09:11.820 --> 00:09:14.720
خطوة التحقق هي حيث يحدث السحر أو الفوضى

00:09:14.720 --> 00:09:17.780
قد تكتشف مراجع معطلة أو إجراءات غير مدعومة

00:09:17.780 --> 00:09:18.780
والأسوأ من ذلك

00:09:18.780 --> 00:09:21.720
إذا كان التغيير في تدفق العمل يعتمد على موصل مخصص

00:09:21.720 --> 00:09:23.500
لم يتم تضمينه في التحكم بالمصادر

00:09:23.500 --> 00:09:26.260
فإن عملية البناء ستحزم بصمت شيئا غير مكتملا

00:09:26.260 --> 00:09:28.200
وهنا تزداد الأمور تعقيدا

00:09:28.200 --> 00:09:31.560
وظائف البناء هذه لا تتعلق بالتجميع بقدر ما تتعلق

00:09:31.560 --> 00:09:35.880
بتنظيم عملية تصدير موثوقة والتأكد من أن ما بداخلها قابل للشحن

00:09:35.880 --> 00:09:38.900
الفرق التي تتجاهل هذا أو تتعجل فيه تجد نفسها بسرعة

00:09:38.900 --> 00:09:40.580
في مواقف ينجح فيها البناء تقنيا

00:09:40.580 --> 00:09:44.300
لكن ما يصل إلى بيئة الاختبار أو الإنتاج يفتقر إلى نصف ميزاته المقصودة

00:09:44.300 --> 00:09:47.700
تواصل مايكروسوفت الترويجة لفكرة أن ملفات الحلول تجعل إدارة دورة حياة التطبيقات

00:09:47.700 --> 00:09:48.840
قابلة للنقل

00:09:48.840 --> 00:09:50.540
ولكن هناك دائما ملاحظة هامشية

00:09:50.540 --> 00:09:54.860
تعتمد القابلية للنقل على تعيين المواصلات بشكل صحيح وإعداد الأدوار عبر البيئات المختلفة

00:09:54.860 --> 00:09:57.160
الاختبار هو الخطوة التالية في قائمة المصادر

00:09:57.160 --> 00:09:58.700
في خط أنبيب تطبيقات الويب

00:09:58.700 --> 00:10:02.140
قد تقوم الاختبارات المؤتمدة بتشغيل اختبارات الوحدات أو فخصات واجهة المستخدم

00:10:02.140 --> 00:10:04.060
أما بالنسبة لام باور بلاتفورم

00:10:04.060 --> 00:10:06.320
فما يعتبر اختبارا لا يزال محل نقاشا

00:10:06.320 --> 00:10:09.180
أحيانا يكون الأمر عبارة عن التحقق من الحل

00:10:09.180 --> 00:10:12.380
أي هل يفتح الحل وهل يتم حل التبعيات الرئيسية

00:10:12.380 --> 00:10:18.300
وفي أحيان أخرى يكون عبارة عن تشغيل تدفقة اختبار أو التأكد من أن المواصلات تستجيب في بيئة الاختبار

00:10:18.300 --> 00:10:23.020
في كثير من الأحيان يكون الاختبار يدويا لأن التحقق من منطق الأعمال داخل تطبيقات كنفس

00:10:23.020 --> 00:10:25.260
لم يتم ربطه بعد بخطوط الانتاج المؤتمدة

00:10:25.260 --> 00:10:28.160
ولكن يمكنك أتمتة عمليات الفحص لاكتشاف المواصلات المفقودة

00:10:28.160 --> 00:10:29.760
أو التحقق من التدفقات الهامة

00:10:29.760 --> 00:10:33.340
أو حتى اختبار بيئة تجربية للتأكد من أن بيانات الاعتماد تعمل بشكل صحيح

00:10:33.340 --> 00:10:35.980
وعملية النشر هي التي تزيد من حدة هذه الصعوبات

00:10:35.980 --> 00:10:40.020
عند نشر تطبيق قياسي قد تكتفي فقط برفع ملفات الويب على منصة أشر

00:10:40.020 --> 00:10:44.200
أما مع Power Platform فعليك تعيين الاتصالات وتحديد الأذونات وتحديث الأسرار

00:10:44.200 --> 00:10:45.520
وتبديل متغيرات البيئة

00:10:45.520 --> 00:10:49.420
وأخيرا بدء الاستيراد باستخدام Service Principal وليس أبدا باستخدام حساب عادي

00:10:49.420 --> 00:10:52.980
وإلا ستواجه الكثير من عمليات التدقيق ورفض الأذونات

00:10:52.980 --> 00:10:55.940
يمكن لام GitHub Actions ربط هذه العملية معا

00:10:55.940 --> 00:11:00.240
ولكن فقط إذا كانت كل مهمة تعرف البيئة المستهدفة والأسرار التي يجب استخدامها

00:11:00.240 --> 00:11:04.980
لقد رأيت فرقا تحاول اختصار هذا المسار باستخدام مجموعة واحدة من بيانات الاعتماد عبر بيئات التطوير والإنتاج

00:11:04.980 --> 00:11:09.960
وهو ما يؤدي حطنا إلى الفوضى وتسريب البيانات وأخطاء الأذونات وتعطل الميزات في بيئة دون أخرى

00:11:09.960 --> 00:11:12.660
لنأخذ مثالا لفريق عمل حقيقي تعاملت معه قبل بضعة أشهر

00:11:12.660 --> 00:11:19.020
كانوا يقومون بمعظم الأمور بشكل صحيح من استخدام مستودعة بيت قياسية وإصدارات مضغوطة للحلول وهيكلية واضحة للفروع

00:11:19.020 --> 00:11:21.260
لكن مسار عملهم كان يتعطل دائما عند مرحلة النشر

00:11:21.260 --> 00:11:26.780
لماذا؟ لأنهم لم يهتموا بتبديل متغيرات البيئة أو تحديث مراجع المواصلات قبل الاستيراد إلى بيئة الإنتاج

00:11:26.780 --> 00:11:31.620
مما جعل تدفقة العمل الأساسية تشير إلى نقاط نهاية خاطئة مع تسرب البيانات إلى أنظمة غير صحيحة

00:11:31.620 --> 00:11:34.460
كان الحل يكمن في إضافة خطوات برمجية في مسار بيتهب

00:11:34.460 --> 00:11:37.760
الخاص بهم تقوم بتبديل المتغيرات وإعادة تعيين كل موصل عند الاستيراد

00:11:37.760 --> 00:11:41.120
توجيهات مايكروسوفت نفسها واضحة وصريحة بشأن هذا الأمر

00:11:41.120 --> 00:11:43.540
استخدم ملفات الحلول لنقل العناصر بين البيئات

00:11:43.540 --> 00:11:48.180
ولكن تعامل دائما مع مراجع المواصلات وتعيين الأدوار كجزء من مسار العمل الخاص بك

00:11:48.180 --> 00:11:52.040
ويشيرنا إلى أن تخطي هذه الخطوات هو السبب الأول لتعطل التطبيقات

00:11:52.040 --> 00:11:54.400
خاصة مع تزايد قيود الأمان في البيئات

00:11:54.400 --> 00:12:00.120
بمجرد التعامل مع المصدر والبناء والاختبار والنشر كأجزاء متصلة وليست خطوات معزولة

00:12:00.120 --> 00:12:06.540
يصبح من الأسهل فهم سبب فشل محاولات أوم وكيف يمكنك استكشاف المشكلات وإصلاحها بدلا من الاكتفاء بالأمل

00:12:06.540 --> 00:12:13.200
بعد ذلك دعنا نتعمق في كيفية تنسيق GitHub Actions لهذا العمل من مشغلات وفروع وفصل للمهام

00:12:13.200 --> 00:12:17.060
مما يجعل أتمتة Power Platform مرنة وآمنة في آن واحد

00:12:17.060 --> 00:12:20.780
GitHub Actions ربط النقاط ببعضها من خلال المشغلات والمهام

00:12:20.780 --> 00:12:25.140
إذا سبق لك انتظار اكتمال مسار GitHub Actions بعد تحديث تطبيق Power App

00:12:25.140 --> 00:12:29.080
فأنت تعلم بالفعل أن الأتمتة لا تعني السرعة الفورية وبالتأكيد ليست سحراً

00:12:29.080 --> 00:12:33.840
تصل معظم الفرق إلى هذا العائق مباشرة بعد حماس رؤية أول سير عمل قيد التنفيذي

00:12:33.840 --> 00:12:36.880
حيث تقوم بإعداد برنامج نصي وربطه بمستودعك

00:12:36.880 --> 00:12:41.240
وتتوقع أن يتم طرح كل التزام جديد كومت بسلاسة عبر جميع البيئات

00:12:41.240 --> 00:12:43.400
ثم تأتي الحقيقة لتفرض نفسها

00:12:43.400 --> 00:12:49.260
بدلا من مجرد تشغيل برنامج نصي تستخدم GitHub Actions سلسلة منطقية مبنية على المشغلات والمهام

00:12:49.260 --> 00:12:50.840
وعمليات التسليم بين البيئات

00:12:50.840 --> 00:12:56.460
هذا الترتيب والهيكل هو ما يمنع عمليات النشر من أن تصبح تشابكناً من الخطوات الفاشلة والأخطاء الغريبة

00:12:56.460 --> 00:12:59.560
نقطة البداية في هذا النظام هي المشغل Trigger

00:12:59.560 --> 00:13:03.600
يقوم معظم المبتدئين بإنشاء سير عمل يعمل عند كل عملية دفع

00:13:03.600 --> 00:13:07.800
أو عند وصول طلب سحب إلى الفرع الرئيسي

00:13:07.800 --> 00:13:10.200
من الناحية السطحية يبدو هذا كأفضل ممارسة

00:13:10.200 --> 00:13:12.800
لماذا لا تشغل خطأ نبيبك في كل مرة يتغير فيها العمل؟

00:13:12.800 --> 00:13:15.600
هنا تكمن المشكلة عندما تضع مشغلاً على الفرع الرئيسي فقط

00:13:15.600 --> 00:13:17.560
يتم توجيه كل شيء عبر مصار واحداً

00:13:17.560 --> 00:13:21.020
ماذا لو كانت التغييرات بحاجة للوصول إلى بيئة التطوير ولكن ليس الاختبار أو الانتاجة؟

00:13:21.020 --> 00:13:24.800
ماذا لو كنت مستعداً للنشر في بيئة الانتاج بينما لا تزال بيئة الاختبار تجري التحقق؟

00:13:24.800 --> 00:13:31.580
تميل الفرق التي تلتزم بمشغلات موحدة إلى مواجهة مشاكل حيث تتسلل ميزات مخصصة لبيئات التطوير إلى الانتاج

00:13:31.580 --> 00:13:34.880
أو تتجاوز عمليات نشر الاختبار أعدادات الانتاج فجأة

00:13:34.880 --> 00:13:42.080
يمكنك تفريد سير العمل لكل بيئة التطوير والاختبار والإنتاج وإعداد مشغلات محددة جداً لكل منها

00:13:42.080 --> 00:13:46.320
على سبيل المثال قم بإعداد سير عمل يعمل فقط عند الدفع إلى فرع التطوير

00:13:46.320 --> 00:13:50.500
أو قم بتشغيل سير عمل مختلف عندما يدمج شخص ما في فرع إصدار الانتاج

00:13:50.500 --> 00:13:55.180
يمنح هذا النهج تحكماً أكبر ويخلق فاصلاً واضحاً بين العمل قيد التنفيذ والتغييرات الحية

00:13:55.180 --> 00:13:58.580
لكن العديد من الفرق لا تعيد النظر في مشغلاتها بعد إنشائها

00:13:58.580 --> 00:14:01.820
هكذا يمكن أن تتسرب الأسرار من بيئة إلى أخرى

00:14:01.820 --> 00:14:05.460
وتنتهي إعدادات مخصصة للتطوير في الانتاج عن طريق الخطأ

00:14:05.460 --> 00:14:10.780
حاول أحد الفرق التي عملت معها تشغيل عملية إدارة دورة حياة التطبيق أوم بالكامل من سير عمل واحد

00:14:10.780 --> 00:14:17.720
لفترة بدأ الأمر جيداً حتى لاحظ أحدهم ظهور سلسلة اتصال قاعدة بيانات الانتاج في بيئة التطوير

00:14:17.720 --> 00:14:21.140
لم يدركوا أن أسرارهم كانت تتم مشاركتها بين المهام

00:14:21.140 --> 00:14:24.780
وبمجرد انتقال الكود بين البيئات تسربت تلك الأسرار معه

00:14:24.780 --> 00:14:26.940
لم يكن انهياراً أو خطأاً واضحاً

00:14:26.940 --> 00:14:28.300
كان أمراً صامتاً

00:14:28.300 --> 00:14:30.900
هذا النوع من تسرب البيانات أكثر شيوعاً مما تعتقد

00:14:30.900 --> 00:14:35.160
خاصة إذا لم تكن بإعداد سير العمل الخاص بك لفصل الأسرار عن متغيرات البيئة

00:14:35.160 --> 00:14:39.640
تتعامل كل مهمة في سير عمل جيت هاب أكشونز مع جزء واضح من العملية

00:14:39.640 --> 00:14:42.820
قد تتولى مهمة واحدة تصدير الحل من بيئة المصدر

00:14:42.820 --> 00:14:48.140
بينما تهتم مهمة أخرى بالتحقق وفك الحزم ومسح البيانات الوصفية للحل

00:14:48.140 --> 00:14:52.200
والتحقق من جميع التبعيات والتأكد من وجود مراجع الموصل

00:14:52.200 --> 00:14:56.020
بعد ذلك تأتي المهمة التي تجهز المتغيرات الخاصة بالبيئة

00:14:56.020 --> 00:14:58.780
وتترجم الحل ليناسب بيئته المستهدفة

00:14:58.780 --> 00:15:02.140
تقوم المهمة الأخيرة بتشغيل عملية الاستيراد باستخدام مدير الخدمة

00:15:02.140 --> 00:15:05.000
لكتابة التغيرات في البيئة الصحيحة

00:15:05.000 --> 00:15:08.520
قد تعتقد أن متغيرات البيئة والأسرار هي مجرد عناصر نائبة أساسية

00:15:08.520 --> 00:15:12.080
لكنها من الناحية العملية هي الغراء الذي يربط كل شيء ببعضه

00:15:12.080 --> 00:15:14.280
سلاسل الاتصال ومفاتيح واجهة البرمجة

00:15:14.280 --> 00:15:16.180
وكلمات المرور المشتركة

00:15:16.180 --> 00:15:17.900
كلها تحتاج إلى تبديل بين المهام

00:15:17.900 --> 00:15:20.100
ولكن لا يمكن أبدا أن تتسرب عبر الحدود

00:15:20.100 --> 00:15:21.620
في إدارة دورة حياة تطبيقات

00:15:21.620 --> 00:15:25.480
قد يكون لديك اتصال مختلف لكل بيئة

00:15:25.480 --> 00:15:29.460
أو تحتاج إلى تبديل نقاط نهاية اعتمادا على التدفق أو تطبيق باور أب الذي تستهدفه

00:15:29.460 --> 00:15:32.480
إذا قمت بإعادة استخدام المتغيرات أو ترميز الأسرار بشكل ثابت

00:15:32.480 --> 00:15:35.480
فسينتهي بك الأمر إلى خط أنبيب هاش أو الأسوأ من ذلك

00:15:35.480 --> 00:15:36.760
مخاطر أمنية كبيرة

00:15:36.760 --> 00:15:40.380
تعتمد عملية الاستيراد على سحب الأسرار فقط من المخزن الصحيح

00:15:40.380 --> 00:15:44.100
بحيث لا يتم تعريض بيئة الإنتاج لهفوات الاختبار أو التطوير

00:15:44.100 --> 00:15:47.820
نموذج ذهني جيد للأسرار في جيت هاب أكشونز هو تخيل كل بيئة

00:15:47.820 --> 00:15:49.940
وكأنها تمتلك مخزنها الرقمية الخاصة

00:15:49.940 --> 00:15:52.940
صندوق مغلق لا يمكن إلا للمهام الصحيحة رؤيته

00:15:52.940 --> 00:15:55.360
يمنحك جيت هاب عناصر تحكم دقيقة

00:15:55.360 --> 00:15:57.320
يمكنك تحديد نطاق الأسرار للبيئات

00:15:57.320 --> 00:16:02.260
بحيث لا يمكن لمهمة تعمل في بيئة التطوير الوصول إلى بيانات اعتماد بيئة الإنتاج والعكس صحيح

00:16:02.260 --> 00:16:03.520
قم بإعداد هذه المخازن

00:16:03.520 --> 00:16:07.240
وحتى إذا حاول شخص يعدل على خط الأنابيب القيامة بشيء محفوف بالمخاطر

00:16:07.240 --> 00:16:09.920
فإن قواعد حماية البيئة تمنع أي خطأ من الانتقال

00:16:09.920 --> 00:16:13.700
توثيق كل من مايكروسوفت وجيت هاب يركز بشدة على هذه النقطة

00:16:13.700 --> 00:16:19.880
يسون بقواعد حماية البيئة وتحديد نطاق الأسرار بصرامة لإيقاف التسريبات بين البيئات قبل أن تبدأ حتى

00:16:19.880 --> 00:16:24.220
بدون هذا النوع من الحماية تنهار حتى أفضل سير عمل لإدارة دورة حياة التطبيقات

00:16:24.220 --> 00:16:27.460
تخيل سير عمل يقوم بالنشر في بيئة الإنتاج

00:16:27.460 --> 00:16:32.420
بينما لا يزال يحتفظ بسلسلة اتصال بيئة التطوير أو بيئة اختبار تصل فجأة إلى بيانات الإنتاج

00:16:32.420 --> 00:16:34.980
الأمر لا يكسر الأشياء بشكل مرئي دائما

00:16:34.980 --> 00:16:40.860
أحيانا يعني ذلك فقط انطلاق تنبيهات الانتثال أو انطلاء السجلات بأخطاء طفيفة تتراكم ببطء لتصبح مشاكل أكبر

00:16:40.860 --> 00:16:45.040
لهذا السبب فإن تفرع سير العمل وتحديد نطاق الأسرار ليست مجرد مواضيع متقدمة

00:16:45.040 --> 00:16:48.580
إنها شبكة الأمان التي تمنع أتمتتك من الانهيار بصمت

00:16:48.580 --> 00:16:54.080
هناك أيضا قيمة في تقسيم سير العمل ليس فقط حسب البيئة ولكن حسب المسئولية

00:16:54.080 --> 00:16:59.620
الكود الذي يصدر ويتحقق من الحلول لا ينبغي حتى أن يعرف كيفية النشر أو تبديل الأسرار

00:16:59.620 --> 00:17:08.240
إذا كانت كل مهمة تتعامل مع جزء واحد من اللغز يصبح من الأسهل بكثير تحديد مكان حدوث الخطأ والتراجع وتدقيق التغييرات بعد وقوعها

00:17:08.240 --> 00:17:12.140
تبقى الأسرار في مخازنها وتتبع المهام أذونة محددة النطاق بوضوح

00:17:12.140 --> 00:17:16.060
وتشير إخفقات خط الأنابيب مباشرة إلى الجزء الذي يحتاج إلى إصلاح

00:17:16.060 --> 00:17:23.500
فهم كيفية تسليم جيتهب أكشونز العمل من مهمة إلى أخرى مع الحفاظ على الأسرار ضمن نطاق ضيق والمشغلات محددة بوضوح

00:17:23.500 --> 00:17:28.900
هو ما ينقل أم من تجربة قائمة على الأمل إلى ممارسة موثوقة وآمنة وقابلة للتنبؤ

00:17:28.900 --> 00:17:33.500
تقسيم سير العمل هذا ليس مجرد مسألة لمطابقة أفضل الممارسات

00:17:33.500 --> 00:17:37.360
إنه ما يمنع التسريبات الأمنية الهادئة والتجاوزات غير المقصودة

00:17:37.360 --> 00:17:42.420
ويقطع دابر فئة كاملة من الأخطاء غير المرئية قبل أن تبدأ في إزعاج بيئاتك

00:17:42.420 --> 00:17:46.680
الآن ومع عمل الأجزاء معا من خلال أتمتة محددة النطاق بشكل صحيح

00:17:46.680 --> 00:17:49.180
حان الوقت لمعالجة نقطة احتكاك أخرى

00:17:49.180 --> 00:17:56.520
الموصلات ومبادئ الخدمة والمزالق الصغيرة ولكن الحاسمة التي قد تعيق عمليات النشر بمجرد شعورك بالثقة

00:17:56.520 --> 00:17:59.980
مبادئ الخدمة السرية والمشاكل المتعلقة بالموصلات

00:17:59.980 --> 00:18:04.220
إذا حاولت يوما نقل تطبيق باور أب أو تدفق فلو من بيئة التطوير إلى بيئة الإنتاج

00:18:04.220 --> 00:18:05.420
فأنت تعرف القصة

00:18:05.420 --> 00:18:07.740
تعمل الأمور بسلاسة في بيئة واحدة

00:18:07.740 --> 00:18:12.980
ثم بمجرد التبديل يتوقف كل شيء أو تظهر لك تلك الأخطاء الغامضة في الاتصال

00:18:12.980 --> 00:18:15.520
هذا الأمر ليس مقتصرا على فريق معين

00:18:15.520 --> 00:18:19.660
كل مسؤول في باور بلاتفورم يصطدم بهذا الجدار في نهاية المطاف

00:18:19.660 --> 00:18:24.380
يكمن أصل المشكلة في كيفية عمل الموصلات والأسرار خلف الكواليس

00:18:24.380 --> 00:18:29.540
لا يمكنك ببساطة تصدير ملف حل مضغوط من التطوير وتوقع عمله في مكان آخر

00:18:29.540 --> 00:18:32.840
لأن الروابط التي يعتمد عليها تتغير مع كل بيئة

00:18:32.840 --> 00:18:35.120
لنأخذ مراجع الموصلات كمثال

00:18:35.120 --> 00:18:40.340
في باور بلاتفورم لا يعد الموصل مجرد جزء ثابت من المعلومات المضمنة في تطبيقك

00:18:40.340 --> 00:18:43.900
إنه ديناميكي وقابل للتغيير وغالبا ما يكون فريدا لكل بيئة

00:18:43.900 --> 00:18:48.160
عند تصدير الحل الخاص بك تعمل مراجع الموصلات تقريبا مثل العلامات المرجعية

00:18:48.160 --> 00:18:52.420
فهي تشير إلى كائنات اتصال لا توجد إلا في البيئة التي أنشئت فيها

00:18:52.420 --> 00:18:54.660
لذا عند الاستيراد إلى بيئة الاختبار أو الانتاج

00:18:54.660 --> 00:18:57.820
لا تتم إعادة إنشاء نقطة نهاية HTTP أو رابط Dataverse

00:18:57.820 --> 00:19:00.820
الخاص بك بالضرورة بنفس الطريقة أو قد لا يتم إنشاؤه على الإطلاق

00:19:00.820 --> 00:19:03.080
هنا يقع الكثير من الفرق في الفخ

00:19:03.080 --> 00:19:06.620
إذا كان التطوير يستخدم موصلنا لاختبار البيانات

00:19:06.620 --> 00:19:09.900
ولم يتم عكس ذلك الإعداد بدقة في الانتاج

00:19:09.900 --> 00:19:15.740
فسيفشل التدفق أو التطبيق بصمت أو يتوقف عند محاولة الاتصال الأولى

00:19:15.740 --> 00:19:20.900
يحاول الكثير من الأشخاص الالتفاف على هذا بمشاركة بيانات اعتماد المستخدم عبر البيئات

00:19:20.900 --> 00:19:25.620
يعتقدون أنه إذا استخدمت نفس الحساب أو كلمة المرور التي أنشأت الاتصال في التطوير

00:19:25.620 --> 00:19:27.300
فربما سيعمل في الانتاج

00:19:27.300 --> 00:19:29.600
الواقع هو أن هذا يجلب مجموعة من المشاكل

00:19:29.600 --> 00:19:32.780
بدءا من رفض الأدونات وصولا إلى تشغيل عمليات تدقيق الامتثال

00:19:32.780 --> 00:19:34.240
توجيهات مايكروسوفت واضحة

00:19:34.240 --> 00:19:38.900
فاستخدام بيانات اعتماد المستخدم الفردية لعمليات النشر الألية ليس عمليا أو آمنا

00:19:38.900 --> 00:19:44.660
إنه يضع أتمتتك تحت رحمة تغييرات كلمة المرور وقد يترك أثرا غير واضح في سجلات التدقيق الخاصة بك

00:19:44.660 --> 00:19:46.380
لا توجد مساءلة واضحة

00:19:46.380 --> 00:19:52.860
وفي النهاية تحضر الأدونات مسار العمل عندما يتم تمييز المستخدم الأصلي أو إزالته أو فقدان وصوله

00:19:52.860 --> 00:19:54.540
هنا يأتي دور مبادئ الخدمة

00:19:54.540 --> 00:19:57.080
إذا لم تعمل بها من قبل

00:19:57.080 --> 00:20:01.600
تخيل مبدأ الخدمة كيد رقمية إضافية مصممة خصصا للأتمتة

00:20:01.600 --> 00:20:06.680
على عكس المستخدم العادي يرتبط مبدأ الخدمة بتسجيل تطبيق في أشر أيدي

00:20:06.680 --> 00:20:12.440
وليس بشخص حقيقي أن تمنحه الحد الأدنى من الأذونات اللازمة لتنفيذ مهام النشر الخاصة بك

00:20:12.440 --> 00:20:15.060
يبدو الأمر بسيطا لكن المكاسب كبيرة

00:20:15.060 --> 00:20:18.880
بدلا من الاعتماد على مستخدم قد يغادر المؤسسة أو يغير أدوارا وظيفية

00:20:18.880 --> 00:20:21.880
تظل عمليات النشر متسقة وقابلة للتدقيق والتتبع

00:20:21.880 --> 00:20:25.760
تحصل كل بيئة على صلاحية الوصول إلى الموارد والاتصالات الصحيحة فقط

00:20:25.760 --> 00:20:28.480
ويتم تسجيل أي تغييرات تحت هذا الحساب الآلي

00:20:28.480 --> 00:20:31.020
عند حدوث فشل يكون لديك سجل تدقيق واضح

00:20:31.020 --> 00:20:34.680
ولن ينتهي بك الأمر بوجود تدفقات مهجورة لا يمكن لأحد إصلاحها

00:20:34.680 --> 00:20:36.740
بخصوص مشكلة تعيين المواصلات

00:20:36.740 --> 00:20:40.040
فكر فيما يحدث عندما تتباعد البيئات عن بعضها البعض

00:20:40.040 --> 00:20:43.420
ربما حصل فريق التطوير على موافقة لاستخدام موصل مخصص جديد

00:20:43.420 --> 00:20:45.800
لنفترض أنه يتصل بواجهة برمجة تطبيقات تجريبية

00:20:45.800 --> 00:20:48.740
عندما يحين وقت الانتقال إلى بيئة الإنتاج

00:20:48.740 --> 00:20:50.680
لا يكون هذا الموصل مفقودا فحسبه

00:20:50.680 --> 00:20:52.740
بل قد لا تسمح به سياسات البيانات المؤسسية

00:20:52.740 --> 00:20:54.120
إذا نسيت إعادة التعيين

00:20:54.120 --> 00:20:58.180
فسيقوم التطبيق بالاتصال بنقطة نهاية خاطئة أو يتعطل تماما

00:20:58.180 --> 00:21:01.600
رأيت هذا الأمر يتسبب في مشاكل كبيرة في مجموعة رعاية صحية مؤخرا

00:21:01.600 --> 00:21:05.240
تسبب تعيين خاطئ لأحد المواصلات في استخدام بيانات اختبار في بيئة الإنتاج

00:21:05.240 --> 00:21:07.180
وكاد أن يتسبب في خرق لسياسات الانتثال

00:21:07.180 --> 00:21:10.720
قامت خطة العمل المؤتمتة الخاصة بهم بتصدير كل شيء كما هو مخطط

00:21:10.720 --> 00:21:15.040
لكن مرجع الموصل داخل الحل كان لا يزال يشير إلى قاعدة بيانات اختبار قديمة

00:21:15.040 --> 00:21:16.900
لم يتم رصدها بواسطة باور بلاتفورم

00:21:16.900 --> 00:21:19.740
حتى بدأت البيانات الحقيقية تتدفق عبر المسارات الخاطئة

00:21:19.740 --> 00:21:23.120
تتدخل متغيرات البيئة لتخفيف بعض هذه المعاناة

00:21:23.120 --> 00:21:26.660
على عكس الترميز الثابت لنقاط النهاية أو مفاتيح واجهة البرمجة

00:21:26.660 --> 00:21:30.740
تسمح لك متغيرات البيئة بفصل ما يتغير عبر البيئات عما يظل ثابتا

00:21:30.740 --> 00:21:34.120
يمكنك استبدال نقاط النهاية أو مفاتيح واجهة البرمجة أو الأسرار الأخرى

00:21:34.120 --> 00:21:37.560
مع كل عملية نشر دون الحاجة إلى إعادة كتابة تطبيقك أو تدفق العمل

00:21:37.560 --> 00:21:41.720
على سبيل المثال يمكن إعادة تهيئة تدفق يعمل مع جدول ديتا فيرس

00:21:41.720 --> 00:21:46.040
للتطوير عند الاستيراد ليستخدم جدول الانتاج ببساطة عن طريق تغيير متغير البيئة

00:21:46.040 --> 00:21:47.680
داخل عملية النشر الخاصة بك

00:21:47.680 --> 00:21:50.460
تعد خطوط أنابيبي جيت هاب أكشونز هذا الأمر عمليا

00:21:50.460 --> 00:21:53.540
يمكن لكل مهمة إدراج القيمة الصحيحة في الوقت المناسب

00:21:53.540 --> 00:21:56.200
ولكن حتى هنا الانضباط هو المفتاح

00:21:56.200 --> 00:22:00.340
إذا نسيت تحديث متغير أو سمحت بتسرب الأسرار عبر البيئات

00:22:00.340 --> 00:22:03.020
فسيصبح سير عملك مكشوفا فجأة

00:22:03.020 --> 00:22:09.100
تؤكد مايكروسوفت على ضرورة تحديد نطاق الأسرار بعناية وتعيين مراجع الموصلات بشكل مقصود

00:22:09.100 --> 00:22:11.180
سياسات منع فقدان البيانات

00:22:11.180 --> 00:22:12.140
دي أل بي

00:22:12.140 --> 00:22:18.380
موجودة لسبب وهو منع المعلومات الحساسة من التنقل بين البيئات أو الظهور في المكان الخطأ

00:22:18.380 --> 00:22:22.880
إذا حاولت تجاوز هذه السياسات بمشاركة المتغيرات أو الاتصالات

00:22:22.880 --> 00:22:26.320
فستصطدم بضوابط الأمن أو الامتثال المؤسسيات

00:22:26.320 --> 00:22:28.680
والأهم من ذلك أنك تفقد القدرة على التنبؤ

00:22:28.680 --> 00:22:33.020
لأنه لم يعد هناك خط فاصل بين ما هو مخصص للتطوير وما هو مخصص للاختبار أو الإنتاج

00:22:33.020 --> 00:22:36.820
من الصعب المبالغة في تقدير الفائدة التي تحصل عليها عندما تقوم بكل هذا بشكل صحيح

00:22:36.820 --> 00:22:37.920
تغير مبادئ الخدمة

00:22:37.920 --> 00:22:42.580
جنبنا إلى جنب مع متغيرات البيئة المدارة جيدا والمواصلات المعينة بدقة من مسار عملك

00:22:42.580 --> 00:22:45.020
تصبح عمليات النشر الخاصة بك قابلة للتنبؤ

00:22:45.020 --> 00:22:49.080
عندما تتعطل الأمور يكون لديك سلسلة عهدة واضحة وتعرف بالضبط أين تبحث

00:22:49.080 --> 00:22:52.660
هل كان السبب في تعيين الموصل أم متغيرا أم إذنا مفقودا

00:22:52.660 --> 00:22:57.760
يمكن للمدقيقين تتبع التغييرات ولا يوجد أي قلق عندما يغادر شخص ما المؤسسة أو يغير كلمات المرور

00:22:57.760 --> 00:23:02.520
كل الأمر يعود إلى التعامل مع الأسرار والمواصلات ومبادئ الخدمة كما لو كانت ذات أهمية بالغة

00:23:02.520 --> 00:23:32.500
اشتركوا في القناة