ALM، Deployment Pipelines، PBIP، Git و مدیریت نسخه در Power BI

شروع جلسه؛ دیگر مستقیم روی Production دست نمی‌زنیم

تا اینجا یک سیستم BI حرفه‌ای ساخته‌ایم؛ اما اگر هر تغییر را مستقیم Publish کنیم، یک اشتباه کوچک در DAX یا مدل می‌تواند عدد رسمی سازمان را خراب کند. این فصل درباره مدیریت تغییر است.

هدف این است که Power BI را مثل یک محصول نرم‌افزاری واقعی مدیریت کنیم: نسخه داشته باشیم، تغییر را Review کنیم، در محیط آزمایشی تست کنیم و بعد با برنامه وارد Production کنیم.

۴۶.۱. ALM یعنی چه؟

ALM یا Application Lifecycle Management یعنی مدیریت چرخه عمر محصول از توسعه تا تست، انتشار، عملیات و بهبود.

۴۶.۲. سه محیط اصلی

اصل مهم این است که کاربر نهایی روی DEV کار نکند و Developer هم تغییر آزمایشی را مستقیم وارد PROD نکند.

۴۶.۳. جریان انتشار استاندارد

Feature → Commit → Review → DEV → QA → UAT → PROD → Smoke Test

۴۶.۴. Deployment Pipelines

Deployment Pipeline کمک می‌کند Artifactهای Power BI را بین Stageهای توسعه، تست و Production با نظم بیشتری جابه‌جا کنیم.

Pipeline جای QA نیست؛ فقط چون Deploy موفق شده، معنی‌اش این نیست که KPI درست است.

۴۶.۵. تنظیمات وابسته به محیط

اتصال DEV ممکن است به SQL-DEV باشد ولی Production باید SQL-PROD را بخواند. Configuration محیط را از منطق Business جدا کن.

۴۶.۶. مشکل Version Control با PBIX

PBIX برای کار فردی ساده است، اما برای Diff، Merge و Code Review تیمی محدودیت دارد. فایل final-final-v7.pbix سیستم نسخه‌بندی نیست!

۴۶.۷. PBIP

Power BI Project یا PBIP پروژه را به ساختاری مناسب‌تر برای توسعه تیمی و Source Control تبدیل می‌کند.

SalesAnalytics/
  SalesAnalytics.Report/
  SalesAnalytics.SemanticModel/
  SalesAnalytics.pbip

۴۶.۸. Git چه کمکی می‌کند؟

Git تاریخچه تغییرات را نگه می‌دارد؛ می‌توانیم بفهمیم چه کسی چه تغییری داده، Review انجام دهیم و به نسخه قبلی برگردیم.

۴۶.۹. Commit خوب

feat: add gross margin KPI
fix: correct YTD target logic
perf: reduce customer matrix query cost

هر Commit بهتر است یک تغییر منطقی مشخص داشته باشد، نه مجموعه‌ای از تغییرات نامرتبط.

۴۶.۱۰. Branch Strategy

برای تیم کوچک Strategy را بی‌دلیل پیچیده نکن.

۴۶.۱۱. Pull Request و Review

قبل از Merge تغییرات مهم، یک نفر دیگر Model، DAX، Power Query، RLS، UX و Performance را بررسی کند.

۴۶.۱۲. KPI Versioning

اگر تعریف Gross Margin عوض شود، این فقط یک تغییر فنی نیست؛ تعریف تصمیم مدیریتی تغییر کرده است.

۴۶.۱۳. Release Notes

v2.3.0
- Added Customer 360
- Added dynamic KPI selector
- Fixed YTD target
- Improved Executive page performance

Release Note کمک می‌کند تیم Business و Support بدانند دقیقاً چه چیزی تغییر کرده است.

۴۶.۱۴. Breaking Change

حذف Column، تغییر نام Measure یا تغییر Grain می‌تواند Thin Reportها و مصرف‌کنندگان دیگر Semantic Model را خراب کند. قبل از تغییر Dependencyها را بررسی کن.

۴۶.۱۵. Regression Test

Fix جدید نباید قابلیت قدیمی را خراب کند. چند Test Case ثابت با جواب معلوم داشته باش.

۴۶.۱۶. Golden Dataset

یک Dataset کوچک با داده کنترل‌شده و جواب‌های از قبل معلوم بساز. برای تست DAX و RLS فوق‌العاده مفید است.

