https://thedotnetblog.com/ar/tags/ci-cd/Articles, tutorials and insights from the .NET community.Hugoar@thedotnetblog (The .NET Blog)@thedotnetblogSat, 18 Jul 2026 00:00:00 +0000https://thedotnetblog.com/ar/news/emiliano-montesdeoca/mcp-binlog-ci-build-diagnostics/Sat, 18 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ar/news/emiliano-montesdeoca/mcp-binlog-ci-build-diagnostics/عندما يعمل تحليل MCP لـ Binlog مباشرة في سير عمل طلبات السحب، تقلل الفرق وقت فرز الفشل وتسرع المطورين.<p>المصدر الأصلي: <a href="https://devblogs.microsoft.com/dotnet/mcp-build-diagnostics-workflows/">MCP Beyond the Chat Window: Build Diagnostics in CI</a></p> <p>هذه واحدة من أقوى قصص MCP العملية حتى الآن لأنها تترك عالم عروض الدردشة وتدخل واقع خط الأنابيب.</p> <p>النمط الموضح مقنع: فشل بناء PR يطلق تحليل الوكيل ضد binlog عبر MCP، ثم سير العمل ينشر سياق السبب الجذري القابل للتنفيذ مرة أخرى إلى طلب السحب. هذا هو بالضبط حيث يُهدر وقت المطور اليوم.</p> <p>معظم الفرق لا تزال تتعامل مع البناء الأحمر بحلقات يدوية مكلفة:</p> <ul> <li>تحميل binlog.</li> <li>فتح العارض.</li> <li>تتبع الهدف والمهمة الفاشلة.</li> <li>ترجمة النتائج للمراجعين.</li> </ul> <p>أدوات MCP القائمة على binlog تضغط تلك الحلقة وتجعل التحليل متاحًا لكل مساهم، وليس فقط خبير البناء المناوب.</p> <p>موقف الاستشارة فقط في سير العمل هو أيضًا خيار معماري ذكي. حافظ على دمج البوابة مع بنائك الحالي المطلوب، واستخدم تشخيصات الوكيل كتسريع وليس كسلطة. هذا يحافظ على الثقة مع الاستمرار في جني مكاسب الإنتاجية.</p> <p>سطح الأداة الموسع ملحوظ. استدلال الهدف، وخصائص التقييم، وتحليلات تكلفة المحلل، ورسوم بيانية للمسار الحرج، وتحليل الاستعادة، وفحص السلوك التزايدي — كلها بالضبط نوع التشخيصات المنظمة التي تتعامل معها نماذج اللغة بشكل جيد عندما تُعرض عبر أدوات دقيقة.</p> <p>رأيي الشخصي: هذا هو المكان الذي يصبح فيه AI في الهندسة بنية تحتية بالفعل. إذا كانت القدرة تقلل بشكل موثوق متوسط الوقت لشرح فشل البناء دون إضافة استقلالية محفوفة بالمخاطر، فهي تنتمي إلى CI افتراضيًا.</p> <p>بيانات التقييم تقوي الحجة. نتائج أفضل مع وقت مادي أقل واستخدام رموز أقل مقارنة بخطوط الأساس بدون أدوات تشير إلى أن مكاسب الإنتاجية ليست قصصية.</p> <p>خطة طرح عملية لفرق .NET:</p> <ul> <li>اجعل إنشاء /bl قياسيًا في CI لوظائف البناء والاختبار ذات الصلة.</li> <li>قدم تعليقات تشخيص MCP في مستودع غير حرج أولاً.</li> <li>تتبع مقاييس وقت الفرز ومعدل التفسير الإيجابي الكاذب.</li> <li>وسع فقط بعد إثبات جودة التعليق وقبول المطور.</li> </ul> <p>تحذير واحد: تعامل مع قدرات الأداة كعقود مُرقمة. أسطح الخادم تتطور، وموثوقية سير العمل تعتمد على فحوصات التوافق الصريحة. أدوات اكتشاف القدرات يجب أن تكون جزءًا من إعداد خط الأنابيب الخاص بك.</p> <p>إذا كانت مؤسستك تبحث عن نقطة اعتماد AI عالية الثقة في توصيل البرمجيات، فهذه هي. إنها محدودة وقابلة للقياس ومرتبطة مباشرة بوقت دورة المطور.</p> <p>MCP هنا ليس طبقة جديدة. إنه ناقل للذكاء التشغيلي المنظم، وخطوط أنابيب البناء هي مكان مثالي لاستغلاله.</p>https://thedotnetblog.com/ar/news/emiliano-montesdeoca/azd-may-june-2026-operational-upgrades/Tue, 14 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ar/news/emiliano-montesdeoca/azd-may-june-2026-operational-upgrades/تركز دورة azd الأخيرة بشكل أقل على الأوامر البراقة وأكثر على تقليل فوضى النشر في الفرق الحقيقية.<p>المصدر الأصلي: <a href="https://devblogs.microsoft.com/azure-sdk/azure-developer-cli-azd-may-june-2026/">Azure Developer CLI (azd) – May and June 2026</a></p> <p>تسعة إصدارات في شهرين قد تبدو فوضوية، لكن هذه الدفعة من azd تحمل خيطًا واضحًا: إزالة الحواف الهشة التي تحرق الفرق في بيئات CI وعمليات النشر متعددة الخدمات.</p> <p>الميزة الرئيسية بالنسبة لي ليست مجرد أداة azd. بل هي القرار المنتج بمعالجة المتطلبات الأساسية كحالة عمل من الدرجة الأولى في سير العمل. عمليًا، العديد من حالات فشل النشر السحابي ليست فشلاً في البنية التحتية. إنها بيئات محلية و CI غير متناسقة. عندما تستطيع CLI اكتشاف وتثبيت والتحقق من الأدوات المطلوبة مباشرة، تقلل الفرق أحد أكبر مصادر الاحتكاك المسببة للفشل.</p> <p>الفوز الكبير الثاني هو azd exec. هذا مهم لأن نصوص النشر غالبًا ما تبتعد عن سياق البيئة، خاصة مع حل الأسرار ونشر المتغيرات. منصة تشغيل عبر الأنظمة ترث بيئة azd الكاملة تقلل هذا الانجراف وتجعل النصوص أكثر موثوقية.</p> <p>إصلاحات التزامن تستحق اهتمامًا خاصًا. تلوث الصور عبر الخدمات في عمليات نشر Container Apps المتزامنة هو بالضبط نوع الخلل الذي يدمر الثقة في الأتمتة. لا يمكنك التبشير بهندسة المنصات بينما خط أنابيبك يرسل أحيانًا الصورة الخاطئة إلى الخدمة الخاطئة. حقيقة أن هذه الموجة من الإصدارات عالجت تلك السباقات البيانية هي أهم من معظم الميزات الجديدة.</p> <p>توصيتي العملية لفرق المنصات:</p> <ul> <li>اعتماد فحص أداة azd كخطوة إلزامية قبل CI.</li> <li>مراجعة أي محللات مخصصة أو فحوصات regex مرتبطة بمخرجات azd up القديمة لأن نموذج التقدم الموحد هو تغيير جذري في السلوك.</li> <li>تفعيل واختبار تصفية الاشتراكات للمؤسسات متعددة المستأجرين الآن، قبل طرح البيئة الكبير التالي.</li> <li>تشغيل اختبار إجهاد موازٍ خاضع للتحكم إذا كنت تستخدم البناء عن بعد مع Container Apps.</li> </ul> <p>أعجب أيضًا بالتحول نحو تحذيرات ما قبل النشر القابلة للتنفيذ ومعرفات النشر المقروءة آليًا. هذا هو الجسر من تجربة مطور سهلة الاستخدام إلى قابلية مراقبة على مستوى العمليات.</p> <p>رأيي الشخصي: azd يكبر من مجرد قالب إطلاق إلى ركيزة توصيل. هذا جيد، لكنه يأتي بمسؤولية على الفرق: توقفوا عن معاملة ترقيات azd كصيانة اختيارية. بالنظر إلى عدد إصلاحات الأمان والموثوقية في هذه الملاحظات، البقاء في الخلف لم يعد محايدًا. إنه قبول نشط للمخاطر.</p> <p>إذا كان فريقك يستخدم azd في مسارات الإنتاج، السياسة الصحيحة بسيطة: حدد الإصدارات عمدًا، اختبر الترقيات بسرعة، وتحرك. سرعة دورة الإصدار هذه تظهر أين تتجه أدوات السحابة. الأدوات التي لا تتحمل التوازي والنطاق ستُهجر.</p> <p>قطار الإصدارات هذا يثبت أن azd يحاول أن يكون أداة تتحمل ضغط المؤسسات الحقيقي.</p>