Welcome to this lab on implementing Continuous Integration and Continuous Delivery CICD in Microsoft Fabric. We've got three workspaces available, Dev, UAT, and Live. Each one is separate and fully hosted in Fabric.

If we go into the Dev workspace, this is where the other developers will join the process. We'll select Manage Access and add the developers who will be working alongside us. We can add Dev 1 and Dev 2 as contributors.

In the UAT workspace, we'll add the designated testers in the same way. In the Manage Access window, we add Test 1 and Test 2, both set as viewers.

It may be useful to set up the production, the live environment, as well, with users already working on it.

At the moment, these workspaces aren't part of a deployment pipeline. That's what we'll set up next.

We go to the deployment pipeline. On the first page we are asked to create a new pipeline. We have multiple pipelines within our system, but each workspace can only belong to one pipeline — it can't be shared across several pipelines.

So, we create a new pipeline named from Dev to Live and select Next.

We'll see three boxes representing the stages Development, test as the UAT, and Production. We can add more stages if needed and rename them to suit the process. We're not going to do this, so we'll remove it.

We can also change the names of the existing stages, for example, change the second one to Test internal.

Once we're happy with the setup, select Create and Continue.

At this stage, we'll be asked to assign workspaces to each stage. We've already created the workspaces and added viewers to them. We start by selecting the Dev workspace and making sure we tick the check box next to it. It will turn green once added.

We do the same for the UAT.

Notice the list gets shorter as each workspace is assigned.

Finally, select Live workspace to complete the setup.

So, we've got the three stages of the pipeline already set up. We'll see a rocket symbol at the bottom to show us the pipeline is active and is ready to deploy content. We could go into each individual item if we wanted to, just to check what's there.

Right now, they're blank, but we'll be working on them and pushing Power BI content through shortly.

Within the Power BI setup we've got a Power BI desktop file open. If we switch between the options in the left-hand menu, we'll see some basic reports. There are various tables and, in Model view, we can see the schema.

At this stage we're looking at the modelling and setting up roles. Select Manage Roles on the Home tab. Here we've created country-based roles. Each one of these can have different rules.

Now we want to push this up to the server. We go back to Report view, select Publish, and save the changes.

This will send the report to the Dev workspace. So in the Publish window, we select the Dev workspace. We'll see it's currently empty. Once it's deployed, we can check the published version and test it as developers would to make sure everything's working correctly.

So, we go back to the deployment pipeline and refresh the page to make sure the data is up-to-date.

We can see the brown icon for the middle stage, which shows that content is out-of-date. In the development stage, we'll see the items we've just pushed through.

At this stage, we can take a look at the semantic model and the report that's been published. Let's open the report.

If needed, we can go back to the Dev workspace and add new items at this stage. For example, if a developer wants to work online without changing the model, they can select the three dots next to the semantic model and choose Auto Create Report to see what Power BI generates. We're not going to preselect any data here, we'll let it run freely.

Here's the report we wanted. It's got several pages of sales data, with header information across the top. We'll use the Save button to save into the Dev workspace and call it Workspace Report.

Back in the deployment pipeline, we'll see three items in the development stage.

These haven't yet been moved to UAT. If we select the UAT stage, we'll see a status saying the items are only in source. That means they exist in the development stage, not in the destination which is the UAT stage.

Select all items and select the Deploy button. This pushes the content from dev to UAT.

We can add a note for ourselves that this is the initial load. This helps track what's been moved and why.

Once the deployment has finished, we'll see Same as source in the Compared to source column. This means the content in the UAT stage now matches what's in Dev.

We'll also notice a brown icon in the Production stage. That shows there's content in Dev or UAT that hasn't yet been deployed to production, meaning it's out-of-date.

At this point, it's useful to check these security settings to make sure the right users are assigned to the right roles before moving content forward.

On the left, we can see several roles. Let's add Test 1 as an Australian Manager and we'll add Test 2 as a Canadian Manager.

Once that's saved, we go back to the deployment pipeline.

We've got items ready to move into the production stage. The comparison status still shows Same as source, even though we've updated the security settings, because the comparison only checks the content. Security settings can be different at each stage if needed.

We select all items to deploy them to the production stage. We can add a note that this one is “After security added” and select deploy.

Again, once the items are deployed, we can open the semantic model in the production stage and check the security settings.

We can see that security is blank and no users have been assigned to the roles in the production yet.

The security can be different between the stages.

Let's add users here. We'll add Prod 1 as an Australian manager and Prod 2 as a German manager.

Select Save to confirm.

Now that we've added these users, we need to return to the live workspace and check the access settings. Select Manage Access, then add the two new users, Prod 1 and Prod 2, as viewers to give them access to the content.

They can now test the system to make sure everything works as expected, both for themselves and for other users.

We can do the same with Fabric items too.

Let's go back to the Dev workspace. We can see there are already some items here.

This time we're going to create a lakehouse. Select new item at the top, then look for the lakehouse in the list. This is going to be the lakehouse for the CICD. So, we put the name in and select Create.

We can create similar items here too. Let's go ahead and create a subfolder called Sales.

Inside that folder, we'll upload a file. In this case, it will be the products_small file.

Once it's uploaded, we can take a look at the data.

We've got the first row's headers, then, in the Sales dropdown menu, we choose Load to Tables. New table named Sales. The file type is CSV. We'll load it without column headers, keep it comma separated, and select Load.

Once the load is complete, we can have a look at the Sales table. We'll see the columns listed and can preview the items.

This table now counts as a new item in the Dev workspace. We now have CICD, so there are two new items there.

Let's go back to Power BI and make a change to one of the items, in this case 2018 Regional Sales.

Once we've done the update, we're going to redeploy it. We select Publish and select the Dev workspace. We confirm the replacement.

Now, we switch back to the deployment pipeline. We refresh the page to make sure the latest changes are visible.

In the centre stage, we can see the brown icon, which means some of the items have changed. We have the lakehouse in preview mode with Only in source status.

The report we've just updated shows as Different from source. The semantic model is marked Same as source, since it hasn't changed.

We'll now move the updated items into the next stage. To do that, we select the changed items and select Deploy. We can add a note to document the updates in this case after the first change.

Once deployed, we'll see the updated elements appear in the UAT stage with Same as source status. Now, we'll do the same for the production stage. So it's fully updated, we want to make sure all elements are deployed. As at the moment we can see a mix of statuses, Different from source and Only in source, which means some items have changed.

So, just like before, we select the updated items and then select Deploy.

Ideally, each stage should be tested before deployment. In this case, we're deploying to ensure all three stages, Development, UAT and Production, stay up-to-date.

Implement continuous integration and continuous delivery (CI/CD) in Microsoft Fabric​

About

Implement continuous integration and continuous delivery (CI/CD) in Microsoft Fabric