مشاركة عبر

توفير التحليلات على نطاق السحابة

  • مقالة

عملية توزيع منطقة إدارة البيانات المنتقل إليها

فريق عمليات النظام الأساسي للبيانات مسؤول عن نشر منطقة هبوط إدارة البيانات. يجب أن يكون للمنطقة المنتقل إليها لإدارة البيانات مستودع خاص بها يحتفظ به فريق عمليات النظام الأساسي للبيانات.

تنبيه

إنشاء ونشر منطقة منتقل إليها لإدارة البيانات قبل توزيع أي منطقة منتقل إليها للبيانات.

عملية توزيع منطقة البيانات المنتقل إليها

يمكن للفرق استخدام القوالب التي يوفرها فريق عمليات النظام الأساسي للبيانات لتجنب البدء من البداية لكل أصل. نوصي بنمط نسخ المستودع لأتمتة نشر منطقة هبوط جديدة.

على سبيل المثال، يطلب فريق عمليات منطقة البيانات المنتقل إليها منطقة هبوط بيانات جديدة باستخدام أداة إدارة تكنولوجيا المعلومات أو Power Apps. عند الموافقة على الطلب، ابدأ سير العمل التالي باستخدام معلمات من الطلب:

  1. نشر اشتراك جديد لمنطقة البيانات المنتقل إليها الجديدة.
  2. نسخ الفرع الرئيسي من قالب منطقة البيانات المنتقل إليها لإنشاء مستودع جديد.
  3. إنشاء اتصال خدمة في المستودع الجديد.
  4. تحديث المعلمات في المستودع الجديد استنادا إلى المعلمات من الطلب.
  5. إنشاء البنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع لتوزيع الخدمات، التي يتم تشغيلها عن طريق إيداع المعلمات المحدثة.
  6. قم بإعلام فريق عمليات منطقة البيانات المنتقل إليها بأن المنطقة المنتقل إليها الجديدة متاحة.

يمكن لفريق عمليات منطقة البيانات المنتقل إليها الآن تغيير قوالب Azure Resource Manager أو إضافتها.

يمكن أتمتة سير العمل هذا باستخدام مجموعات خدمات متعددة على النظام الأساسي ل Azure. تعامل مع بعض الخطوات، مثل إعادة تسمية المعلمات في ملفات المعلمات، باستخدام مسارات CI/CD. يمكن تنفيذ خطوات أخرى باستخدام أدوات تنسيق سير العمل الأخرى مثل Logic Apps.

رسم تخطيطي لنموذج DevOps المتشعب.

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

اعتماد أفضل الممارسات للمستودعات، مثل:

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

تلميح

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

رسم تخطيطي لعملية أتمتة منطقة هبوط البيانات.

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

لا توجد واجهات برمجة تطبيقات Git متاحة لاستنساخ/تحديث/تثبيت/دفع في حل الأتمتة المقترح. لذلك فإن نهجنا هو استخدام حساب Azure Automation الذي يحتوي على دفاتر تشغيل PowerShell التي:

  • إعداد منطقة البيانات المنتقل إليها
  • نسخ المستودع الرئيسي إلى مستودع Git للنظام الأساسي للبيانات
  • إعداد تكوينات الشبكة الفرعية لمنطقة البيانات المنتقل إليها
  • إعداد Azure Active Directory

تستخدم دفاتر التشغيل وظائف Git من GitAutomation وحدة PowerShell للعمل مع مستودعات Git. من خلال تثبيت هذه الوحدة داخل حساب Azure Automation، يمكن للمستخدمين القيام بعمليات الإنشاء والاستنساخ والاستعلام والدفع والسحب والتثبيت في مستودعات Git. تظهر الصورة التالية الوحدة النمطية GitAutomation المثبتة داخل حساب Azure Automation:

رسم تخطيطي لوحدة

استخدم الدالة Copy-GitRepository من الوحدة النمطية GitAutomation لاستنساخ مستودع Git الرئيسي من عنوان URL المحدد من قبل URL إلى مسار Git للنظام الأساسي للبيانات المحدد بواسطة DestinationPath.

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

عملية نشر تطبيق البيانات

بعد إنشاء منطقة هبوط البيانات، يمكن أن يبدأ الإعداد لفرق تطبيق البيانات. تمنح فرق عمليات النظام الأساسي للبيانات أو منطقة البيانات المنتقل إليها الموافقة على النشر.

يتم التوزيع إما مباشرة باستخدام أدوات DevOps أو يتم استدعاؤها عبر المسارات/مهام سير العمل المكشوفة كواجهات برمجة تطبيقات. على غرار منطقة البيانات المنتقل إليها، يبدأ التوزيع بتشعب مستودع تطبيق البيانات الأصلي.

