التكامل والتسليم المستمر في Azure Data Factory
ينطبق على:
Azure Data Factory 
Azure Synapse Analytics
تلميح
جرب Data Factory في Microsoft Fabric، وهو حل تحليلي متكامل للمؤسسات. يغطي Microsoft Fabric كل شيء بدءا من حركة البيانات إلى علم البيانات والتحليلات في الوقت الحقيقي والمعلومات المهنية وإعداد التقارير. تعرف على كيفية بدء إصدار تجريبي جديد مجانا!
التكامل المستمر هو ممارسة اختبار كل تغيير يتم إجراؤه على قاعدة التعليمات البرمجية الخاصة بك تلقائيًا وفي وقت مبكر قدر الإمكان. يتبع التسليم المستمر الاختبار الذي يحدث في أثناء التكامل المستمر ويدفع التغييرات إلى نظام تشغيل مرحلي أو إنتاج.
في Azure Data Factory، التكامل المستمر والتسليم المستمر (CI/CD) يعنيان نقل مسارات Data Factory من بيئة (تطوير واختبار وإنتاج) إلى بيئة أخرى. يستخدم Azure Data Factory قوالب Azure Resource Manager لتخزين تكوين كيانات ADF المتعددة (مسارات، مجموعة البيانات، تدفق البيانات، إلخ). هناك طريقتان مقترحتان لتعزيز مصنع البيانات إلى بيئة أخرى:
- التوزيع التلقائي باستخدام تكامل مصانع البيانات مع مسارات Azure
- التحميل اليدوي لقالب Resource Manager باستخدام تكامل واجهة مستخدم Data Factory مع Azure Resource Manager.
إشعار
نوصي باستخدام الوحدة النمطية Azure Az PowerShell للتفاعل مع Azure. راجع تثبيت Azure PowerShell للبدء. لمعرفة كيفية الترحيل إلى الوحدة النمطية Az PowerShell، راجع ترحيل Azure PowerShell من AzureRM إلى Az.
دورة حياة CI/CD
إشعار
لمزيد من المعلومات، راجع تحسينات التوزيع المستمر.
فيما يلي نظرة عامة على دورة حياة التكامل المستمر/التسليم المستمر في Azure Data Factory تم تكوينه باستخدام Azure Repos Git. لمزيد من المعلومات حول كيفية تكوين مستودع Git، راجعتحكم المصدر في Azure Data Factory.
يتم إنشاء Development Data Factory وتكوينه باستخدام Azure Repos Git. ويجب أن يكون لدى جميع المطورين إذن لتأليف موارد Data Factory مثل المسارات ومجموعات البيانات.
ينشئ المطور فرع ميزة لإجراء تغيير. ويصحح المسارات الخاصة به طبقًا لأحدث التغييرات. لمزيد من المعلومات حول كيفية تصحيح تشغيل المسار، راجع التطوير التكراري وتصحيح الأخطاء مع Azure Data Factory.
بعد أن يكون المطور راضياً عن تغييراته، فإنه ينشئ طلب سحب من فرع الميزة إلى الفرع الرئيسي أو فرع التعاون ليقوم الأقران بمراجعة تغييراته.
بعد الموافقة على طلب السحب ودمج التغييرات في الفرع الرئيسي، تُنشر التغييرات في مصنع التطوير.
عندما يكون الفريق جاهزًا لنشر التغييرات على مصنع اختبار أو UAT (اختبار قبول المستخدم)، ينتقل الفريق إلى إصدار Azure Pipelines وينشر الإصدار المطلوب من مصنع التطوير إلى UAT. يحدث هذا النشر كجزء من مهمة Azure Pipelines ويستخدم معلمات قالب Resource Manager لتطبيق التكوين المناسب.
بعد أن يتم التحقق من التغييرات في مصنع الاختبار، قم بنشرها إلى مصنع الإنتاج باستخدام المهمة التالية لإصدار المسارات.
إشعار
يقترن مصنع التطوير فقط بمستودع Git. يجب ألا يكون لدى مصانع الاختبار والإنتاج مستودع Git مقترن بها ويجب تحديثها فقط عبر مسارات Azure DevOps أو عبر قالب Resource Management.
توضح الصورة أدناه الخطوات المختلفة لدورة الحياة هذه.
أفضل الممارسات لـ CI/CD
إذا كنت تستخدم تكامل Git مع مصنع البيانات لديك وكان لديك مسار تكامل مستمر/تسليم مستمر CI/CD ينقل التغييرات من التطوير إلى الاختبار ثم إلى الإنتاج، نوصي بأفضل الممارسات التالية:
تكامل Git. قم بتكوين Development Data Factory الخاص بك فقط باستخدام تكامل Git. يتم توزيع التغييرات في الاختبار والتشغيل عبر التكامل المستمر/التسليم المستمر ولا تحتاج إلى تكامل Git.
البرنامج النصي قبل النشر وما بعده. قبل خطوة توزيع Resource Manager في التكامل المستمر/التسليم المستمر (CI/CD)، تحتاج إلى إكمال مهام معينة، مثل إيقاف تشغيل المشغلات وإعادة تشغيلها وإجراء التنظيف. من المستحسن استخدام البرامج النصية PowerShell قبل وبعد مهمة النشر. لمزيد من المعلومات، راجع تحديث المشغلات النشطة. أتاح فريق مصنع البيانات نصّاً برمجيّاً لاستخدامه في أسفل هذه الصفحة.
إشعار
استخدم PrePostDeploymentScript.Ver2.ps1 إذا كنت ترغب في إيقاف تشغيل/ تشغيل المشغلات التي تم تعديلها فقط بدلاً من إيقاف تشغيل/ تشغيل جميع المشغلات أثناء CI/CD.
تحذير
تأكد من استخدام PowerShell Core في مهمة ADO لتشغيل البرنامج النصي.
تحذير
إذا كنت لا تستخدم أحدث إصدارات PowerShell والوحدة النمطية لـ Data Factory، فقد تتعرض لأخطاء إلغاء التسلسل أثناء تشغيل الأوامر.
أوقات تشغيل التكامل والمشاركة. لا تتغير غالبًا أوقات تشغيل التكامل وهي متشابهة عبر جميع المراحل في التكامل المستمر/التسليم المستمر (CI/CD). لذلك يتوقع Data Factory أن يكون لديك نفس الاسم والنوع والنوع الفرعي لوقت تشغيل التكامل عبر جميع مراحل CI/CD. إذا كنت ترغب في مشاركة وقت تشغيل التكامل عبر جميع المراحل، ففكر في استخدام مصنع ثلاثي فقط لاحتواء عمليات تشغيل التكامل المشتركة. يمكنك استخدام هذا المصنع المشترك في جميع البيئات لديك كنوع وقت تشغيل تكامل مرتبط.
إشعار
تتوفر مشاركة وقت تشغيل التكامل فقط لأوقات تشغيل التكامل المستضافة ذاتيًا. لا تدعم أوقات تشغيل تكامل Azure-SSIS المشاركة.
نشر نقطة النهاية الخاصة المدارة. إذا كانت هناك نقطة نهاية خاصة موجودة بالفعل في مصنع وتحاول توزيع قالب ARM يحتوي على نقطة نهاية خاصة بنفس الاسم ولكن ذات خصائص معدلة، فسيفشل التوزيع. بمعنى آخر، يمكنك توزيع نقطة نهاية خاصة بنجاح طالما أن لها نفس الخصائص الموجودة بالفعل في المصنع. إذا كانت هناك أي خاصية مختلفة بين البيئات، يمكنك تجاوزها بواسطة تحديد معلمات تلك الخاصية وتوفير القيمة الخاصة في أثناء التوزيع.
Key Vault. عند استخدام الخدمات المرتبطة التي يتم تخزين معلومات الاتصال الخاصة بها في Azure Key Vault، من المستحسن الاحتفاظ بالمخازن الرئيسية المنفصلة لبيئات مختلفة. يمكنك أيضًا تكوين مستويات أذونات منفصلة لكل مخزن رئيسي. على سبيل المثال، قد لا ترغب في أن يكون لدى أعضاء الفريق أذونات إلى البيانات السرية للتشغيل. إذا اتبعت هذا النهج، نوصيك بالاحتفاظ بنفس أسماء البيانات السرية عبر جميع المراحل. إذا كنت تحتفظ بنفس أسماء البيانات السرية، فلن تحتاج إلى وضع معلمات لكل سلسلة اتصال عبر بيئات التكامل المستمر/التسليم المستمر (CI/CD) لأن الشيء الوحيد الذي يتغير هو اسم المخزن الرئيسي، وهو معلمة منفصلة.
تسمية المورد. بسبب قيود قالب ARM، قد تنشأ مشاكل في النشر إذا كانت الموارد الخاصة بك تحتوي على مسافات في الاسم. يوصي فريق Azure Data Factory باستخدام الأحرف '_' أو '-' بدلاً من المسافات للموارد. على سبيل المثال، سيكون «Pipeline_1» اسمًا مفضلاً لـ «Pipeline 1».
تغيير المستودع. يدير ADF محتوى مستودع GIT تلقائيا. قد يؤدي تغيير الملفات أو المجلدات غير المرتبطة يدويا أو إضافتها إلى أي مكان في مجلد بيانات مستودع ADF Git إلى حدوث أخطاء في تحميل الموارد. على سبيل المثال، يمكن أن يتسبب وجود ملفات .bak في حدوث خطأ ADF CI/CD، لذلك يجب إزالتها لتحميل ADF.
التحكم في التعرض وأعلام المعالم. عند العمل في فريق، هناك مثيلات حيث يمكنك دمج التغييرات، ولكن لا تريد تشغيلها في بيئات مرتفعة مثل PROD و QA. لمعالجة هذا السيناريو، يوصي فريق ADF بمفهوم DevOps حول استخدام علامات الميزة. في ADF، يمكنك ضم المعلمات العمومية ونشاط "if condition" لإخفاء مجموعات من المنطق استناداً إلى علامات البيئة هذه.
لمعرفة كيفية إعداد علامة ميزة، راجع الفيديو التعليمي أدناه:
ميزات غير معتمدة
حسب التصميم، لا يسمح مصنع البيانات بانتقاء الالتزام أو التوزيع الانتقائي للموارد. ستتضمن عمليات النشر جميع التغييرات التي أجريت في مصنع البيانات.
- تعتمد كيانات مصنع البيانات على بعضها. على سبيل المثال، تعتمد المشغلات على المسارات، في حين تعتمد المسارات على مجموعات البيانات والمسارات الأخرى. من الممكن أن يؤدي التوزيع الانتقائي لمجموعة فرعية من الموارد إلى سلوكيات وأخطاء غير متوقعة.
- في مناسبات نادرة عندما تحتاج إلى التوزيع الانتقائي، خذ بعين الاعتبار استخدام إصلاح عاجل. لمزيد من المعلومات، راجع بيئة إنتاج الإصلاح العاجل.
لا يوصي فريق Azure Data Factory بتعيين عناصر تحكم Azure RBAC إلى كيانات فردية (مسارات ومجموعات البيانات وما إلى ذلك) في مصنع البيانات. على سبيل المثال، إذا كان لدى المطور حق الوصول إلى مسار أو مجموعة بيانات، فيجب أن يكون قادراً على الوصول إلى جميع المسارات أو مجموعات البيانات في مصنع البيانات. إذا كنت تشعر أنك بحاجة إلى تنفيذ العديد من أدوار Azure داخل مصنع بيانات، فانظر إلى توزيع مصنع بيانات ثان.
لا يمكنك النشر من الفروع الخاصة.
لا يمكنك حالياً استضافة المشاريع على Bitbucket.
لا يمكنك حالياً تصدير واستيراد التنبيهات والمصفوفات كمعلمات.
في مستودع التعليمات البرمجية تحت فرع adf_publish، تتم إضافة مجلد يسمى "PartialArmTemplates" حالياً بجانب مجلد "linkedTemplates" و "ARMTemplateForFactory.json" و "ARMTemplateParametersForFactory.json" كجزء من النشر مع التحكم في المصدر.
لن نقوم بعد الآن بنشر "PartialArmTemplates" إلى فرع adf_publish بدءاً من 1 نوفمبر 2021.
لا يلزم اتخاذ أي إجراء إلا إذا كنت تستخدم "PartialArmTemplates". بخلاف ذلك، قم بالتبديل إلى أي آلية مدعومة لعمليات التوزيع باستخدام: ملفات "ARMTemplateForFactory.json" أو "linkedTemplates".