<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>CI/CD | The .NET Blog</title><link>https://thedotnetblog.com/ar/tags/ci/cd/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>ar</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Wed, 15 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/ar/tags/ci/cd/index.xml" rel="self" type="application/rss+xml"/><item><title>توقف عن معاملة قواعد البيانات كرقاقات ثلجية خاصة: Azure DevOps + SQL Projects بالطريقة الصحيحة</title><link>https://thedotnetblog.com/ar/news/emiliano-montesdeoca/azure-devops-sql-projects-ci-cd-fundamentals/</link><pubDate>Wed, 15 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/ar/news/emiliano-montesdeoca/azure-devops-sql-projects-ci-cd-fundamentals/</guid><description>نموذج خط أنابيب SQL Projects في Azure DevOps يثبت أن توصيل قواعد البيانات يمكن أن يكون قابلاً للتكرار وآمنًا وقابلاً للاختبار عندما تتبنى الفرق انضباط CI/CD القائم على الكود أولاً.</description><content:encoded>&lt;p&gt;الكثير من الفرق تدّعي أنها تمارس DevOps، ثم تنشر تغييرات قاعدة البيانات يدويًا من حاسوب شخص ما. هذا التناقض هو بالضبط ما يصلحه هذا الدليل من Azure SQL. SQL Projects مع خطوط أنابيب Azure DevOps تجعل توصيل قواعد البيانات حتميًا وقابلًا للتدقيق وآمنًا بما يكفي لسير عمل الإنتاج الحقيقي.&lt;/p&gt;
&lt;p&gt;المصدر الأصلي: &lt;a href="https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/"&gt;https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;أقوى جزء في النهج ليس بناء جملة YAML، بل تسلسل الانضباط: ابنِ أولاً، انشر ثانيًا، وأمّن مسار النشر بأقل امتياز وهوية بدون كلمة مرور. بناء ملف .sqlproj باستخدام dotnet يتحقق من توافق المنصة المستهدفة مبكرًا وينتج قطعة DACPAC يمكن ترقيتها عبر البيئات.&lt;/p&gt;
&lt;p&gt;رأيي واضح: إذا كان مخططك غير مبني في CI، فإن عملية جودة قاعدة بياناتك تعتمد في الغالب على الأمل. النجاح المحلي في SSMS أو VS Code ليس ضمانًا للإصدار.&lt;/p&gt;
&lt;p&gt;تصميم النشر أيضًا عملي بشكل منعش. استخدم اتصالات الخدمة المرتبطة بهويات Entra، وامنح أدوار قاعدة بيانات محددة النطاق لمقارنة المخطط والبيانات، وأتمت فتح جدار الحماية المؤقت لعناوين IP الخاصة بالمشغل مع ضمان التنظيف. هذا هو النوع من النظافة التشغيلية الذي تتجاهله الفرق حتى يجبرها مراجعة اختراق على إعادة النظر في كل شيء.&lt;/p&gt;
&lt;p&gt;توصيات عملية للتطبيق الفوري:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;افصل خطوط أنابيب البناء والنشر. البناء يجب أن يعمل على تغييرات الفرع ويفشل بسرعة. النشر يجب أن يكون خاصًا بالبيئة ومقيدًا بالسياسات.&lt;/li&gt;
&lt;li&gt;خزّن سلاسل الاتصال المستهدفة وبيانات التعريف الخاصة بالبنية التحتية في متغيرات خط أنابيب مؤمنة، ودوّر مراجعات الحوكمة لتعيينات الأدوار بانتظام.&lt;/li&gt;
&lt;li&gt;اجعل إصدارات SqlPackage صريحة ومثبتة في CI لتجنب تغييرات السلوك المفاجئة.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;لا تمنح امتيازات مفرطة مبكرًا. البدء بـ db_ddladmin و db_datareader و db_datawriter هو أساس أفضل من منح db_owner لكل مدير خط أنابيب &amp;ldquo;فقط لنجعلها تعمل&amp;rdquo;. ارفع المستوى فقط عندما يثبت شرط نشر ملموس ضرورته.&lt;/p&gt;
&lt;p&gt;درس قوي آخر هو قابلية النقل. لأن SQL Projects تعمل على سلسلة أدوات .NET SDK، هذا النمط ليس حصريًا لـ Azure DevOps. نفس الأساسيات تُترجم إلى GitHub Actions أو منسقين آخرين، مما يجعل هذا الدليل استراتيجيًا وليس مقيدًا بالمنصة.&lt;/p&gt;
&lt;p&gt;إذا كانت مؤسستك لا تزال تعامل توصيل المخططات كعملية خاصة خارج CI/CD للتطبيق، هذا هو مخطط الترحيل الخاص بك. لا تحتاج إلى هندسة منصات بطولية. تحتاج إلى الاتساق، والأمن القائم على الهوية أولاً، والاستعداد للتوقف عن شحن تغييرات قاعدة البيانات عبر مسارات امتيازات مخصصة.&lt;/p&gt;
&lt;p&gt;الفرق التي تفعل هذا ستنشر أسرع مع أحداث تراجع أقل. الفرق التي تؤجل ستدفع الضريبة الخفية لعمليات نشر يدوية على مستوى البيانات.&lt;/p&gt;</content:encoded></item></channel></rss>