Devops | The .NET Blog

تصحيح Azure DevOps Server لشهر أبريل 2026 — إصلاح اكتمال طلبات السحب وتحديثات الأمان

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

تنبيه سريع للفرق التي تشغل Azure DevOps Server المستضاف ذاتياً: أصدرت Microsoft التصحيح 3 لشهر أبريل 2026 مع ثلاثة إصلاحات محددة.

ما الذي تم إصلاحه

فشل اكتمال طلبات السحب — كان استثناء مرجع فارغ أثناء الإكمال التلقائي لعناصر العمل يتسبب في فشل دمج طلبات السحب. إذا كنت تواجه أخطاء عشوائية في اكتمال طلبات السحب، فهذا هو السبب على الأرجح
التحقق من إعادة توجيه تسجيل الخروج — تحسين التحقق أثناء تسجيل الخروج لمنع عمليات إعادة التوجيه الخبيثة المحتملة. هذا إصلاح أمني يستحق التطبيق الفوري
اتصالات PAT بـ GitHub Enterprise Server — كان إنشاء اتصالات رمز الوصول الشخصي بـ GitHub Enterprise Server معطوباً، وقد تم استعادته الآن

كيفية التحديث

نزّل التصحيح 3 وشغّل المثبت. للتحقق من تطبيق التصحيح:

<patch-installer>.exe CheckInstall

إذا كنت تشغّل Azure DevOps Server محلياً، توصي Microsoft بشدة بالبقاء على آخر تصحيح للأمان والموثوقية معاً. راجع ملاحظات الإصدار للتفاصيل الكاملة.

هندسة المنصات الوكيلية تصبح حقيقة — Git-APE يُظهر كيف

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

كانت هندسة المنصات من تلك المصطلحات التي تبدو رائعة في محادثات المؤتمرات لكنها عادةً ما تعني “أنشأنا بوابة داخلية وغلافاً لـ Terraform.” الوعد الحقيقي — بنية تحتية ذاتية الخدمة آمنة فعلاً ومُحكَّمة وسريعة — كانت دائماً على بُعد خطوات.

نشر فريق Azure للتو الجزء الثاني من سلسلة هندسة المنصات الوكيلية، وهذا الجزء يتعلق بالتطبيق العملي. يطلقون عليه Git-APE (نعم، الاختصار مقصود)، وهو مشروع مفتوح المصدر يستخدم وكلاء GitHub Copilot بالإضافة إلى خوادم Azure MCP لتحويل الطلبات باللغة الطبيعية إلى بنية تحتية مُتحقَّق منها ومنشورة.

ما الذي يفعله Git-APE فعلاً

الفكرة الجوهرية: بدلاً من تعلّم المطوّرين وحدات Terraform، أو التنقل في واجهات المستخدم للبوابات، أو تقديم تذاكر إلى فريق المنصة، يتحدثون مع وكيل Copilot. يفسّر الوكيل النية، ويولّد البنية التحتية كأكواد، ويتحقق منها مقابل السياسات، وينشر — كل ذلك داخل VS Code.

إليك الإعداد:

git clone https://github.com/Azure/git-ape
cd git-ape

افتح مساحة العمل في VS Code، وتُكتشف ملفات إعداد الوكيل تلقائياً بواسطة GitHub Copilot. تتفاعل مع الوكيل مباشرةً:

@git-ape deploy a function app with storage in West Europe

يستخدم الوكيل Azure MCP Server خلف الكواليس للتفاعل مع خدمات Azure. يُمكّن إعداد MCP في إعدادات VS Code قدرات محددة:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

لماذا يهمّ هذا

لمن يبنون على Azure، يحوّل هذا محادثة هندسة المنصات من “كيف نبني بوابة” إلى “كيف نصف حواجز الحماية كواجهات برمجية.” حين تكون واجهة منصتك وكيل ذكاء اصطناعي، تصبح جودة قيودك وسياساتك هي المنتج.

وضع الجزء الأول من المدوّنة النظرية: الواجهات البرمجية الموصوفة جيداً، ومخططات التحكم، وحواجز الحماية الصريحة تجعل المنصات جاهزة للوكلاء. يُثبت الجزء الثاني أنها تعمل من خلال شحن أدوات فعلية. الوكيل لا يولّد الموارد بشكل أعمى — بل يتحقق مقابل أفضل الممارسات، ويحترم اصطلاحات التسمية، ويطبّق سياسات مؤسستك.

التنظيف بسيط بالقدر نفسه:

@git-ape destroy my-resource-group

رأيي

