Prepstellar
Get the app

DP-600 · Workspace Development Lifecycle

23 cards

Deployment Pipelines

Swipe, scroll or use ← →

  1. Promote content through ordered stages

    Deployment pipelines in Microsoft Fabric promote content through ordered stages. Each stage maps to a separate workspace, and a deployment copies selected items from the source stage to the target workspace in the next stage.

    That is the whole mechanic, and it repays reading slowly. A stage is not a folder or a label attached to an item: it is a workspace of its own, with its own content, its own permissions, and its own connections.

    1 / 23

  2. Promote content through ordered stages

    The idea What it actually is
    A stage A separate workspace
    A deployment A copy of selected items into the next stage's workspace
    Promotion Content moving forward, one stage at a time

    Because a stage is a workspace, environments stop being a convention everyone has to remember and become something the platform enforces. The report in Test cannot quietly turn out to be the same object as the report in Production, because the two live in different workspaces.

    2 / 23

  3. Quick check

    What does each stage of a deployment pipeline correspond to?

    1. AA repository and its Git provider

      A repository holds version history; it is not what a pipeline stage points at.

    2. BA folder inside a project saved as text

      A project folder is a local save format for one report and its model, not an environment.

    3. CA separate workspace, which must run on Fabric or Premium capacity

      Right. Each stage maps to its own workspace, and every assigned workspace must use Fabric or Premium capacity.

    3 / 23

  4. Choose the stages and what each is for

    A default pipeline has Development, Test, and Production stages. The number of stages can be customized from two through 10, and stages can be renamed for a team's workflow.

    Stage What happens there
    Development Authoring and iteration
    Test Validating content, report behavior, results, and performance
    Production Approved content, available to business users

    Development is used to author and iterate. Test is used to validate content, report behavior, measure results, and performance. Production is where approved content is available to business users.

    4 / 23

  5. Choose the stages and what each is for

    The range from two through 10 is wide on purpose. A small team may want only Development and Production. An organization with a formal acceptance step may add a stage between Test and Production and rename it after the group that signs off.

    What does not change is the direction of travel. Content moves forward through the stages a team has defined, and each stage exists so that somebody can answer a question about that content before it goes any further.

    5 / 23

  6. Quick check

    Which stages does a default pipeline provide, and can that be changed?

    1. ADraft, Review, and Published, and the count cannot be changed

      Those are not the default names, and the stage count can in fact be customized.

    2. BDevelopment, Test, and Production, with two to 10 possible

      Right. The default is Development, Test, and Production, and teams can rename stages and use between two and 10 of them.

    3. CSource, Transform, and Destination, one for each data movement step

      Those describe steps inside a data movement process rather than environments content is promoted through.

    6 / 23

  7. Create the pipeline and assign workspaces

    To create a pipeline in the Fabric portal, select Workspaces, then Deployment pipelines, and then Create pipeline. Name the pipeline and configure its stage count.

    Assign one workspace to each stage; every assigned workspace must use Fabric or Premium capacity. The pipeline view then displays stage content side by side.

    7 / 23

  8. Create the pipeline and assign workspaces

    The capacity requirement is what most often blocks a first attempt. A workspace on shared capacity cannot take part, however tidy the rest of the setup looks.

    The side-by-side view is worth noticing too. Once stages are assigned, that view is where the team sees what each environment currently holds, which is what makes the comparison step later possible at a glance rather than by memory.

    8 / 23

  9. Quick check

    Which portal path creates a deployment pipeline?

    1. AWorkspaces, then Deployment pipelines, then Create pipeline

      Right. From there the pipeline is named, its stage count is set, and a workspace is assigned to each stage.

    2. BFile, Save as, Power BI Project

      That saves a report locally as a text-based project and creates no promotion path at all.

    3. CWorkspace settings, then Git integration, then select a repository

      That connects a workspace to version control, which answers a different lifecycle question.

    9 / 23

  10. Keep your progress in the app

    That’s 3 of 9 quick checks. In the app they stay answered, and every lesson remembers where you left off.

    Get the app Keep reading here

  11. Point each stage at its own source

    Deployment rules replace configuration values as content moves between stages. The first type, the data source rule, changes a server, database, or connection path.

    It solves the most common environment difference of all. A data source rule can therefore point Development at a test database while Production keeps the live one, without anyone editing the item by hand between deployments.

    Editing by hand is the alternative these rules exist to remove: it is slow, it is easy to forget, and it means touching content that has already been validated.

    10 / 23

  12. Quick check

    Development must read a test database while Production reads the live one. What handles that?

    1. AA branch in the repository that rewrites the item by hand for each environment

      Editing the item by hand for each environment is exactly the manual work rules remove.

    2. BA data source rule for each target stage

      Right. Data source rules change a server, database, or connection path as content moves into a stage.

    3. CA comparison indicator that turns the item's icon from orange to green

      Comparison icons report whether items differ between stages; they change no configured value.

    11 / 23

  13. Override parameter values per stage

    The second type, the parameter rule, overrides Power BI parameter values for a stage. A parameter rule can hold a different value for each stage, so a row limit of 1,000 in Development can be left unlimited in Production. Between them, data source rules change a server, database, or connection path, while parameter rules override Power BI parameter values for a stage. These rules allow development, test, and production to use different settings without manually changing the source item.

    Configure rules before the first deployment. A rule applies during pipeline deployment and does not change the source item. If a rule is modified after setup, deploy the content again to apply the updated rule to the target stage.

    12 / 23

  14. Quick check

    A `MaxRows` parameter should be 1,000 in Development and unlimited in Production. What applies that, and when?

    1. AA data source rule, applied when the item is saved

      Data source rules change servers, databases, and connection paths rather than parameter values.

    2. BA Git update, applied at each commit

      Committing records a change in version history; it does not override a value for one environment.

    3. CA parameter rule with a value per stage, applied during deployment

      Right. The rule takes effect during deployment to the target stage and leaves the source item untouched.

    13 / 23

  15. Compare before you deploy

    Before promotion, select the source stage and inspect comparison indicators. An orange icon marks an item that differs between stages, a green icon marks an identical item, and a new indicator marks an item found only in the source stage.

    Indicator Meaning
    Orange The item differs between the two stages
    Green The item is identical
    New The item exists only in the source stage
    14 / 23

  16. Compare before you deploy

    The comparison can also expose items that were deleted or renamed. That matters more than it sounds: a rename in the source stage reads as one new item plus one missing item, and catching it here is what stops a duplicate appearing downstream.

    Reading the indicators is the last cheap moment in the process. Afterwards, whatever was selected is already sitting in the next workspace.

    15 / 23

  17. Quick check

    In the comparison view, what does an orange icon on an item mean?

    1. AThe item differs between the source and target stages

      Right. Orange marks a difference, green marks an identical item, and new content carries its own indicator.

    2. BThe item is identical

      An identical item is marked green, which is the signal that nothing needs to move.

    3. CThe item exists only in the source stage and has never been deployed

      Content found only in the source stage is flagged as new rather than as different.

    16 / 23

  18. Deploy what is ready, and automate the trigger

    Select the items that are ready and choose Deploy to move them to the next stage. A deployment can include everything or only selected items.

    Selective deployment allows a validated semantic model to advance while an unfinished report remains in its current stage. Without it, one unfinished item would hold back everything else that was ready to go.

    17 / 23

  19. Deploy what is ready, and automate the trigger

    Deployment pipelines can also be triggered through the Fabric REST API. Programmatic triggers support CI/CD patterns such as deploying after a successful pull request merge, scheduling a nightly development-to-test deployment, or running validation before promotion.

    Trigger Typical use
    A person, in the portal A considered release
    The REST API, after a merge Promotion that follows an approved change
    The REST API, on a schedule A nightly refresh of the test environment

    The reason to automate the trigger is not speed. It is that the same steps then happen the same way every time.

    18 / 23

  20. Quick check

    A semantic model has passed validation, but a report in the same stage is unfinished. What should the release lead do?

    1. ADeploy every item in the stage so the two stay together

      Deploying everything would carry the unfinished report forward with it.

    2. BSend the unfinished report straight through to Production

      Skipping ahead with unfinished content is the opposite of what staged promotion is for.

    3. CDeploy the model on its own

      Right. Selective deployment lets a validated item advance while unfinished content stays where it is.

    19 / 23

  21. Git and pipelines answer different questions

    Git integration and deployment pipelines solve different lifecycle problems. Git tracks change history, branches, and pull requests for collaboration. Deployment pipelines move content between environments and apply stage-specific configuration.

    The question What answers it
    What changed, who changed it, and when? Git
    Is this content in Test yet? The pipeline
    Which server does this stage read? A deployment rule

    A combined workflow can synchronize approved Git changes to a development workspace and then promote validated content through test and production. They are complements, and neither one substitutes for the other.

    20 / 23

  22. Quick check

    How do Git integration and deployment pipelines divide the work?

    1. ABoth keep change history, so a team can pick either one

      Only one of them keeps history, and in practice the two are combined rather than swapped.

    2. BGit keeps history and reviews; pipelines move content between environments

      Right. A combined workflow syncs approved changes into a development workspace and then promotes validated content onward.

    3. CPipelines keep commit history, and Git assigns stage capacity

      Commits belong to version control, and capacity is a workspace property rather than something Git assigns.

    21 / 23

  23. Key takeaways

    • A stage is a workspace, and a deployment copies selected content into the next stage's workspace; every assigned workspace needs Fabric or Premium capacity.
    • Default stages are Development, Test, and Production, customizable from two through 10 and renameable.
    • Data source rules change connection details; parameter rules override Power BI parameter values by stage. Rules apply during deployment and leave the source item alone.
    • Read the comparison first: orange means different, green means identical, and a new indicator means source-only.
    • Selective deployment can promote a ready item while leaving unfinished content behind, and the REST API can trigger the same promotion automatically.
    22 / 23

  24. Quick check

    Which summary matches how a pipeline promotes content?

    1. AEach stage is a workspace, and a deployment copies selected items forward

      Right. Deployment copies the items you select from the source stage into the next stage's workspace.

    2. BEach stage is a branch, and a commit copies items forward

      Branches are lines of development in a repository, not the environments a pipeline promotes through.

    3. CEach stage is a report page, and a refresh copies items into the next environment

      A report page displays results, and refreshing reloads data rather than promoting content.

    23 / 23

  25. 9 quick checks · then the test

    In the app, finishing the quick checks opens this lesson’s 10-question test, and the ones you miss come back exactly when you’re about to forget them.

    Take this lesson’s test → Next lesson: Dependency Impact AnalysisGet the app
← Previous Keep your progress · Get the app Next card →

The whole course, on your phone

Lessons you can read, audio you can listen to on the way to work, and practice that remembers what you got wrong.

Get the app