Latest / M365.FM – بودكاست Microsoft 365 وCopilot والذكاء الاصطناعي بالعربية / إدارة دورة حياة تطبيقات Power Platform باستخدام GitHub Actions: المصدر والبناء والاختبار والنشر دون تخمين (دبلجة بالذكاء الاصطناعي)
Transcript
- 0:00هل أنت مستعد لعشرة أيام من مايكروسوفت 365 وكوبايلوت والذكاء الاصطناعي وأشر
- 0:05ولقاء الأشخاص الذين يشكلون مستقبل العمل
- 0:07في يناير القادم يعود مؤتمر M365 كون بحجم أكبر
- 0:12انضم إلينا في جلسات مباشرة وعروض توضيحية واقعية
- 0:15ومعرفة عملية يقدمها خبراء مايكروسوفت وأبرز المتخصصين حول العالم
- 0:18لا شرائح عرض تقليدية
- 0:19لا مصطلحات رنانة لا تنتهي
- 0:22نحن نعالج تحديات حقيقية
- 0:23سواء كنت متخصص تقنية معلومات أو مطورا أو قائدا للأعمال
- 0:33هناك جلسات مصممة خصيصا لك
- 0:35مع عشر أيام كاملة يمكنك استكشاف تقنيات متعددة والتواصل مع مجتمع عالميا
- 0:40شاهد الجلسات مباشرة واكتسب رؤى عملية لتطبيقها في مؤسستك
- 0:44يناير 2027 عشرة أيام ومجتمع مايكروسوفت واحد
- 0:49باب التسجيل مفتوح الآن
- 0:51أحجز مكانك اليوم
- 0:54الموقع هو m365.net
- 0:59انضم الآن عبر m365.net
- 1:02ونراكم في البث المباشر في يناير
- 1:04هل تشعر أحياناً أن عمليات نشر Power Platform هي صندوق أسود غامض
- 1:08هل ترسل تحديثاً وتنتظر بقلق
- 1:10وتأمل فقط أن يعمل عبر بيئات التطوير والاختبار والإنتاج
- 1:13ماذا لو كان بإمكانك التحكم ورؤية كل مرحلة من عملية أوم
- 1:17باستخدام GitHub Actions دون تخمين أو عمل يدوي
- 1:20دعونا نكشف الستارة عن كيفية ترابط المكونات والتحكم في المصدر
- 1:25والأتمتة والمتغيرات الآمنة بشكل فعلي
- 1:28هذا ليس مجرد شرح تقليدي آخر
- 1:30هذا هو السبب الذي تغفله معظم الأدلة
- 1:32حتى لا تضطر للتخمين في عملية النشر القادمة
- 1:34إذن لماذا تبدو إدارة دورة حياة التطبيقات أوم في Power Platform كالمتاهة؟
- 1:38إذا حاولت يوما نشر تطبيق Power App وشعرتي بعدم اليقين
- 1:42وكأن شيئا مهما قد سقط سهونا فأنت لست وحدك
- 1:45نظريا تعد Power Platform بتطوير سهل للتطبيقات
- 1:48ولكن خلف هذه الواجهة الودية
- 1:50عملية أوم ليست مباشرة على الإطلاق
- 1:53يتم نشر تطبيقات الويب من نظام التحكم في المصدر
- 1:55وتبنى في خط أنبيب وتستقر في بيئة الإنتاج بسلوك متوقع
- 1:59أما Power Platform فهي تخفي نصف المنطق داخل واجهات السحب والإفلات
- 2:04وشاشات الموصلات وصيغة لا يمكنك رؤيتها في أي مستودع جد
- 2:08لذا حتى لو اتبعت كل خطوة في أدلة الإدارة عالية المستوى
- 2:11ستظل تواجه أعطالا غريبة يصعب تشخيصها بمجرد خروج التطبيقات الهامة عن بيئة التطوير
- 2:16لنلقي نظرة على أدلة أوم المنتشرة حاليا
- 2:19معظمها يواجهك لتصدير ملف حل مضغوط زب واستيراده في مكان آخر
- 2:23الأمر بسيط أليس كذلك لكن كيفية القيام بذلك هي مجرد طبقة واحدة
- 2:27ما تتجهله تلك الأدلة هو السبب
- 2:29لماذا تتعطل عمليات نشر Power Platform بطرق لا تحدث أبدا مع الكود البرمجي العادي
- 2:33هذا هو ما يسبب حالة من الارتباك المستمر
- 2:36جذر المشكلة هو أن المنطقة والاتصالات والإعدادات في Power Apps لا تخزن مثل الكود البرمجي التقليدي
- 2:41أنت لا تقوم فقط بنسخ مستودع برمجيات ومراقبة اختبارات الوحدة
- 2:45لذا عند محاولة نقل تطبيقك فإن كل تلك التبعيات المخفية والاتصالات بأوتلوك والشيربوينت وواجهات برمجة التطبيقات المخصصة لا تنتقل دائما بسلاسة داخل ملف
- 2:54إليك السيناريو
- 2:55لديك تطبيق جديد ومميز يعمل في بيئة التطوير
- 2:58تقوم بتصدير الحل واستيراده للاختبار وفجأة يتوقف التدفق عن العمل
- 3:01نادرا ما تكون المشكلة مجرد ملف
- 3:03بدلا من ذلك تشير الاتصالات إلى المكان الخطأ ولا تتوافق الأذونات وتحضر سياسات البيانات اتصالات بدأت جيدة قبل دقائق
- 3:11الآن تخيل القيام بذلك عبر ثلاث بيئات التطوير والاختبار والإنتاج حيث تستخدم كل منها اتصالات مختلفة وسياسات حماية بيانات وموافقين وحواجز إدارية
- 3:21لا يمكنك حل هذه المشكلة عن طريق النسخ واللسق
- 3:24الأبحاث تدعم ما يراه المسؤولون والمطورون كل أسبوع
- 3:27غالبية عمليات النشر الفاشلة في Power Platform تنجم عن فقدان مراجع الموصلات أو سوء إدارة متغيرات البيئة
- 3:34فقدان مرجع الموصل يعني ببساطة أن التدفق لا يمكنه العثور على اتصال Outlook أو Dataverse الخاص به
- 3:40لذا في اللحظة التي تحاول فيها تشغيل تطبيقك أو تدفقك في بيئة أخرى تحصل على أخطاء وقت التشغيل
- 3:46ولأن متغيرات البيئة تعمل بشكل مختلف في Power Platform مقارنة بمنتجات Microsoft 365 الأخرى
- 3:52فإنها توقع حتى المطورين ذوي الخبرة في أخطاء
- 3:55من المفترض أن تتعامل المتغيرات مع نقاط النهاية أو المفاتيح أو تكونات خاصة بالمستأجر
- 4:00ولكن إذا نسي شخص ما تحديثها بعد تصدير الحل فقد يؤدي تغيير يبدو غير ضر إلى كسر تطبيق مباشر
- 4:06كثيرون منا يقعون في نفس الفخ في البداية
- 4:09قد تعتقد أن تصدير ملف زقل الحل يجمع كل ما يلزم
- 4:11لكنه في الواقع يتجاهل مراجع الموصلات الديناميكية
- 4:14على سبيل المثال لنقل أن لديك تطبيق يستخدم موصل HTTP لخدمة خارجية في بيئة التطوير
- 4:19عند الاستيراد إلى بيئة الاختبار أو الإنتاج
- 4:22لن توجد نسخة الموصل تلك
- 4:24يشير مرجع الموصل داخل تطبيقك إلى كائن مفقود
- 4:27وتتوقف التدفقات داخل الحل بصمت حتى يقوم مستخدم أو مسؤول بإعادة إنشاء الاتصالات وإعادة تعيينها يدويا
- 4:34إذا كان لديك أكثر من مطور أو مسؤول
- 4:36فمن السهل فقدان تتبع أي مرجع يذهب إلى أين
- 4:39ولا أحد يريد مراجعة ما بعد الحادث لتبرير أنه كان يعمل في بيئة التطوير
- 4:44تعقيد آخر
- 4:45مدير الخدمة
- 4:46يبدأ معظم الأشخاص باستخدام حسابات المستخدمين لتصدير واستيراد الحلول لأنها أسرع في البدء
- 4:53ولكن عند محاولة الأتمتة باستخدام إجراءات بذهب أو أي نظام تكامل مستمر
- 4:56فإن استخدام بيانات اعتماد شخص ما يؤدي بسرعة إلى طريق مسدود
- 4:59ستصطدم بجدان الأذونات أحيانا بدون رسائل خطأ واضحة
- 5:03أو قد تثير عمليات تدقيق الامتثال لأنك تشغل عمليات نشر حيوية تحت حساب شخصي بدلا من حساب مخصص للأتمتة
- 5:10تتولى كيانات الخدمة
- 5:11وهي في الأساس هويات تطبيقات يتم إنشاؤها في أشر أيدي
- 5:14إدارة كافة الأذونات والسجلات وعمليات التدقيق التي يحتاجها مسار العمل الخاص بك
- 5:18بدونها تتحول سلسلة الأتمتة لديك إلى مجموعة متفرقة من عمليات التسليم بين الأفراد
- 5:23ولن تعرف أبدا من قام بتغيير ماذا
- 5:25يتحول التحكم في المصدر أيضا إلى أمر غير متوقع
- 5:27مع التعليمات البرمجية العادية لديك سجلات الالتزام
- 5:30كوميت هستوريز وأدوات تتبع التغييرات
- 5:32تمثل ملفات خلول باور بلاتفورم لقطات فقط
- 5:34مما يعني أنك تفتقد تتبع التغييرات الدقيقي
- 5:37المنطق المخفي في صياغ شاشات تطبيقات كنفس
- 5:39أو في التدفقات فلوز الموثقة بشكل بسيط لا يظهر إلا عند التصدير مجددا
- 5:44إذا قام شخص ما بتعديل أعداد تدفق في واجهة المستخدم
- 5:46فمن الصعب معرفة سبب تصرف البيئات اللاحقة بشكل مختلف فجأة
- 5:49النتيجة النهائية هي أن إدارة دورة حياة التطبيق
- 5:52تبدو كحل لغز ينقصه نصف القطع
- 5:55أو على الأقل مخفية تحت الصندوق
- 5:57الاعتمادات غير المرئية والموصلات الخاصة بالبيئة
- 6:00والمتغيرات التي لا يمكنك رؤيتها في الكودي
- 6:03كلها تعيق سير عمل المطور المعتاد
- 6:06وهذا قبل التعامل مع حقيقة أن بيئات الإنتاج
- 6:08تحتوي دائما تقريبا على أذونات أكثر صرامة
- 6:11وسياسات بيانات مختلفة
- 6:12ومتطلبات تدقيق غير واضحة في بيئات التطوير أو الاختبار
- 6:16لكن إليك الجانب الإيجابي
- 6:18هذا التعقيد ليس عشوائيا
- 6:20هناك سبب عملي لتعامل باور بلاتفورم
- 6:23مع المصدر والمتغيرات والموصلات بهذه الطريقة الفريدة
- 6:27إنها تسعى للسماح لمستخدم الأعمال
- 6:29ببناء تطبيقات قوية دون القلق بشأن البرمجة
- 6:32النتيجة الجانبية هي أنه يتعين عليك بصفتك الشخص الذي يقوم بأعداد الأتمتة
- 6:36تتبع ما يختبئ خلف الكواليس
- 6:38إذا عرفت مسار تلك الأسلاك غير المرئية
- 6:41يمكنك إصلاح أو تجنب معظم الأخطاء الفادحة التي تعرقل إدارة أوم في باور بلاتفورم
- 6:46الآن إذا كان كل هذا يبدو كعبء كبير فأنت لست مخطئا
- 6:50لكن هناك أربع ركائز لإدارة أوم تساعد بالفعل في فك هذا التشابك
- 6:53المصدر والبناء والاختبار والنشر
- 6:56لكل منها سماتها الخاصة في باور بلاتفورم
- 6:58لكنها معاً تعيد الهيكلة لما يبدو خلاف ذلك فوضى عارمة
- 7:01نظام أوم الأساسي
- 7:03المصدر والبناء والاختبار والنشر
- 7:05في كل مرة يطلب فيها أحدهم مسار عمل لام باور بلاتفورم يعمل بسلاسة
- 7:09فإن أول ما يتبادر إلى الذهن هو تلك الركائز الأربع لام أوم
- 7:12المصدر والبناء والاختبار والنشر
- 7:15في عالم التطوير التقليدي يمكنك القيام بهذه المهام وأنت مغمض العينين
- 7:18لكن باور بلاتفورم لا تمنحك هذه السهولة
- 7:21فجأة لم يعد المصدر يعني الكود البرمجي
- 7:24بل يعني التعامل مع ملفات الحلول
- 7:26وتصدير حزم مضغوطة مليئة بالتطبيقات والتدفقات
- 7:29وأحياناً المواصلات التي تتظاهر بأنها جزء من المصدر
- 7:33لنبدأ بالأساسيات
- 7:34ثم نحلل ما يجعل كل ركيزة تبدو غريبة بعض الشيء في هذا العالم
- 7:38لديك ملف الحل المضغوط الخاص بك
- 7:40إنه ليس كوداً بالمعنى المعتادي
- 7:42افتح الملفة وستجد أمامك ملفات شرح بصغتي XML وجيسن
- 7:45وليس المنطق البرمجي الذي قد تراه في TypeScript أو C-H
- 7:48لكن هذا هو المصدر الخاص باور بلاتفورم
- 7:50غالباً ما تتعثر الفرق في هذه النقطة
- 7:53يبدو الأمر قابلاً للنقل حتى تلك أن معظم التغييرات
- 7:55مثل تحديث معادلة في شاشة أو تعديل منطق تدفق العمل
- 7:58لا تظهر بوضوح إلا بعد تصدير ملف حل سولوشن جديد بصغتي زب
- 8:02لذا نعم يمكنك إدارة إصدارات ملفات الحل هذه في جت
- 8:05ولكن ما لم تكن منضبطاً بشأن التصدير بعد كل تعديل مهم
- 8:07فسيحتوي تاريخ إصداراتك على فجوات واضحة
- 8:10الآن ننتقل إلى التكوين
- 8:12بالنسبة للتطبيقات العادية
- 8:13قد تخزن سلاسل الاتصال في ملف أعدادات وتنتهي المهمة
- 8:17أما باور بلاتفورم فيقوم بتهريب بيانات خاصة بالبيئة داخل هذه الحلول
- 8:21الأمر لا يقتصر على متغيرات البيئة
- 8:23بل يشمل مراجع الموصلات ونقاط النهاية الديناميكية والأدوار
- 8:27والأذنات المجمعة بجانب منطق العمل
- 8:35إلى أماكن خاطئة
- 8:36لقد رأيت فرقاً تلتزم بدقة برفع ملفات الحلول بصيغة زب
- 8:39لتكتشف بعد النشر أن نصف تطبيقاتهم
- 8:41لا تزال تتصل بقاعدة بيانات التطوير
- 8:43ديتا فيرس بدلاً من بيئة الإنتاج
- 8:45لأن أحداً لم يقم بإعادة تعيين مراجع الموصلات
- 8:47ثم نأتي إلى مرحلة البناء
- 8:49كلمة بناء تستحضر عادة صور تجميع الأكوادي
- 8:52ورؤية علامات الاختيار الخضراء في مهام التكامل المستمر
- 8:55مع باور بلاتفورم
- 8:56تدور عملية البناء حول تخزين تلك الحزم المضغوطة
- 8:59ومراجعة المخططات والتحقق من التبعيات
- 9:02في خط أنابيبي جيت هاب أكشونز
- 9:04تلتقط مهمة البناء ملف الحل الخاص بك
- 9:06ثم تستخدم واجهة سطر أوامر باور بلاتفورم من مايكروسوفت
- 9:09لفك ضغط الحل والتحقق منه وإعادة ضغطه
- 9:11خطوة التحقق هي حيث يحدث السحر أو الفوضى
- 9:14قد تكتشف مراجع معطلة أو إجراءات غير مدعومة
- 9:17والأسوأ من ذلك
- 9:18إذا كان التغيير في تدفق العمل يعتمد على موصل مخصص
- 9:21لم يتم تضمينه في التحكم بالمصادر
- 9:23فإن عملية البناء ستحزم بصمت شيئا غير مكتملا
- 9:26وهنا تزداد الأمور تعقيدا
- 9:28وظائف البناء هذه لا تتعلق بالتجميع بقدر ما تتعلق
- 9:31بتنظيم عملية تصدير موثوقة والتأكد من أن ما بداخلها قابل للشحن
- 9:35الفرق التي تتجاهل هذا أو تتعجل فيه تجد نفسها بسرعة
- 9:38في مواقف ينجح فيها البناء تقنيا
- 9:40لكن ما يصل إلى بيئة الاختبار أو الإنتاج يفتقر إلى نصف ميزاته المقصودة
- 9:44تواصل مايكروسوفت الترويجة لفكرة أن ملفات الحلول تجعل إدارة دورة حياة التطبيقات
- 9:47قابلة للنقل
- 9:48ولكن هناك دائما ملاحظة هامشية
- 9:50تعتمد القابلية للنقل على تعيين المواصلات بشكل صحيح وإعداد الأدوار عبر البيئات المختلفة
- 9:54الاختبار هو الخطوة التالية في قائمة المصادر
- 9:57في خط أنبيب تطبيقات الويب
- 9:58قد تقوم الاختبارات المؤتمدة بتشغيل اختبارات الوحدات أو فخصات واجهة المستخدم
- 10:02أما بالنسبة لام باور بلاتفورم
- 10:04فما يعتبر اختبارا لا يزال محل نقاشا
- 10:06أحيانا يكون الأمر عبارة عن التحقق من الحل
- 10:09أي هل يفتح الحل وهل يتم حل التبعيات الرئيسية
- 10:12وفي أحيان أخرى يكون عبارة عن تشغيل تدفقة اختبار أو التأكد من أن المواصلات تستجيب في بيئة الاختبار
- 10:18في كثير من الأحيان يكون الاختبار يدويا لأن التحقق من منطق الأعمال داخل تطبيقات كنفس
- 10:23لم يتم ربطه بعد بخطوط الانتاج المؤتمدة
- 10:25ولكن يمكنك أتمتة عمليات الفحص لاكتشاف المواصلات المفقودة
- 10:28أو التحقق من التدفقات الهامة
- 10:29أو حتى اختبار بيئة تجربية للتأكد من أن بيانات الاعتماد تعمل بشكل صحيح
- 10:33وعملية النشر هي التي تزيد من حدة هذه الصعوبات
- 10:35عند نشر تطبيق قياسي قد تكتفي فقط برفع ملفات الويب على منصة أشر
- 10:40أما مع Power Platform فعليك تعيين الاتصالات وتحديد الأذونات وتحديث الأسرار
- 10:44وتبديل متغيرات البيئة
- 10:45وأخيرا بدء الاستيراد باستخدام Service Principal وليس أبدا باستخدام حساب عادي
- 10:49وإلا ستواجه الكثير من عمليات التدقيق ورفض الأذونات
- 10:52يمكن لام GitHub Actions ربط هذه العملية معا
- 10:55ولكن فقط إذا كانت كل مهمة تعرف البيئة المستهدفة والأسرار التي يجب استخدامها
- 11:00لقد رأيت فرقا تحاول اختصار هذا المسار باستخدام مجموعة واحدة من بيانات الاعتماد عبر بيئات التطوير والإنتاج
- 11:04وهو ما يؤدي حطنا إلى الفوضى وتسريب البيانات وأخطاء الأذونات وتعطل الميزات في بيئة دون أخرى
- 11:09لنأخذ مثالا لفريق عمل حقيقي تعاملت معه قبل بضعة أشهر
- 11:12كانوا يقومون بمعظم الأمور بشكل صحيح من استخدام مستودعة بيت قياسية وإصدارات مضغوطة للحلول وهيكلية واضحة للفروع
- 11:19لكن مسار عملهم كان يتعطل دائما عند مرحلة النشر
- 11:21لماذا؟ لأنهم لم يهتموا بتبديل متغيرات البيئة أو تحديث مراجع المواصلات قبل الاستيراد إلى بيئة الإنتاج
- 11:26مما جعل تدفقة العمل الأساسية تشير إلى نقاط نهاية خاطئة مع تسرب البيانات إلى أنظمة غير صحيحة
- 11:31كان الحل يكمن في إضافة خطوات برمجية في مسار بيتهب
- 11:34الخاص بهم تقوم بتبديل المتغيرات وإعادة تعيين كل موصل عند الاستيراد
- 11:37توجيهات مايكروسوفت نفسها واضحة وصريحة بشأن هذا الأمر
- 11:41استخدم ملفات الحلول لنقل العناصر بين البيئات
- 11:43ولكن تعامل دائما مع مراجع المواصلات وتعيين الأدوار كجزء من مسار العمل الخاص بك
- 11:48ويشيرنا إلى أن تخطي هذه الخطوات هو السبب الأول لتعطل التطبيقات
- 11:52خاصة مع تزايد قيود الأمان في البيئات
- 11:54بمجرد التعامل مع المصدر والبناء والاختبار والنشر كأجزاء متصلة وليست خطوات معزولة
- 12:00يصبح من الأسهل فهم سبب فشل محاولات أوم وكيف يمكنك استكشاف المشكلات وإصلاحها بدلا من الاكتفاء بالأمل
- 12:06بعد ذلك دعنا نتعمق في كيفية تنسيق GitHub Actions لهذا العمل من مشغلات وفروع وفصل للمهام
- 12:13مما يجعل أتمتة Power Platform مرنة وآمنة في آن واحد
- 12:17GitHub Actions ربط النقاط ببعضها من خلال المشغلات والمهام
- 12:20إذا سبق لك انتظار اكتمال مسار GitHub Actions بعد تحديث تطبيق Power App
- 12:25فأنت تعلم بالفعل أن الأتمتة لا تعني السرعة الفورية وبالتأكيد ليست سحراً
- 12:29تصل معظم الفرق إلى هذا العائق مباشرة بعد حماس رؤية أول سير عمل قيد التنفيذي
- 12:33حيث تقوم بإعداد برنامج نصي وربطه بمستودعك
- 12:36وتتوقع أن يتم طرح كل التزام جديد كومت بسلاسة عبر جميع البيئات
- 12:41ثم تأتي الحقيقة لتفرض نفسها
- 12:43بدلا من مجرد تشغيل برنامج نصي تستخدم GitHub Actions سلسلة منطقية مبنية على المشغلات والمهام
- 12:49وعمليات التسليم بين البيئات
- 12:50هذا الترتيب والهيكل هو ما يمنع عمليات النشر من أن تصبح تشابكناً من الخطوات الفاشلة والأخطاء الغريبة
- 12:56نقطة البداية في هذا النظام هي المشغل Trigger
- 12:59يقوم معظم المبتدئين بإنشاء سير عمل يعمل عند كل عملية دفع
- 13:03أو عند وصول طلب سحب إلى الفرع الرئيسي
- 13:07من الناحية السطحية يبدو هذا كأفضل ممارسة
- 13:10لماذا لا تشغل خطأ نبيبك في كل مرة يتغير فيها العمل؟
- 13:12هنا تكمن المشكلة عندما تضع مشغلاً على الفرع الرئيسي فقط
- 13:15يتم توجيه كل شيء عبر مصار واحداً
- 13:17ماذا لو كانت التغييرات بحاجة للوصول إلى بيئة التطوير ولكن ليس الاختبار أو الانتاجة؟
- 13:21ماذا لو كنت مستعداً للنشر في بيئة الانتاج بينما لا تزال بيئة الاختبار تجري التحقق؟
- 13:24تميل الفرق التي تلتزم بمشغلات موحدة إلى مواجهة مشاكل حيث تتسلل ميزات مخصصة لبيئات التطوير إلى الانتاج
- 13:31أو تتجاوز عمليات نشر الاختبار أعدادات الانتاج فجأة
- 13:34يمكنك تفريد سير العمل لكل بيئة التطوير والاختبار والإنتاج وإعداد مشغلات محددة جداً لكل منها
- 13:42على سبيل المثال قم بإعداد سير عمل يعمل فقط عند الدفع إلى فرع التطوير
- 13:46أو قم بتشغيل سير عمل مختلف عندما يدمج شخص ما في فرع إصدار الانتاج
- 13:50يمنح هذا النهج تحكماً أكبر ويخلق فاصلاً واضحاً بين العمل قيد التنفيذ والتغييرات الحية
- 13:55لكن العديد من الفرق لا تعيد النظر في مشغلاتها بعد إنشائها
- 13:58هكذا يمكن أن تتسرب الأسرار من بيئة إلى أخرى
- 14:01وتنتهي إعدادات مخصصة للتطوير في الانتاج عن طريق الخطأ
- 14:05حاول أحد الفرق التي عملت معها تشغيل عملية إدارة دورة حياة التطبيق أوم بالكامل من سير عمل واحد
- 14:10لفترة بدأ الأمر جيداً حتى لاحظ أحدهم ظهور سلسلة اتصال قاعدة بيانات الانتاج في بيئة التطوير
- 14:17لم يدركوا أن أسرارهم كانت تتم مشاركتها بين المهام
- 14:21وبمجرد انتقال الكود بين البيئات تسربت تلك الأسرار معه
- 14:24لم يكن انهياراً أو خطأاً واضحاً
- 14:26كان أمراً صامتاً
- 14:28هذا النوع من تسرب البيانات أكثر شيوعاً مما تعتقد
- 14:30خاصة إذا لم تكن بإعداد سير العمل الخاص بك لفصل الأسرار عن متغيرات البيئة
- 14:35تتعامل كل مهمة في سير عمل جيت هاب أكشونز مع جزء واضح من العملية
- 14:39قد تتولى مهمة واحدة تصدير الحل من بيئة المصدر
- 14:42بينما تهتم مهمة أخرى بالتحقق وفك الحزم ومسح البيانات الوصفية للحل
- 14:48والتحقق من جميع التبعيات والتأكد من وجود مراجع الموصل
- 14:52بعد ذلك تأتي المهمة التي تجهز المتغيرات الخاصة بالبيئة
- 14:56وتترجم الحل ليناسب بيئته المستهدفة
- 14:58تقوم المهمة الأخيرة بتشغيل عملية الاستيراد باستخدام مدير الخدمة
- 15:02لكتابة التغيرات في البيئة الصحيحة
- 15:05قد تعتقد أن متغيرات البيئة والأسرار هي مجرد عناصر نائبة أساسية
- 15:08لكنها من الناحية العملية هي الغراء الذي يربط كل شيء ببعضه
- 15:12سلاسل الاتصال ومفاتيح واجهة البرمجة
- 15:14وكلمات المرور المشتركة
- 15:16كلها تحتاج إلى تبديل بين المهام
- 15:17ولكن لا يمكن أبدا أن تتسرب عبر الحدود
- 15:20في إدارة دورة حياة تطبيقات
- 15:21قد يكون لديك اتصال مختلف لكل بيئة
- 15:25أو تحتاج إلى تبديل نقاط نهاية اعتمادا على التدفق أو تطبيق باور أب الذي تستهدفه
- 15:29إذا قمت بإعادة استخدام المتغيرات أو ترميز الأسرار بشكل ثابت
- 15:32فسينتهي بك الأمر إلى خط أنبيب هاش أو الأسوأ من ذلك
- 15:35مخاطر أمنية كبيرة
- 15:36تعتمد عملية الاستيراد على سحب الأسرار فقط من المخزن الصحيح
- 15:40بحيث لا يتم تعريض بيئة الإنتاج لهفوات الاختبار أو التطوير
- 15:44نموذج ذهني جيد للأسرار في جيت هاب أكشونز هو تخيل كل بيئة
- 15:47وكأنها تمتلك مخزنها الرقمية الخاصة
- 15:49صندوق مغلق لا يمكن إلا للمهام الصحيحة رؤيته
- 15:52يمنحك جيت هاب عناصر تحكم دقيقة
- 15:55يمكنك تحديد نطاق الأسرار للبيئات
- 15:57بحيث لا يمكن لمهمة تعمل في بيئة التطوير الوصول إلى بيانات اعتماد بيئة الإنتاج والعكس صحيح
- 16:02قم بإعداد هذه المخازن
- 16:03وحتى إذا حاول شخص يعدل على خط الأنابيب القيامة بشيء محفوف بالمخاطر
- 16:07فإن قواعد حماية البيئة تمنع أي خطأ من الانتقال
- 16:09توثيق كل من مايكروسوفت وجيت هاب يركز بشدة على هذه النقطة
- 16:13يسون بقواعد حماية البيئة وتحديد نطاق الأسرار بصرامة لإيقاف التسريبات بين البيئات قبل أن تبدأ حتى
- 16:19بدون هذا النوع من الحماية تنهار حتى أفضل سير عمل لإدارة دورة حياة التطبيقات
- 16:24تخيل سير عمل يقوم بالنشر في بيئة الإنتاج
- 16:27بينما لا يزال يحتفظ بسلسلة اتصال بيئة التطوير أو بيئة اختبار تصل فجأة إلى بيانات الإنتاج
- 16:32الأمر لا يكسر الأشياء بشكل مرئي دائما
- 16:34أحيانا يعني ذلك فقط انطلاق تنبيهات الانتثال أو انطلاء السجلات بأخطاء طفيفة تتراكم ببطء لتصبح مشاكل أكبر
- 16:40لهذا السبب فإن تفرع سير العمل وتحديد نطاق الأسرار ليست مجرد مواضيع متقدمة
- 16:45إنها شبكة الأمان التي تمنع أتمتتك من الانهيار بصمت
- 16:48هناك أيضا قيمة في تقسيم سير العمل ليس فقط حسب البيئة ولكن حسب المسئولية
- 16:54الكود الذي يصدر ويتحقق من الحلول لا ينبغي حتى أن يعرف كيفية النشر أو تبديل الأسرار
- 16:59إذا كانت كل مهمة تتعامل مع جزء واحد من اللغز يصبح من الأسهل بكثير تحديد مكان حدوث الخطأ والتراجع وتدقيق التغييرات بعد وقوعها
- 17:08تبقى الأسرار في مخازنها وتتبع المهام أذونة محددة النطاق بوضوح
- 17:12وتشير إخفقات خط الأنابيب مباشرة إلى الجزء الذي يحتاج إلى إصلاح
- 17:16فهم كيفية تسليم جيتهب أكشونز العمل من مهمة إلى أخرى مع الحفاظ على الأسرار ضمن نطاق ضيق والمشغلات محددة بوضوح
- 17:23هو ما ينقل أم من تجربة قائمة على الأمل إلى ممارسة موثوقة وآمنة وقابلة للتنبؤ
- 17:28تقسيم سير العمل هذا ليس مجرد مسألة لمطابقة أفضل الممارسات
- 17:33إنه ما يمنع التسريبات الأمنية الهادئة والتجاوزات غير المقصودة
- 17:37ويقطع دابر فئة كاملة من الأخطاء غير المرئية قبل أن تبدأ في إزعاج بيئاتك
- 17:42الآن ومع عمل الأجزاء معا من خلال أتمتة محددة النطاق بشكل صحيح
- 17:46حان الوقت لمعالجة نقطة احتكاك أخرى
- 17:49الموصلات ومبادئ الخدمة والمزالق الصغيرة ولكن الحاسمة التي قد تعيق عمليات النشر بمجرد شعورك بالثقة
- 17:56مبادئ الخدمة السرية والمشاكل المتعلقة بالموصلات
- 17:59إذا حاولت يوما نقل تطبيق باور أب أو تدفق فلو من بيئة التطوير إلى بيئة الإنتاج
- 18:04فأنت تعرف القصة
- 18:05تعمل الأمور بسلاسة في بيئة واحدة
- 18:07ثم بمجرد التبديل يتوقف كل شيء أو تظهر لك تلك الأخطاء الغامضة في الاتصال
- 18:12هذا الأمر ليس مقتصرا على فريق معين
- 18:15كل مسؤول في باور بلاتفورم يصطدم بهذا الجدار في نهاية المطاف
- 18:19يكمن أصل المشكلة في كيفية عمل الموصلات والأسرار خلف الكواليس
- 18:24لا يمكنك ببساطة تصدير ملف حل مضغوط من التطوير وتوقع عمله في مكان آخر
- 18:29لأن الروابط التي يعتمد عليها تتغير مع كل بيئة
- 18:32لنأخذ مراجع الموصلات كمثال
- 18:35في باور بلاتفورم لا يعد الموصل مجرد جزء ثابت من المعلومات المضمنة في تطبيقك
- 18:40إنه ديناميكي وقابل للتغيير وغالبا ما يكون فريدا لكل بيئة
- 18:43عند تصدير الحل الخاص بك تعمل مراجع الموصلات تقريبا مثل العلامات المرجعية
- 18:48فهي تشير إلى كائنات اتصال لا توجد إلا في البيئة التي أنشئت فيها
- 18:52لذا عند الاستيراد إلى بيئة الاختبار أو الانتاج
- 18:54لا تتم إعادة إنشاء نقطة نهاية HTTP أو رابط Dataverse
- 18:57الخاص بك بالضرورة بنفس الطريقة أو قد لا يتم إنشاؤه على الإطلاق
- 19:00هنا يقع الكثير من الفرق في الفخ
- 19:03إذا كان التطوير يستخدم موصلنا لاختبار البيانات
- 19:06ولم يتم عكس ذلك الإعداد بدقة في الانتاج
- 19:09فسيفشل التدفق أو التطبيق بصمت أو يتوقف عند محاولة الاتصال الأولى
- 19:15يحاول الكثير من الأشخاص الالتفاف على هذا بمشاركة بيانات اعتماد المستخدم عبر البيئات
- 19:20يعتقدون أنه إذا استخدمت نفس الحساب أو كلمة المرور التي أنشأت الاتصال في التطوير
- 19:25فربما سيعمل في الانتاج
- 19:27الواقع هو أن هذا يجلب مجموعة من المشاكل
- 19:29بدءا من رفض الأدونات وصولا إلى تشغيل عمليات تدقيق الامتثال
- 19:32توجيهات مايكروسوفت واضحة
- 19:34فاستخدام بيانات اعتماد المستخدم الفردية لعمليات النشر الألية ليس عمليا أو آمنا
- 19:38إنه يضع أتمتتك تحت رحمة تغييرات كلمة المرور وقد يترك أثرا غير واضح في سجلات التدقيق الخاصة بك
- 19:44لا توجد مساءلة واضحة
- 19:46وفي النهاية تحضر الأدونات مسار العمل عندما يتم تمييز المستخدم الأصلي أو إزالته أو فقدان وصوله
- 19:52هنا يأتي دور مبادئ الخدمة
- 19:54إذا لم تعمل بها من قبل
- 19:57تخيل مبدأ الخدمة كيد رقمية إضافية مصممة خصصا للأتمتة
- 20:01على عكس المستخدم العادي يرتبط مبدأ الخدمة بتسجيل تطبيق في أشر أيدي
- 20:06وليس بشخص حقيقي أن تمنحه الحد الأدنى من الأذونات اللازمة لتنفيذ مهام النشر الخاصة بك
- 20:12يبدو الأمر بسيطا لكن المكاسب كبيرة
- 20:15بدلا من الاعتماد على مستخدم قد يغادر المؤسسة أو يغير أدوارا وظيفية
- 20:18تظل عمليات النشر متسقة وقابلة للتدقيق والتتبع
- 20:21تحصل كل بيئة على صلاحية الوصول إلى الموارد والاتصالات الصحيحة فقط
- 20:25ويتم تسجيل أي تغييرات تحت هذا الحساب الآلي
- 20:28عند حدوث فشل يكون لديك سجل تدقيق واضح
- 20:31ولن ينتهي بك الأمر بوجود تدفقات مهجورة لا يمكن لأحد إصلاحها
- 20:34بخصوص مشكلة تعيين المواصلات
- 20:36فكر فيما يحدث عندما تتباعد البيئات عن بعضها البعض
- 20:40ربما حصل فريق التطوير على موافقة لاستخدام موصل مخصص جديد
- 20:43لنفترض أنه يتصل بواجهة برمجة تطبيقات تجريبية
- 20:45عندما يحين وقت الانتقال إلى بيئة الإنتاج
- 20:48لا يكون هذا الموصل مفقودا فحسبه
- 20:50بل قد لا تسمح به سياسات البيانات المؤسسية
- 20:52إذا نسيت إعادة التعيين
- 20:54فسيقوم التطبيق بالاتصال بنقطة نهاية خاطئة أو يتعطل تماما
- 20:58رأيت هذا الأمر يتسبب في مشاكل كبيرة في مجموعة رعاية صحية مؤخرا
- 21:01تسبب تعيين خاطئ لأحد المواصلات في استخدام بيانات اختبار في بيئة الإنتاج
- 21:05وكاد أن يتسبب في خرق لسياسات الانتثال
- 21:07قامت خطة العمل المؤتمتة الخاصة بهم بتصدير كل شيء كما هو مخطط
- 21:10لكن مرجع الموصل داخل الحل كان لا يزال يشير إلى قاعدة بيانات اختبار قديمة
- 21:15لم يتم رصدها بواسطة باور بلاتفورم
- 21:16حتى بدأت البيانات الحقيقية تتدفق عبر المسارات الخاطئة
- 21:19تتدخل متغيرات البيئة لتخفيف بعض هذه المعاناة
- 21:23على عكس الترميز الثابت لنقاط النهاية أو مفاتيح واجهة البرمجة
- 21:26تسمح لك متغيرات البيئة بفصل ما يتغير عبر البيئات عما يظل ثابتا
- 21:30يمكنك استبدال نقاط النهاية أو مفاتيح واجهة البرمجة أو الأسرار الأخرى
- 21:34مع كل عملية نشر دون الحاجة إلى إعادة كتابة تطبيقك أو تدفق العمل
- 21:37على سبيل المثال يمكن إعادة تهيئة تدفق يعمل مع جدول ديتا فيرس
- 21:41للتطوير عند الاستيراد ليستخدم جدول الانتاج ببساطة عن طريق تغيير متغير البيئة
- 21:46داخل عملية النشر الخاصة بك
- 21:47تعد خطوط أنابيبي جيت هاب أكشونز هذا الأمر عمليا
- 21:50يمكن لكل مهمة إدراج القيمة الصحيحة في الوقت المناسب
- 21:53ولكن حتى هنا الانضباط هو المفتاح
- 21:56إذا نسيت تحديث متغير أو سمحت بتسرب الأسرار عبر البيئات
- 22:00فسيصبح سير عملك مكشوفا فجأة
- 22:03تؤكد مايكروسوفت على ضرورة تحديد نطاق الأسرار بعناية وتعيين مراجع الموصلات بشكل مقصود
- 22:09سياسات منع فقدان البيانات
- 22:11دي أل بي
- 22:12موجودة لسبب وهو منع المعلومات الحساسة من التنقل بين البيئات أو الظهور في المكان الخطأ
- 22:18إذا حاولت تجاوز هذه السياسات بمشاركة المتغيرات أو الاتصالات
- 22:22فستصطدم بضوابط الأمن أو الامتثال المؤسسيات
- 22:26والأهم من ذلك أنك تفقد القدرة على التنبؤ
- 22:28لأنه لم يعد هناك خط فاصل بين ما هو مخصص للتطوير وما هو مخصص للاختبار أو الإنتاج
- 22:33من الصعب المبالغة في تقدير الفائدة التي تحصل عليها عندما تقوم بكل هذا بشكل صحيح
- 22:36تغير مبادئ الخدمة
- 22:37جنبنا إلى جنب مع متغيرات البيئة المدارة جيدا والمواصلات المعينة بدقة من مسار عملك
- 22:42تصبح عمليات النشر الخاصة بك قابلة للتنبؤ
- 22:45عندما تتعطل الأمور يكون لديك سلسلة عهدة واضحة وتعرف بالضبط أين تبحث
- 22:49هل كان السبب في تعيين الموصل أم متغيرا أم إذنا مفقودا
- 22:52يمكن للمدقيقين تتبع التغييرات ولا يوجد أي قلق عندما يغادر شخص ما المؤسسة أو يغير كلمات المرور
- 22:57كل الأمر يعود إلى التعامل مع الأسرار والمواصلات ومبادئ الخدمة كما لو كانت ذات أهمية بالغة
- 23:02اشتركوا في القناة