لأكن صريحاً — هذا يتعلق بالنمط أكثر من الأداة المحددة. Git-APE نفسه هو بنية مرجعية/توضيحية. لكن الفكرة الكامنة — الوكلاء كواجهة لمنصتك، وMCP كبروتوكول، وGitHub Copilot كمضيف — هي وجهة تجربة المطوّر في المؤسسات.

إذا كنت فريق منصة تبحث عن كيفية جعل أدواتك الداخلية صديقةً للوكلاء، فلا يوجد نقطة بداية أفضل. وإذا كنت مطوّر .NET تتساءل عن كيفية ارتباط هذا بعالمك: يعمل Azure MCP Server ووكلاء GitHub Copilot مع أي عبء عمل على Azure. واجهة برمجة ASP.NET Core، ومكدّس .NET Aspire، والخدمات المُعبّأة في حاويات — كل ذلك يمكن أن يكون هدفاً لتدفق نشر وكيلي.

خلاصة القول

Git-APE هو نظرة مبكرة لكن ملموسة على هندسة المنصات الوكيلية في التطبيق. استنسخ المستودع، وجرّب العرض التوضيحي، وابدأ في التفكير في كيفية احتياج واجهات برمجية منصتك وسياساتها للظهور حتى يستطيع الوكيل استخدامها بأمان.

اقرأ المقال الكامل للشرح التفصيلي والعروض التوضيحية المرئية.

Azure DevOps يُصلح أخيراً تجربة مستخدم محرر Markdown التي اشتكى منها الجميع

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

إذا كنت تستخدم Azure Boards، فمن المرجح أنك مررت بهذا الموقف: تقرأ وصف عنصر عمل، ربما تراجع معايير القبول، ثم تنقر نقراً مزدوجاً عن طريق الخطأ. فجأة — أنت في وضع التحرير. لم تكن تريد تحرير أي شيء. كنت فقط تقرأ.

أعلن Dan Hellem عن هذا الإصلاح، وهو من التغييرات التي تبدو صغيرة لكنها تزيل احتكاكاً حقيقياً من سير عملك اليومي.

ما الذي تغيّر

يفتح محرر Markdown لحقول نص عناصر العمل الآن في وضع المعاينة افتراضياً. يمكنك قراءة المحتوى والتفاعل معه — اتباع الروابط ومراجعة التنسيق — دون القلق من الدخول إلى وضع التحرير عن طريق الخطأ.

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

هذا هو التغيير. هذا كل شيء.

لماذا هذا أهم مما يبدو

كان سلسلة ملاحظات المجتمع حول هذا الأمر طويلاً. جرى تقديم سلوك النقر المزدوج للتحرير مع محرر Markdown في يوليو 2025، وبدأت الشكاوى فوراً تقريباً. لم تكن المشكلة مجرد تعديلات غير مقصودة — بل كان التفاعل كله يبدو غير قابل للتنبؤ. لم تكن تعرف أبداً إذا كان النقر سيضعك في وضع القراءة أم التحرير.

بالنسبة للفرق التي تُجري تخطيط السبرينت، أو تنقية قائمة المهام المتراكمة، أو مراجعة الكود باستخدام Azure Boards، يتراكم هذا الاحتكاك الصغير. كل دخول غير مقصود إلى وضع التحرير يعني تحولاً في السياق. وكل لحظة “انتظر، هل غيّرت شيئاً؟” هي انتباه مُهدَر.

السلوك الافتراضي الجديد يحترم نمط التفاعل الأكثر شيوعاً: فأنت تقرأ عناصر العمل أكثر بكثير مما تحررها.

حالة الإطلاق

هذا التغيير بدأ بالانتشار لدى مجموعة من المستخدمين ويتوسع ليشمل الجميع خلال الأسبوعين إلى الثلاثة أسابيع القادمة. إذا لم تكن قد رأيته بعد، فستراه قريباً.

خلاصة القول

لا تحتاج كل تحسينات البرامج إلى أن تكون ميزة بارزة في العناوين. أحياناً أفضل تحديث هو إزالة شيء مزعج. هذا واحد منها — إصلاح صغير لتجربة المستخدم يجعل Azure Boards أقل إزعاجاً للأشخاص الذين يريدون فقط قراءة عناصر عملهم بهدوء.

خادم Azure DevOps MCP يصل إلى Microsoft Foundry: ما الذي يعنيه هذا لوكلاء الذكاء الاصطناعي لديك

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

يمر MCP (بروتوكول سياق النموذج) بلحظته المميزة. إذا كنت تتابع منظومة وكلاء الذكاء الاصطناعي، فلاحظت على الأرجح انتشار خوادم MCP في كل مكان — حيث تمنح الوكلاء القدرة على التفاعل مع الأدوات والخدمات الخارجية من خلال بروتوكول موحد.

