خطوط أنابيب نشر Power BI: تطوير سير عمل الإنتاج

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

توفر مسارات نشر Power BI انضباط هندسة البرمجيات لتطوير التحليلات - حيث تحدد مراحل واضحة (التطوير والاختبار والإنتاج)، والترويج الخاضع للتحكم بين المراحل، والقدرة على التراجع عندما يحدث خطأ ما. يغطي هذا الدليل تكوين مسار النشر وأفضل الممارسات لإدارة المؤسسة والتكامل مع أدوات CI/CD الخارجية.

الوجبات الرئيسية

• تتطلب مسارات النشر Power BI Premium (لكل سعة أو لكل مستخدم) أو Microsoft Fabric
• خريطة ثلاث مراحل (التطوير والاختبار والإنتاج) لفصل مساحات العمل في خدمة Power BI
• يتم الترويج للمحتوى خطوة بخطوة، مع خيار مراجعة التغييرات ومقارنتها قبل الترويج
• تسمح قواعد مصدر البيانات الخاصة بالمرحلة لنفس مجموعة البيانات بالإشارة إلى قواعد بيانات مختلفة في كل مرحلة
• تعالج قواعد النشر الاختلافات في مصادر البيانات والمعلمات واتصالات مساحة العمل بين المراحل
• تتحكم قواعد الوصول في من يمكنه النشر في كل مرحلة - عادةً ما يمتلك المطورون التطوير، ويمتلك ضمان الجودة الاختبار، ويمتلك مديرو الإصدار فقط الإنتاج
• تعمل واجهة Power BI REST API على تمكين خطوط الأنابيب الآلية المتكاملة مع GitHub Actions أو Azure DevOps أو أدوات CI/CD الأخرى
• مقارنة A/B بين المراحل توضح بالضبط ما تغير قبل الترقية

---

ما هي مسارات النشر؟

مسار النشر في Power BI عبارة عن آلية تربط ثلاث مساحات عمل - التطوير والاختبار والإنتاج - وتدير الترويج لمحتوى Power BI (مجموعات البيانات والتقارير ولوحات المعلومات وتدفقات البيانات والتقارير المرقّمة) فيما بينها.

بدون خطوط أنابيب:

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

مع خطوط الأنابيب:

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

---

إعداد خط أنابيب النشر

المتطلبات الأساسية:

• Power BI Premium لكل سعة، أو Premium لكل مستخدم، أو سعة Microsoft Fabric
• ثلاث مساحات عمل (أو دع خط الأنابيب ينشئها)
• وصول المسؤول أو العضو في مساحات العمل المقصودة

الخطوة 1: إنشاء خط الأنابيب

في خدمة Power BI: مسارات النشر ← إنشاء مسار ← قم بتسميته (على سبيل المثال، "خط أنابيب التحليلات المالية") ← إنشاء.

الخطوة 2: تعيين مساحات العمل للمراحل

يتم تخصيص مساحة عمل موجودة لكل مرحلة (التطوير والاختبار والإنتاج) أو يمكنك إنشاء مساحات عمل جديدة من داخل واجهة خط الأنابيب. يجب تسمية مساحات العمل بشكل متسق - على سبيل المثال، "Finance Analytics - Dev" و"Finance Analytics - Test" و"Finance Analytics".

الخطوة 3: السكان الأولي

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

الخطوة 4: تكوين قواعد النشر

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

• قواعد مصدر البيانات: تجاوز سلسلة اتصال مصدر البيانات عند النشر. تشير مجموعة بيانات التطوير إلى قاعدة بيانات التطوير/الاختبار؛ تشير مجموعة بيانات الإنتاج إلى قاعدة بيانات الإنتاج. ويحدث هذا تلقائيًا أثناء النشر دون تحرير كل مجموعة بيانات يدويًا.

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

• قواعد اتصال مساحة العمل: بالنسبة للتقارير المتصلة بمجموعات بيانات Power BI في المسار نفسه، يتم تحديث الاتصال تلقائيًا للإشارة إلى مجموعة بيانات المرحلة المكافئة عند النشر.

---

قواعد النشر بالتفصيل

قواعد النشر هي الآلية التي تجعل نفس مجموعة البيانات تعمل بشكل صحيح في المراحل الثلاث دون تحرير يدوي.

قواعد مصدر البيانات يتم تكوينها لكل مرحلة في إعدادات المسار:

انتقل إلى المسار → مرحلة الاختبار → قواعد النشر → إضافة قاعدة:

• مجموعة البيانات: "تقارير المبيعات"
• نوع مصدر البيانات: قاعدة بيانات Azure SQL
• الاتصال الأصلي: dev-server.database.windows.net/SalesDB_Dev
• اتصال جديد: test-server.database.windows.net/SalesDB_Test

عند نشر المحتوى من التطوير إلى الاختبار، يتم تحديث اتصال مجموعة البيانات تلقائيًا للإشارة إلى قاعدة بيانات الاختبار. عند الترقية من الاختبار إلى الإنتاج:

