Press "Enter" to skip to content

Category: Deployment

Deploying Assets via Azure DevOps and fabric-cicd into Microsoft Fabric

Kevin Chant pushes some code:

In this post I want to show how you can operationalize fabric-cicd to work with Microsoft Fabric and Azure DevOps. Which I exclusively revealed at Power BI Gebruikersdag over the weekend.

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.

Click through to see what Kevin did and how it worked out.

Leave a Comment

Getting Started with GitHub Actions

Kathi Kellenberger takes action:

Shortly before Microsoft acquired GitHub in late 2018, GitHub Actions was released. GitHub Actions is a powerful CI/CD platform that can be used to automate code integration and deployment.

This article series will teach you what you need to know to take advantage of GitHub Actions, especially for deploying database code.

Read on for the first article in the series, which acts as a primer on GitHub Actions.

Leave a Comment

Publishing a Fabric SQL Database

Koen Verbeeck deploys a database:

When a SQL Database is in Microsoft Fabric, you can develop it locally in a database project. As part of the development process, you want to deploy this project to the online Fabric SQL Database. The database project also contains pre- and/or post-deployment scripts that need to be executed as part of the deployment process. How can this goal be achieved?

Click through for the answer.

Leave a Comment

Trying out fabric-cicd

Kevin Chant tries a Python package:

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.

Read on for the test. It currently supports a limit amount of functionality, but it looks promising.

Comments closed

Changing the Source Lakehouse in a Power BI Deployment Pipeline

Chris Webb makes a switch:

If you’re using deployment pipelines with Direct Lake semantic models in Power BI you’ll have found that when you deploy your model from one stage to another by default the model still points to the Lakehouse it was originally bound to. So, for example, if you deploy your model from your Development stage to your test stage, the model in the Test stage still points to the Lakehouse in the Development stage. The good news is that you can use the deployment rules feature of deployment pipelines to make sure the model in the Test stage points to a Lakehouse in the Test stage and in this post I’ll show you how.

Click through for the process.

Comments closed

A Mechanism for Change Management for DBAs

Terri Hurley shares one path:

Back in the day when I received an email from a developer who requested a Production Change, I would copy and paste SQL code from an email to SQL Server to run against a production database. I never bothered to save that code. But later when I was asked for a history of database changes, it was awkward to locate all the previous email requests asking for production changes. Fast forward to present day, most businesses have embraced Change Management Separation of Duties in companies of all sizes.

My preferred path to change management is:

  • All changes go into source control. You can either have the people making changes create the actual scripts to run, or generate them from base changes in source control, dealer’s choice.
  • Each changeset goes to a specific environment when it gets PR’d into the appropriate branch—that is, dev, QA, test, pre-prod, prod, post-prod, next-gen-post-dev-unprod, whatever.
  • DBAs are on pull requests, at least after a certain point. PR to dev? Let the team handle that code review. Once you move nearer to prod, at least one DBA performs a code review.
  • After PR gating happens, your CI/CD system automatically deploys the changes, assuming it passes any continuous integration tests.

This takes time to get right, but it’s very much worth the effort. I worked at a company where they built the release management processes on top of Git + Azure DevOps. You can also use tools like Flyway.

Comments closed

Continuous Deployment in Practice

Bravin Wasike completes a series on continuous integration and continuous deployment:

Continuous Deployment (CD) is an advanced CI/CD practice that takes automation to the next level. It automatically deploys every code change that passes the automated testing phase to production. Unlike Continuous Delivery, which requires manual approval before deploying to production, Continuous Deployment eliminates manual intervention. This allows for seamless and frequent software updates.

Click through for the full article.

Comments closed

Continuous Integration vs Continuous Delivery

Bravin Wasike disambiguates two terms:

Continuous Integration (CI) and Continuous Delivery (CD) are fundamental to DevOps and agile methodologies. They ensure that software is developed, tested, and delivered quickly and efficiently. CI and CD are more than just trending buzzwords. They are crucial processes that help teams deliver quality software at a high velocity. Understanding CI and CD is essential for anyone involved in software development or operations.

In this two-part series, we will demystify continuous integration vs. continuous delivery. In this part 1 article, we will discuss the basic concepts involved in Continuous Integration and Continuous Delivery. The article will highlight primary objectives of CI/CD, their benefits, CI/CD tools examples, key differences between CI and CD and real-world examples of CI/CD.

Read the whole thing. The way I quickly summarize continuous integration, continuous delivery, and continuous deployment is as follows:

  • Continuous integration: you check in code and the build process automatically runs tests to make sure all is well.
  • Continuous delivery: you check in code and, after the continuous integration process automatically runs tests, the continuous delivery process automatically builds the project and makes it available for push-button deployment.
  • Continuous deployment: you check in code and, after the continuous integration process automatically runs tests, the continuous deployment process automatically builds the project and deploys it. No human needs to be involved after check-in if all goes well.
Comments closed

Change Management for the DBA

Terri Hurley moved our cheese:

If you have never been involved in Change Management processes but now find yourself part of one, it may seem a bit overwhelming or confusing. However, the reasons for and benefits of these processes are simple and straightforward.

This article will explain Change Management and how DBAs are involved and can benefit from it.

Read on to learn more about how change management can work for a DBA. I’ve worked for several organizations as they’ve moved from a philosophy of “just do it” toward proper change management, typically for regulatory reasons like Sarbanes-Oxley compliance.

Comments closed