Press "Enter" to skip to content

Category: DevOps

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.

Leave a Comment

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

Running a Microsoft Fabric Notebook via Azure DevOps

Kevin Chant runs a notebook:

In this post I want to share one way that you can run a Microsoft Fabric notebook from Azure DevOps.

You can consider this post a follow-up to my last post about unit tests on Microsoft Fabric items. Since somebody asked me about automating notebooks and I wanted to show it in action.

Please note, currently the ability to call the API that runs a notebook on demand does not support service principals.

Despite that limitation, Kevin shows two ways to authenticate while calling the appropriate API.

Comments closed

CI/CD in GitHub

I have a new video:

In this video, I explain what continuous integration (CI) is, disambiguate continuous delivery from continuous deployment (CD), and see how you can perform CI/CD operations using GitHub Actions.

Read on to see what these terms mean and an example of how it all works with .NET projects.

Comments closed

Going with the Flow: GitHub Edition

I have a new video:

In this video, cover the GitHub flow. We talk a bit about branching strategies and how GitHub development ought to look in a multi-developer situation.

The GitHub flow is a minor variant from the classical Git flow, but one that works well with the ethos of development specifically in GitHub. It’s often overkill for a single-developer repo, but once you have a team working on a problem, this is a much more efficient approach.

Comments closed

Learning about GitHub Actions

I have a new video:

In this video, we dig into GitHub’s process for executing code: GitHub Actions workflows. We’ll learn what Actions and workflows are, how we can create them from scratch, and how to incorporate Actions from the GitHub Marketplace into our own workflows.

Along the way, I describe what GitHub Actions workflows are and we build a simple one. I’ll have more videos coming up that expand on GitHub Actions and show you more of what you can do with them.

Comments closed

The State of CI/CD in Power BI

Paul Turley violates Betteridge’s Law of Headlines:

The answer – finally – is a resounding YES! It has been a long road and the path to implementing Continuous Integration & Delivery (CI/CD) in all of its forms for Power BI is still a journey, but the capabilities are now a reality. This broad category includes a range of features and capabilities related to managing project files with version control and the ability to share and collaborate with other development team members. Additionally, we also have the ability to assign individual components of a solution to different team members who then check-out files and develop features, check them back in and merge changes into a feature branch. In enterprise-class projects, having these capabilities enables true Development Operations or DevOps: a process for managing iterative development, testing and deployment with automated builds, using a central process management tool. Implementing full-fledged DevOps is a big lift for most Business Intelligence professionals but the core concept of code version control is essential for any durable project.

Read on for Paul’s thoughts on the importance of source control and how you can pull this off.

Comments closed

Git Integration for Power BI Reports in Microsoft Fabric

Kevin Chant gives GIt integration a try:

To manage expectations, this post covers:

  1. Brief overview of Microsoft Fabric Git integration.
  2. How I converted a Power BI report to a Power BI Desktop project containing metadata files.
  3. Converting the folder that contains the Desktop project into a Git repository.
  4. Synchronizing the Git repository with Azure DevOps.
  5. Setting up Microsoft Fabric Git integration.
  6. Initial tests.
  7. Interesting workaround to deploy a second Power BI report using metadata.

Read on for Kevin’s thoughts.

Comments closed

Deploying Azure Resources with Terraform and GitHub Actions

Reitse Eskens sets up some new resources:

When you start out with Terraform, you’ll most likely run the code locally with terraform on your own machine. Terraform works with a so-called state-file, it saves the state of the Azure deployment it left behind and compares the (new) code with the state it encounters when it runs again. Changes are resolved by changing, deleting or adding resources that don’t match the state-file.

This works fine when you’re flying solo and don’t have co-workers who can change resources as well. Whenever you need to share code, the industry standard is to use a git solution, whether GitHub, GitLab, Azure DevOps or some other solution, as long as it has version control you should be fine (providing people adhere to the correct usage of branches).

Click through for a step-by-step walkthrough, as well as explanation of the major actors in that play.

Comments closed

Creating Sprint Review Reports with Azure DevOps and Fabric

Kevin Chant checks the burndown:

In this post I want to cover using Azure DevOps Analytics views and Microsoft Fabric to create Sprint review dashboards.

I consider this post to be a sequel to one of my post popular posts that covered using Azure DevOps Analytics views and Power BI to create Sprint review dashboards. For four very good reasons.

Read on for those reasons, along with the steps Kevin took.

Comments closed