• الأصل: test-server.database.windows.net/SalesDB_Test
• جديد: prod-server.database.windows.net/SalesDB

وهذا يضمن أن:

• لا يؤثر المطورون العاملون في مجال التطوير على بيانات الإنتاج عن طريق الخطأ
• يتم التحقق من ضمان الجودة مقابل نسخة واقعية من بيانات الإنتاج (وليس بيانات التطوير)
• يستخدم الإنتاج اتصال الإنتاج الصحيح دون تدخل يدوي

قواعد المعلمات تعمل بالمثل. إذا كانت مجموعة البيانات تحتوي على معلمة تسمى APIEnvironment بقيم "dev" أو "staging" أو "prod"، فإن قاعدة المعلمة تقوم بتعيين القيمة الصحيحة لكل مرحلة تلقائيًا أثناء النشر.

---

التحكم في الوصول حسب المرحلة

من فوائد الحوكمة الرئيسية لخطوط النشر هي التحكم الدقيق في الوصول حسب المرحلة:

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

** عملية إدارة الإصدار: **

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

---

مقارنة التغييرات قبل النشر

قبل الترقية من مرحلة إلى أخرى، يعرض المسار عرضًا مقارنًا لما تغير. هذه هي خطوة المراجعة للمستخدم القوي.

مقارنة مجموعة البيانات تظهر:

• تغييرات المخطط (إضافة / إزالة الجداول والأعمدة والمقاييس والعلاقات)
• اختلافات اتصال مصدر البيانات
• تغييرات تعريف القياس المحسوبة
• تغييرات قاعدة الأمان على مستوى الصف

مقارنة التقارير تظهر:

• الصور المضافة أو إزالتها أو تعديلها
• تغييرات التصفية والتقطيع
• إضافات الصفحة أو عمليات الإزالة
• الإبلاغ عن تغييرات الموضوع

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

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

---

أتمتة خطوط الأنابيب باستخدام REST API

بالنسبة للبيئات على مستوى المؤسسة، يتم استبدال عمليات نشر خطوط الأنابيب اليدوية بسير عمل تلقائي يتم تشغيله بواسطة التزامات Git، أو عمليات دمج طلبات السحب، أو خطوات خطوط أنابيب CI/CD.

نقاط نهاية نشر Power BI REST API:

POST /v1.0/myorg/pipelines/{pipelineId}/deployAll
POST /v1.0/myorg/pipelines/{pipelineId}/stages/{stageId}/deployAllArtifacts
POST /v1.0/myorg/pipelines/{pipelineId}/stages/{stageId}/deploySpecificArtifacts
GET /v1.0/myorg/pipelines/{pipelineId}/operations/{operationId}

مثال على سير عمل إجراءات GitHub:

name: Deploy to Power BI Test

on:
  push:
    branches: [main]

jobs:
  deploy-to-test:
    runs-on: ubuntu-latest
    steps:
      - name: Get Bearer Token
        id: auth
        run: |
          TOKEN=$(curl -s -X POST \
            "https://login.microsoftonline.com/${{ secrets.TENANT_ID }}/oauth2/v2.0/token" \
            -d "client_id=${{ secrets.CLIENT_ID }}&client_secret=${{ secrets.CLIENT_SECRET }}&scope=https://analysis.windows.net/powerbi/api/.default&grant_type=client_credentials" \
            | jq -r '.access_token')
          echo "token=$TOKEN" >> $GITHUB_OUTPUT

      - name: Deploy Development to Test
        run: |
          curl -X POST \
            "https://api.powerbi.com/v1.0/myorg/pipelines/${{ secrets.PIPELINE_ID }}/stages/0/deployAllArtifacts" \
            -H "Authorization: Bearer ${{ steps.auth.outputs.token }}" \
            -H "Content-Type: application/json" \
            -d '{"sourceStageOrder": 0}'

      - name: Wait for Deployment
        run: |
          # Poll operation status until complete
          sleep 30
          # Add status checking logic here

يؤدي هذا إلى أتمتة النشر إلى مرحلة الاختبار عندما يتم دمج التعليمات البرمجية في الفرع الرئيسي. تتعامل خطوة يدوية منفصلة (أو سير عمل خاضع للموافقة) مع الاختبار → عمليات نشر الإنتاج.

---

التكامل مع جيت

يقدم Microsoft Fabric تكامل Git الأصلي لمساحات عمل Power BI، والذي يحول مسارات النشر إلى سير عمل DevOps كامل:

مساحة العمل المتصلة بـ Git:

• يتم تمثيل محتوى Power BI (النماذج الدلالية والتقارير) كملفات مصدر في مستودع Git
• تتم مزامنة التغييرات التي تم إجراؤها على Git تلقائيًا مع مساحة العمل المتصلة
• يمكن تحديث مساحة العمل من Git (سحب) أو يمكن الالتزام بمساحة العمل من Git (دفع)