۴۶.۱۷. Performance Gate

اگر Executive Page قبل از تغییر ۲.۵ ثانیه بوده و بعد از Release به ۹ ثانیه رسیده، Release از نظر Performance مشکل دارد. Performance Budget فصل ۴۵ را وارد Definition of Done کن.

۴۶.۱۸. Security Gate

هر تغییر Relationship، Mapping یا Role باید با کاربران نمونه CEO، Area Manager، Branch Manager و Unknown User دوباره تست شود.

۴۶.۱۹. Four-eyes Principle

برای تغییرات حساس بهتر است Developer تنها فردی نباشد که تغییر را می‌سازد و بدون Review وارد Production می‌کند.

۴۶.۲۰. Smoke Test

بلافاصله بعد از Deployment صفحات حیاتی را باز کن، KPIهای کلیدی، RLS، Connection و Refresh را بررسی کن.

Deploy → Open critical pages → Validate KPIs → Validate RLS → Check source → Update App

۴۶.۲۱. Rollback

قبل از Release باید بدانیم اگر خراب شد چه‌طور به نسخه پایدار قبلی برگردیم. Source Control و Release Tag اینجا ارزش واقعی‌شان را نشان می‌دهند.

۴۶.۲۲. Hotfix

برای خطای بحرانی Production مسیر Hotfix تعریف کن؛ سریع باشد ولی Review، ثبت تغییر و تست حداقلی حذف نشود.

۴۶.۲۳. CI/CD در Power BI

CI/CD یعنی بخش‌هایی از Validation، Build و Deployment را استاندارد و در صورت امکان خودکار کنیم. Automation نباید Approval کسب‌وکار را برای تغییر KPIهای حساس حذف کند.

۴۶.۲۴. Secrets

Password، Token و Credential را داخل Repository Commit نکن. Secret Management و Environment Configuration باید جدا باشند.

۴۶.۲۵. Definition of Done

۴۶.۲۶. README پروژه

# Sales Analytics
Owner: BI Team
Business Owner: Sales Director
Environments: DEV/UAT/PROD
Critical KPIs: Sales, Profit, Margin
Refresh SLA: 07:00

۴۶.۲۷. Traceability

در پروژه حرفه‌ای باید بتوانیم از یک Release به Ticket، Commit، Reviewer، Test Result و Business Approval برسیم.

۴۶.۲۸. Technical Debt

Measure تکراری، Naming بد، Model پیچیده و Reportهای Duplicate را مثل بدهی فنی ثبت و برنامه‌ریزی کن.

۴۶.۲۹. پروژه شرکت هانا

مثلاً Feature/customer-360 در Branch خودش توسعه پیدا می‌کند، Review می‌شود، در UAT توسط تیم فروش تأیید می‌شود و بعد وارد Production خواهد شد.

۴۶.۳۰. Release Checklist

۴۶.۳۱. خطاهای رایج

نام‌گذاری فایل با final_final2 به جای Version Control؛ Publish مستقیم به Production؛ Commitهای مبهم؛ نگهداری Secret در Git؛ تغییر Model بدون Dependency Check؛ Deploy بدون Rollback Plan؛ و تغییر KPI بدون Business Approval.

۴۶.۳۲. تمرین عملی

برای یک پروژه Power BI سه Workspace DEV/UAT/PROD طراحی کن. سپس Branch Strategy، Permissionها، Release Checklist و Rollback Plan را بنویس.

بعد یک تغییر فرضی در Margin % تعریف کن و مشخص کن از لحظه درخواست Business تا انتشار Production چه مراحلی طی می‌شود.

۴۶.۳۳. پروژه پایانی Session 46

هدف این پروژه این است که توسعه Power BI از «ویرایش فایل و Publish» به یک فرآیند مهندسی قابل کنترل تبدیل شود.

جمع‌بندی Session 46

از این فصل به بعد، Power BI را مثل Software Product ببین. تغییر خوب فقط تغییری نیست که کار کند؛ باید قابل Review، قابل تست، قابل انتشار و قابل بازگشت باشد.

Version → Review → Validate → Deploy → Verify → Monitor

Session 47: Governance و Center of Excellence در Power BI؛ استانداردهای سازمانی، مالکیت داده، KPI Catalog، Data Governance، Adoption و ساخت BI Operating Model.