DevOps can mean a lot of things, but I find in practice that this results in a team using Continuous Integration and Continuous Deployment/Delivery using automation to check and evaluate your software in some way. This should result in quicker delivery of updates and changes to customers, better agility, and higher quality of code.

That last one only comes if you use testing and try to ensure your code is well-written. It's easy to just use DevOps to throw out more poorly written code that doesn't perform well.

Recently, I went to a presentation on Fabric CI/CD, looking to see if I could learn something about how you might handle Fabric in a DevOps software development flow. What I came away with was the idea that DevOps is really just DevOps. In this case, Azure DevOps was being used to orchestrate the CI/CD flow, and it looked the same way I had set up a flow for a relational database.

There are differences, such as the need to have multiple Fabric workspaces and a need to understand how the code is stored and managed in Git, but the idea is the same. We use a build step to verify that any code changes can be successfully compiled and that those changes can be deployed to a new location. A workspace instead of a database, which means the code doing the work is slightly different, but the process is the same.

Testing? You want tests to verify that the code does what is expected. A lot of people skip testing with data, but I'd argue it's as important in Power BI or SQL Server as it is in C#. We ought to include tests, not because we don't know how to write code, but because others might maintain/extend/refactor our code, and we want their changes to pass our tests. Again, the details are different, but including a step to run tests is the same.

Using a flow to approve and deploy changes between environments? This is no different, and having an automated process reduces the effort, time, and risk of mistakes. This is again the same, though the details are different specifics because the code is different. Deploying a semantic model is different than pushing out a new .exe or running database changes, but the idea of an automated deployment is the same.

We, as an industry, have learned over time how to better move code through a software development life cycle. The ideas work for data-based projects as well, and we ought to be learning and adapting these to ensure we can be just as agile as application software developers.