Skip to content

Initial tests of fabric-cicd

Reading Time: 5 minutes

In this post I want to cover my initial tests of fabric-cicd. In order to provide some tips for those looking to work with this new offering.

Just so that everybody is aware, fabric-cicd is a Python library that allows you to perform CI/CD of various Microsoft Fabric items into Microsoft Fabric workspaces. At this moment in time there is a limited number of supported item types. However, that list is increasing.

One of the Microsoft teams previously shared details about fabric-cicd in a Microsoft Fabric subreddit post. Last week they published an article to introduce to the fabric-cicd Deployment Tool.

To manage expectations, this post covers my initial tests of fabric-cicd on my local machine. Along the way I share plenty of links.

For this post I created a Microsoft Fabric workspace and got the workspace id from the URL. Which I refer to in this post.

Quick way to get started

I wanted to perform my initial tests with the sample items provided. So, I cloned the fabric-cicd GitHub repository onto my local machine. From there I opened Visual Studio Code and navigated to the sample subfolder.

From there, I opened the “auth_default_credential.py” file and entered the value of the Microsoft Fabric workspace ID mentioned earlier in this post. For the environment I entered “PPE”.

For the repository directory I entered the path to the sample directory. I got the path quickly in Visual Studio Code by right clicking the file and selecting “”Copy Path”.

I then opened up the terminal in Visual Studio Code. In order login to the tenant with my Microsoft Entra account via the az login command.

Note: if you are working with a trial tenant, like the ones provided with Microsoft 365 Developer Program, then I recommend logging in with the below syntax:

az login --allow-no-subscriptions

Anyway, once I had logged into Microsoft Entra I ran the Python script in the terminal.

Running the Python script in the terminal to perform initial tests of fabric-cicd
Running the Python script in the terminal

Note: when running fabric-cicd you occasionally get a message appear that a new release of fabric-cicd is available. You can upgrade it with the below syntax:

pip install --upgrade fabric-cicd

Another thing I want to highlight is that even though specifying a period (“.”) as the repository directory works for deployments it can cause issues. More about this later.

Because I had updated to the latest version, I decided to test deploying Lakehouses as well. Which I did by updating the item_type_in_scope parameter.

item_type_in_scope = ["Notebook", "DataPipeline", "Environment","Lakehouse"]

I then ran the Python script in the terminal again. Afterwards, Lakehouses appeared in the workspace as well.

Sample items deployed in a Microsoft Fabric workspace including Lakehouses
Sample items deployed in a Microsoft Fabric workspace including Lakehouses

Testing fabric-cicd parameterization

Deploying the Lakehouses inspired me to test fabric-cicd parameterization. Because I often need to change the default Lakehouses within notebooks. Like I mentioned in my previous post about authenticating as a service principal to run a notebook.

I first created a new Lakehouse called Bronze. Afterwards, I updated the “notebook-content.py” file that came with the sample notebook in Visual Studio Code. In order to add the Bronze Lakehouse in the workspace as my default Lakehouse for the notebook.

# META   "dependencies": {
# META     "lakehouse": {
# META       "default_lakehouse": "(GUID of Bronze Lakehouse)",
# META       "default_lakehouse_name": "Bronze",
# META       "default_lakehouse_workspace_id": "(GUID of workspace)"
# META     },

From there I ran the “auth_default_credential.py” script again and checked that the default Lakehouse was the Bronze one.

Notebook with the Bronze default Lakehouse
Notebook with the Bronze default Lakehouse

Afterwards, I went into the “parameter.yml” file in the workspace subfolder and specified the below in the find_replace options. Bearing in mind that I had set the environment to PPE.

find_replace:
    "(GUID for Bronze Lakehouse)": # lakehouse GUID to be replaced
        PPE: "(GUID for Bronze Lakehouse)" # PPE lakehouse GUID

Adding the find_replace option in the “parameter.yml” file allows me to specify values I want to be replaced when I run fabric-cicd.

In the code shown above, the first value is the GUID for my Bronze Lakehouse. Whereas the second GUID is for my Silver Lakehouse. Note that I did not enter a change for the Lakehouse name.

One key point to note here is that currently the repository directory you specify in your deployment Python file must be the absolute path. For example:

repository_directory = "C:\\repos\\fabric-cicd\sample\workspace"

If you add a relative path fabric-cicd will still perform deployments but the parameterization will not work. So, avoid working with the below syntax.

repository_directory = "."

Anyway, I then ran my deployment script again. Afterwards, I refreshed the notebook in order to check that default Lakehouse had changed to Silver.

Notebook with the Silver default  Lakehouse after using parameterization during initial tests of fabric-cicd
Notebook with the Silver default Lakehouse

As you can see, using the find_replace functionality opens the doors for some interesting possibilities. Such as dynamically changing connections for different environments.

Initial testing of fabric-cicd with a service principal

After testing the deployment, I deleted all the items in my Fabric workspace and removed the default Lakehouse reference in my notebook file. In order to test deployments performed with service principal credentials.

First of all, I provided my service principal adequate permissions in my Microsoft Fabric workspace. I then opened up the “auth_spn_secret.py” sample file and entered my service principal and tenant details.

Note: If you intend to do this, never synchronize the local clone of the repository onto a public repository, ever. Otherwise, your service principal details can end up in the public domain.

Afterwards, I ran my “auth_spn_secret.py” file to deploy all the items.

Sample items deployed in a Microsoft Fabric workspace with a Service Principal
Sample items deployed in a Microsoft Fabric workspace with a Service Principal

As you can see in the above image, Lakehouses can also be deployed with a service principal.

Plus, the service principal is the owner of most of the deployed items. Apart from the default semantic models for the Lakehouses. Which highlights the fact that deploying this with fabric-cicd can help avoid potential ownership issues.

Final words about my initial tests of fabric-cicd

I hope that by sharing my initial tests of fabric-cicd I am encouraging more of you to start testing it. Because fabric-cicd has a lot of potential.

Of course, if you have any comments or queries about this post feel free to reach out to me.

Published inMicrosoft Fabric

2 Comments

  1. Daniel Blomdahl Daniel Blomdahl

    Hey! Thanks for a great blog post!
    Last night there was an update regarding connector to lakehuses from pySpark and notebooks. Do you think this could eliminate the need for extra search and replace? Because it seems it can connect to the right warehouse within the same workspace..?

    Or is it still required to have a unique name so you still would have to do search/replace?

    https://blog.fabric.microsoft.com/en-us/blog/spark-connector-for-fabric-data-warehouse-dw-public-preview/

    • Kevin Chant Kevin Chant

      Hi, I think it depends on the context. At the moment, the find_replace option is useful for replacing the values of for default lakehouses. Yesterdays announcement is more for those who wish to work with Warehouse tables directly from Spark.

Leave a Reply

Your email address will not be published. Required fields are marked *