مِخبارMIKHBAR
التطبيقات والبرامج

GitHub يحدّث فرض الإعدادات المُدارة للمؤسسات

أعلنت GitHub تحديثات جديدة لآلية فرض الإعدادات المُدارة في عملاء Copilot، بما يمنح مسؤولي المؤسسات تحكماً أكبر في توقيت تطبيق السياسات. وتشمل التحديثات إلزام العملاء بجلب الإعدادات الحديثة عند بدء التشغيل وفرض حد أدنى لإصدار العميل ضمن مفتاح البيئة المعزولة.

GitHub يحدّث فرض الإعدادات المُدارة للمؤسسات

تحديث الإعدادات عند بدء التشغيل

أعلنت GitHub تحديثاً يتيح لمسؤولي المؤسسات مطالبة عملاء GitHub Copilot المدعومين بجلب الإعدادات المُدارة الحالية من الخادم عند بدء التشغيل، بدلاً من الاعتماد تلقائياً على سياسة مخزنة مؤقتاً. ويستهدف هذا التغيير الحالات التي تحتاج فيها المؤسسة إلى أن تدخل تعديلات السياسة حيّز التنفيذ قبل تشغيل Copilot، لا بعد انتهاء عملية بدء التشغيل أو عند تحديث البيانات المخزنة في وقت لاحق. ويمكن الرجوع إلى GitHub Changelog للاطلاع على التفاصيل الأصلية للمصدر.

يتحقق السلوك الجديد عبر الإعداد forceRemoteSettingsRefresh، الذي يمكن ضبطه على القيمة true من خلال الإعدادات المُدارة من الخادم، أو إعدادات إدارة الأجهزة المحمولة MDM، أو ملفات الإعداد. وعند تفعيل هذا الخيار، يصبح الحصول على سياسة حديثة جزءاً من متطلبات بدء تشغيل العميل، بدلاً من اعتبار النسخة المؤقتة كافية في كل مرة. ويمكن الرجوع إلى Back to changelog للاطلاع على التفاصيل الأصلية للمصدر.

نطاق الدعم وطرق التوزيع

يدعم الإعداد forceRemoteSettingsRefresh حالياً ثلاثة من عملاء Copilot المذكورين في الإعلان: Copilot CLI، وCopilot في VS Code، وتطبيق GitHub Copilot. وهذا يعني أن مسؤولي المؤسسات يستطيعون تطبيق متطلب حداثة الإعدادات على هذه البيئات عندما تكون سرعة انعكاس تغييرات السياسة أهم من الاستفادة من آلية التخزين المؤقت المعتادة.