رسم تخطيطي لأتمتة توزيع تطبيق البيانات.

  1. يقدم المستخدم طلبا لخدمات تطبيق بيانات جديدة.
  2. تطلب عملية سير العمل الموافقة من النظام الأساسي للبيانات أو فريق عمليات منطقة البيانات المنتقل إليها.
  3. يستدعي سير العمل واجهة برمجة تطبيقات إدارة خدمة تكنولوجيا المعلومات لإنشاء مجموعات الموارد المطلوبة وإنشاء اتصال خدمة Azure DevOps. يعين سير العمل فريقا إلى مشروع Azure DevOps.
  4. ينسخ سير العمل مستودع تطبيق البيانات الأصلي لإنشاء مشروع Azure DevOps الوجهة.
  5. ينشئ سير العمل ملف معلمة قالب Azure Resource Manager والتدفقات.
  6. ثم يبدأ سير العمل مسار Azure لإنشاء متطلبات الشبكة، ومسار Azure آخر لنشر خدمات تطبيق البيانات.
  7. يقوم سير العمل بإعلام المستخدم عند الانتهاء.

تلميح

إذا كنت جديدا على DataOps، فراجع DataOps للمختبر العملي لمستودع البيانات الحديث في Azure Architecture Center. يصف سيناريو المختبر مكتب تخطيط مدينة خيالي يمكنه استخدام حل التوزيع هذا. يوفر حل التوزيع مسار بيانات شامل يتبع النمط المعماري لمستودع البيانات الحديث، جنبا إلى جنب مع عمليات DevOps وDataOps المقابلة، لتقييم استخدام وقوف السيارات واتخاذ قرارات أعمال مستنيرة.

الملخص

توفر الأنماط المذكورة أعلاه التحكم وخفة الحركة والخدمة الذاتية وإدارة دورة حياة النهج.

رسم تخطيطي لنموذج DataOps العام.

في بداية المشروع، يحتوي النظام الأساسي للبيانات على مشروع Azure DevOps واحد مع واحد أو أكثر من لوحات Azure. تركز فرق DevOps الفردية على:

  • مستودع واحد لمنطقة إدارة البيانات المنتقل إليها والبنية الأساسية لبرنامج ربط العمليات التجارية واتصال الخدمة ببيئة السحابة.
  • مستودع قالب واحد لمنطقة البيانات المنتقل إليها، والبنية الأساسية لبرنامج ربط العمليات التجارية لنشر مثيل منطقة هبوط البيانات، واتصالات الخدمة ببيئات السحابة.
  • مستودع قالب واحد لخدمات منتجات البيانات والبنية الأساسية لبرنامج ربط العمليات التجارية لتوزيع مثيل منتج بيانات واتصالات الخدمة ببيئات السحابة. يتم نسخ هذه الاتصالات من منطقة البيانات المنتقل إليها مشاريع Azure DevOps.

بمجرد توزيع مناطق هبوط البيانات، تنص التحليلات على نطاق السحابة على ما يلي:

  • سيكون لكل منطقة منتقل إليها بيانات مشروع Azure DevOps الخاص بها مع واحد أو أكثر من لوحات Azure.
  • لكل تطبيق بيانات، يتم إنشاء منطقة البيانات المنتقل إليها الخاصة به Azure DevOps project fork بعد الموافقة على الطلب.
  • يتضمن كل تطبيق بيانات ما يلي:
    • اتصال خدمة.
    • البنية الأساسية لبرنامج ربط العمليات التجارية المسجلة.
    • فريق DevOps لديه حق الوصول إلى لوحة Azure ومستودعه.
    • مجموعة مختلفة من النهج للمستودع المتشعب.

للتحكم في نشر تطبيقات البيانات، اتبع هذه الممارسات:

  • يمتلك فريق عمليات منطقة هبوط البيانات فرع المستودع الرئيسي ويؤمنه.
  • يتم استخدام الفرع الرئيسي فقط للنشر لاختبار بيئات الإنتاج.
  • يمكن نشر فروع الميزات في بيئات التطوير.
  • فروع الميزات مملوكة لفرق DataOps. يتم استخدامها لاختبار الميزات الجديدة أو المعدلة.
  • يمكن لفرق DataOps دمج فروع الميزات في فروع الميزات الأخرى دون موافقة.
  • تنشئ فرق DataOps طلب سحب لدمج فروع الميزات في الفرع الرئيسي، ويوفر فريق عمليات منطقة هبوط البيانات الموافقة.
  • يتم دمج الميزات أو التحسينات الجديدة على القوالب الأصلية في المستودع المتشعب لإبقائها محدثة.

الخطوات التالية