الآن أصبح خادم Azure DevOps MCP متاحاً في Microsoft Foundry، وهذه من التكاملات التي تجعلك تفكر في الإمكانات العملية.

ما الذي يحدث فعلاً

أصدرت Microsoft بالفعل خادم Azure DevOps MCP كـمعاينة عامة — ذلك هو الخادم نفسه. الجديد هو التكامل مع Foundry. يمكنك الآن إضافة خادم Azure DevOps MCP إلى وكلاء Foundry مباشرةً من كتالوج الأدوات.

لمن لم يتعرف على Foundry بعد: إنها المنصة الموحدة من Microsoft لبناء وإدارة التطبيقات والوكلاء المدعومة بالذكاء الاصطناعي على نطاق واسع. الوصول إلى النماذج، والتنسيق، والتقييم، والنشر — كل ذلك في مكان واحد.

كيفية الإعداد

الإعداد مباشر بشكل مفاجئ:

في وكيل Foundry الخاص بك، انتقل إلى Add Tools > Catalog
ابحث عن “Azure DevOps”
اختر Azure DevOps MCP Server (preview) وانقر Create
أدخل اسم مؤسستك وتواصل

هذا كل شيء. الوكيل لديك الآن وصول إلى أدوات Azure DevOps.

التحكم في ما يمكن للوكيل الوصول إليه

هذا هو الجانب الذي أقدره: لست مقيداً بنهج “الكل أو لا شيء”. يمكنك تحديد الأدوات المتاحة لوكيلك. لذا إذا أردته فقط قراءة عناصر العمل دون لمس المسارات، يمكنك ضبط ذلك. مبدأ الصلاحية الأدنى، مطبقاً على وكلاء الذكاء الاصطناعي لديك.

هذا مهم في سيناريوهات المؤسسات حيث لا تريد أن يُشغّل الوكيل مسار نشر بالخطأ لأن أحدهم طلب منه “المساعدة في الإصدار”.

لماذا هذا مثير للاهتمام لفرق .NET

فكر في ما يتيحه هذا عملياً:

مساعدو تخطيط السبرينت — وكلاء يسحبون عناصر العمل ويحللون بيانات السرعة ويقترحون سعة السبرينت
بوتات مراجعة الكود — وكلاء يفهمون سياق طلب السحب الخاص بك لأنهم يستطيعون فعلاً قراءة المستودعات وعناصر العمل المرتبطة
الاستجابة للحوادث — وكلاء يمكنهم إنشاء عناصر عمل والاستعلام عن النشرات الأخيرة وربط الأخطاء بالتغييرات الأخيرة
تأهيل المطورين — “ما الذي يجب أن أعمل عليه؟” تحصل على إجابة حقيقية مستندة إلى بيانات المشروع الفعلية

بالنسبة لفرق .NET التي تستخدم بالفعل Azure DevOps لمسارات CI/CD وإدارة المشاريع، فإن امتلاك وكيل ذكاء اصطناعي يمكنه التفاعل مع تلك الأنظمة مباشرةً خطوة مهمة نحو أتمتة مفيدة حقيقية (وليس مجرد روبوت محادثة كخدمة).

الصورة الأكبر لـ MCP

هذا جزء من اتجاه أوسع: تصبح خوادم MCP الطريقة المعيارية التي تتفاعل بها وكلاء الذكاء الاصطناعي مع العالم الخارجي. نراها لـ GitHub وAzure DevOps وقواعد البيانات وواجهات برمجية SaaS — وتصبح Foundry المحور الذي تجتمع فيه هذه الاتصالات.

إذا كنت تبني وكلاء في منظومة .NET، فإن MCP يستحق الاهتمام. البروتوكول موحد، والأدوات تنضج، وتكامل Foundry يجعله في متناول يدك دون الحاجة إلى توصيل خوادم يدوياً.

خلاصة القول

خادم Azure DevOps MCP في Foundry في مرحلة المعاينة، لذا توقع أن يتطور. لكن سير العمل الأساسي متين: اتصل، وضبط وصول الأدوات، واترك وكلاءك يعملون مع بيانات DevOps الخاصة بك. إذا كنت بالفعل في منظومة Foundry، فهذا على بُعد بضع نقرات. جربه وانظر إلى سير العمل التي يمكنك بناؤها.

اطلع على الإعلان الكامل للحصول على خطوات الإعداد التفصيلية والمزيد من المعلومات.