سير عمل التطوير باستخدام Git:

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

هذا هو GitOps الكامل لـ Power BI - يتم تعقب جميع التغييرات في التحكم في الإصدار، وتتم جميع عمليات النشر تلقائيًا، ويكون مسار التدقيق في سجل Git.

---

استراتيجيات التراجع

عندما يتسبب نشر الإنتاج في حدوث مشكلات، يجب أن يكون التراجع سريعًا. تدعم مسارات النشر العديد من إستراتيجيات التراجع:

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

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

تحميل .pbix يدويًا: بالنسبة للمؤسسات التي ليس لديها تكامل مع Git، فإن الاحتفاظ بنسخة من آخر إنتاج جيد معروف .pbix يسمح بالتحميل المباشر إلى مساحة عمل الإنتاج كتراجع طارئ. أقل أناقة، ولكن يمكن الاعتماد عليها.

النسخ الاحتياطي والاستعادة لمجموعة البيانات: بالنسبة للمشكلات المتعلقة بمجموعة البيانات فقط، يمكن تطبيق إجراءات النسخ الاحتياطي والاستعادة في Azure Analysis Services عبر نقطة نهاية XMLA للنماذج الدلالية المميزة. يكون هذا مفيدًا عندما تكون تغييرات التقرير جيدة ولكن مجموعة البيانات بها تغيير في النموذج يحتاج إلى التراجع.

---

الأسئلة المتداولة

هل تتطلب مسارات النشر Premium لجميع المراحل الثلاث؟

نعم. يجب أن تحتوي جميع مراحل مساحة العمل الثلاث في مسار النشر على سعة مميزة معينة أو أن تكون مساحات عمل مميزة لكل مستخدم. ستفشل محاولة تعيين مساحة عمل غير Premium لمرحلة التدفق. وهذا يعني أنه يجب على المؤسسات وضع ميزانية للسعة المميزة لمساحات عمل التطوير والاختبار بالإضافة إلى الإنتاج - على الرغم من أن Dev وTest غالبًا ما يشتركان في وحدة SKU ذات سعة أصغر.

هل يمكن لمسارات النشر التعامل مع تدفقات البيانات والتقارير المرقّمة؟

نعم. تدعم مسارات النشر كافة أنواع محتوى Power BI: مجموعات البيانات (النماذج الدلالية)، والتقارير، ولوحات المعلومات، وتدفقات البيانات، والتقارير المرقّمة. تنطبق قواعد النشر لمصادر البيانات على مجموعات البيانات وتدفقات البيانات. يتم نشر التقارير المقسمة إلى صفحات كما هي، مع تحديث اتصالات مصدر البيانات بواسطة قواعد النشر.

ماذا يحدث للمستخدمين النهائيين عندما يكون النشر قيد التقدم؟

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

هل يمكنني نشر تقارير محددة فقط، وليس مساحة العمل بأكملها؟

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

كيف يتصرف الأمان على مستوى الصف عبر مراحل التدفق؟

تعد قواعد RLS جزءًا من تعريف مجموعة البيانات ويتم نشرها مع مجموعة البيانات. ومع ذلك، فإن تعيينات المستخدم (المستخدمون الذين لديهم دور RLS) هي إعدادات على مستوى مساحة العمل ولا يتم نقلها تلقائيًا. بعد نشر مجموعة بيانات باستخدام RLS إلى مرحلة جديدة، قم بإعادة تكوين عضويات الدور لمستخدمي تلك المرحلة. لا تستطيع قواعد النشر حاليًا أتمتة تعيين عضوية الدور بين المراحل.

هل يوجد سجل إصدارات لمحتوى Power BI بدون تكامل Git؟

بدون تكامل Git، لا يحتفظ Power BI أصلاً بمحفوظات الإصدارات لـ .pbix أو ملفات تعريف مجموعة البيانات. يوفر مسار النشر نفسه شكلاً من أشكال التحكم في الإصدار - يمثل المحتوى في كل مرحلة نقطة معروفة في سجل النشر. غالبًا ما تحتفظ المؤسسات التي ليس لديها تكامل Git بالتحكم اليدوي في الإصدار عن طريق حفظ نسخ .pbix بأسماء مختومة بالتاريخ قبل كل تحديث رئيسي. يعد تكامل Git (المتوفر في Fabric) هو الأسلوب الموصى به للتحكم المناسب في الإصدار.

---

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

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

خدمات تنفيذ Power BI من ECOSIRE تتضمن تكوين مسارات النشر، وتصميم إطار عمل الإدارة، وتكامل CI/CD لبيئات Power BI الخاصة بالمؤسسات. اتصل بنا لتقييم سير عمل التطوير الحالي لديك وتصميم استراتيجية خط أنابيب تتوافق مع نضجك التنظيمي.