تختلف نقطة بدء التحقق بحسب طريقة توزيع الإعداد. فالإعدادات التي تُسلَّم عبر MDM أو عبر ملف يمكنها طلب حداثة السياسة قبل تسجيل العميل دخوله للمرة الأولى. أما القيمة التي تصل من الإعدادات المُدارة من الخادم، فتبدأ في طلب التحديث عند مرات بدء التشغيل اللاحقة بعد أن يكون العميل قد تلقاها مرة واحدة. وتوضح GitHub تفاصيل التطبيق في دليل [Deploying enterprise managed settings](https://docs.github.com/enterprise-cloud@latest/copilot/how-tos/administer-copilot/manage-for-enterprise/use-managed-settings/deploy-managed-settings#requiring-fresh-server-managed-settings-on-startup)، بما في ذلك موضع هذا المتطلب ضمن إعدادات المؤسسة.

أثناء تفعيل الخيار، لا يمكن للاستجابة المخزنة مؤقتاً أن تفي بشرط الحداثة. وإذا لم يستطع العميل تأكيد السياسة الحالية، فإنه يتوقف عن العمل بدلاً من المتابعة بسياسة قديمة أو غير مؤكدة. وتصف GitHub هذا السلوك بأنه إغلاق آمن، إذ يمنع تشغيل Copilot عندما لا تتوافر للمؤسسة وسيلة للتأكد من أن الإعدادات المطبقة هي الأحدث.

موازنة الحداثة مع استمرارية التشغيل

لا يؤدي التحديث إلى إلغاء التخزين المؤقت للإعدادات المُدارة في جميع الحالات. فعندما لا يفعّل المسؤولون forceRemoteSettingsRefresh، يستمر العملاء في استخدام آلية التخزين المؤقت المعتادة. وتمنح هذه الآلية بدء تشغيل أسرع وقدرة أكبر على الاستمرار خلال الأعطال المؤقتة في الخدمة، وفقاً لما أعلنته GitHub.

وبذلك يصبح أمام مسؤولي المؤسسات خيار واضح بين سلوكين تشغيليين: الاعتماد على النسخة المخزنة مؤقتاً لتحسين سرعة البدء وتحمل الانقطاعات العابرة، أو فرض جلب السياسة من الخادم عندما يجب أن تصل تغييرات الحوكمة إلى العميل قبل أن يبدأ Copilot. ولا يذكر الإعلان أن الخيار الثاني مفعّل تلقائياً، بل يربطه صراحة بضبط الإعداد على القيمة true عبر إحدى قنوات الإدارة المدعومة.

وتكتسب هذه الآلية أهمية خاصة في السياسات التي لا ينبغي أن يتأخر تطبيقها إلى أن تنتهي صلاحية البيانات المؤقتة أو ينجح العميل في تحديثها لاحقاً. وفي المقابل، يوضح سلوك الإغلاق الآمن أن تعذر تأكيد السياسة قد يمنع استخدام Copilot، بدلاً من توفير مسار احتياطي يعتمد على معلومات غير حديثة.

حد أدنى لإصدار العميل مع sandbox

تضيف GitHub أيضاً إنفاذاً لشرط الحد الأدنى لإصدار العميل ضمن مفتاح sandbox في الإعدادات المُدارة. ويأتي هذا التغيير دعماً للقدرة المحلية المعزولة، التي أصبحت متاحة عموماً، ويبدأ بذلك إدخال متطلبات الحد الأدنى للإصدار تدريجياً إلى مفاتيح الإعدادات المُدارة المرتبطة بالحوكمة.

عندما يتضمن إعداد مُدار مفتاح sandbox مع شرط إصدار أدنى، فإن المستخدمين الذين يثبتون عملاء Copilot على إصدارات أقدم سيُجبرون على التحديث كي يستأنفوا استخدام Copilot. ولا يقتصر الأمر هنا على تنبيه اختياري أو توصية بالترقية؛ فالشرط، بحسب الإعلان، يمنع استئناف الاستخدام إلى أن يعمل العميل بإصدار يطابق الحد المطلوب.

يمكن لمسؤولي المؤسسات الرجوع إلى صفحة [required minimum client version](https://docs.github.com/en/enterprise-cloud@latest/copilot/reference/enterprise-administrators/enterprise-managed-settings#minimum-client-version-enforcement-for-sandbox) لمعرفة تفاصيل إنفاذ الإصدار الأدنى لمفتاح sandbox. ويحدد الإعلان هذا المفتاح باعتباره نقطة البداية لهذه المتطلبات، من دون إعلان أن جميع مفاتيح الحوكمة الأخرى تخضع للشرط نفسه في الوقت الحالي.

ما الذي يعنيه التحديث للمؤسسات؟

يمنح التحديث مسؤولي المؤسسات وسيلة إضافية للتحكم في العلاقة بين تغييرات السياسة وإصدارات العملاء. ففرض جلب الإعدادات عند بدء التشغيل يعالج مشكلة العمل بإعداد قديم، بينما يعالج شرط الإصدار الأدنى مشكلة استخدام قدرة حوكمية أو محلية من خلال عميل لا يفي بمتطلبات المؤسسة.

عملياً، تحتاج الفرق الإدارية إلى تحديد السياسات التي تتطلب تأكيداً فورياً من الخادم، ثم اختيار قناة التوزيع المناسبة وتفعيل forceRemoteSettingsRefresh عند الحاجة. كما ينبغي أن تضع في الحسبان أن تعذر الوصول إلى السياسة الحالية قد يؤدي إلى توقف العميل، وأن فرض إصدار أدنى قد يمنع المستخدمين من العودة إلى Copilot قبل تحديث برامجهم.

وتدعو GitHub المهتمين بالتفاصيل أو بالحالات التشغيلية المختلفة إلى متابعة النقاش في [GitHub Community](https://github.com/orgs/community/discussions/199139). ويظل جوهر التغيير، وفق المعلومات المنشورة، هو جعل حداثة الإعدادات وإصدار العميل متطلبين قابلين للفرض في سياقات مؤسسية محددة، مع الإبقاء على السلوك المؤقت المعتاد عندما لا يختار المسؤولون تشديد هذه القيود.

المصادر

تابع التسلسل الزمني

تغطية الكيانات المرتبطة