Workspaces and Collaboration

// Setting up a Deployment Pipeline — Power BI Service

// Prerequisites: Premium capacity or Premium Per User licence
// All three workspaces must already exist

// Step 1 — Create the pipeline
// Power BI Service → Deployment pipelines → Create pipeline
// Name it: "Sales Dashboard Pipeline"

// Step 2 — Assign workspaces to stages
// Stage 1: Development  → assign "Sales Dev" workspace
// Stage 2: Test         → assign "Sales Test" workspace
// Stage 3: Production   → assign "Sales Prod" workspace

// Step 3 — Deploy from Dev to Test
// Pipeline view → click "Deploy" between Dev and Test
// Options:
//   Deploy all    — deploys every report and dataset
//   Deploy select — choose specific items to deploy
// On first deploy: creates new copies in the Test workspace
// On subsequent deploys: updates existing items (compare view available)

// Step 4 — Configure deployment rules (data source overrides)
// Each stage can have different data source connection strings
// Pipeline → Rules → Test stage → Dataset rules
// Set: Server = "uat-sql-server.company.com"
//      Database = "SalesDB_UAT"
// This means the dataset deployed to Test automatically
// points to the UAT data source — not the Dev data source

// Step 5 — Deploy from Test to Prod after QA sign-off
// Pipeline view → click "Deploy" between Test and Production
// Deployment rules for Prod override connection to live data source

// Comparing stages:
// Pipeline shows a diff indicator between stages:
//   ✓ Up to date  — content is identical
//   ≠ Different   — Dev has changes not yet deployed to Test
// Click "Compare" to see exactly which items differ

Copy
  
// Pattern 1 — Separate the dataset from the reports
// One developer owns the .pbix file that contains ONLY the data model
// (Power Query + DAX, no report pages)
// Other developers connect to the published dataset via Live Connection:
//   Get Data → Power BI datasets → select the published dataset
// Each developer builds their own .pbix file containing only reports
// The data model developer updates and republishes the dataset
// Report developers' files automatically pick up the updated model

// Benefit: 5 report developers can work simultaneously
// The only conflict risk is the single dataset file

// Pattern 2 — Source control with git integration
// Power BI Desktop can be integrated with Git repositories
// (Power BI Desktop → Options → Preview features → Git integration)
// This is a preview feature as of 2024 — workflow:
//   Each developer works on a feature branch
//   Merges to main branch go through pull request review
//   Conflicts are resolved in the git workflow, not by overwriting

// Pattern 3 — Naming conventions and change ownership
// Without git, the simplest collaboration protocol:
//   - Name report files: SalesDashboard_alice_20240315.pbix
//   - Use a shared folder (SharePoint/OneDrive) with version history
//   - Agree on a "file owner" per report — only they publish
//   - Communicate via comments in the Service before editing
//   - Use the dataset history in the Service to track publishes

// Pattern 4 — Service-side editing for minor changes
// Small changes (title text, colour, a new data label) can be made
// directly in the Service without opening Desktop:
// Service → Report → Edit (pencil icon)
// The edits are saved to the Service version of the report
// WARNING: if the Desktop file is republished after a Service edit,
// the Service edits are overwritten — always save Service edits
// back to Desktop (Service → File → Download this file) first