A Fine Slice Of SQL Server
Richard Swinbank configures some deployments:
In earlier posts in this series, I talked about to developing and deploying standalone Power BI datasets and automating report deployment into different environments. I’ll bring together those approaches in this post, to enable deployment of shared datasets into multiple environments. This has consequences for automated report deployment, and I’ll take a look at that too.
Read the whole thing.
Comments closedGrant Fritchey explains why stateful systems are difficult to roll back:
The invitation this month for #PGSqlPhriday comes from Dian Fay. The topic is pretty simple, database change management. Now, I may have, once or twice, spoken about database change management, database DevOps, automating deployments, and all that sort of thing. Maybe. Once or twice.
OK. This is my topic.
I’ve got some great examples on taking changes from the schema on your PostgreSQL databases and then deploying them. All the technical stuff you could want. However, I don’t want to talk about that today. Instead, I want to talk about something really important, the concept of rollbacks when it comes to database deployments.
I completely agree with Grant’s description of the pain and his recommendation. With stateful systems, roll forward, not backward.
Comments closedI’ve used several migration frameworks in my time. Most have been variations on a common theme dating back lo these past fifteen-twenty years: an ordered directory of SQL scripts with an in-database registry table recording those which have been executed. The good ones checksum each script and validate them every run to make sure nobody’s trying to change the old files out from under you. But I’ve run into three so far, and used two in production, that do something different. Each revolves around a central idea that sets it apart and makes developing and deploying changes easier, faster, or better-organized than its competition — provided you’re able to work within the assumptions and constraints that idea implies.
Read on for thoughts about three tools: sqitch, graphile-migrate, and migra.
Comments closedRyan Booz relives an older story:
For those of you that don’t know, those ER tools were really expensive (probably still are for the ones that exist) and only a few developers had access to the tool. They didn’t have a great DX either.
Aside from the lack of automation and ability of our developers to be more integrated into the process, there was always the one looming issue that we just couldn’t reconcile.
If Joe left and joined the circus (see, I got you there), we were stuck.
We knew this was a bottleneck for some time and we had tried multiple times to change the process. Our ability to iterate on new feature development went through one person and a set of 15-year-old scripts. It didn’t match our otherwise Agile process of front-end code and data analysis projects.
Read on for Ryan’s thoughts on database change management. Some of the tools mentioned work with multiple database platforms, whereas others are specific to Postgres.
Comments closedRichard Swinbank re-uses a pipeline:
Implementation of one pipeline per report makes additional demands of a developer when creating a new report. To make this easier to manage, in this post I look how to make pipeline creation as simple as possible, by building each pipeline from a set of reusable components.
Click through to see how this works in Azure DevOps. I’d expect the process to be reasonably similar for GitHub Actions as well.
Comments closedVytas Suopys covers a bit of source control strategy:
Have you ever deployed a release to production only to find out a bug has escaped your testing process and now users are being severely impacted? In this post, I’ll discuss how to deploy a fix from your development Synapse Workspace into a production Synapse Workspace without adversely affecting ongoing development projects.
This example uses Azure DevOps for CICD along with a Synapse extension for Azure DevOps: Synapse Workspace Deployment. In this example, I assume Synapse is already configured for source control with Azure DevOps Git and Build and Release pipelines are already defined in Azure DevOps. Instructions on how to apply this this can be found in the Azure Synapse documentation for continuous integration and delivery.
The specific example covers Synapse, though the general principle applies no matter what you’re deploying.
Comments closedRichard Swinbank deploys a report:
In the first post in this series, I built an Azure DevOps pipeline to automate steps in a Power BI development workflow. The pipeline implemented a very basic workflow – as soon as a developer committed a new report version to Git, the pipeline deployed it immediately into a Power BI workspace.
In this post I’ll be building a pipeline to support a more sophisticated workflow that enables peer review and stakeholder testing.
Click through for the step-by-step process.
Comments closedKevin Chant takes us to the edge:
Azure SQL Edge is a version of the SQL database engine that is designed to be deployed on IoT (Internet of Things) devices.
It is based on SQL Server 2019. Which means that by default all new databases are created using the SQL Server 2019 compatibility level. You can lower the compatibility level all the way down to SQL Server 2008 if required.
There was some nice functionality in Azure SQL Edge, some of which (like DATE_BUCKET() and DATETRUNC() made it into SQL Server 2022).
Kevin Chant uses a deployment tool to install a deployment tool for his deployment tools:
I decided to do this post after some feedback I received about SqlPackage after a series of posts about deploying dacpacs to serverless SQL Pools. For example, my post about deploying a dacpac to a serverless SQL pool.
Because in order to deploy dacpacs to serverless SQL Pools you must update SqlPackage.
With this in mind, I thought I better go through various ways to update SqlPackage if intending to use it to deploy dacpacs to serverless SQL Pools.
Read on to see how you can do this.
Comments closedOlivier Van Steenlandt publishes to Azure SQL Database:
During the step-by-step example, we will download the Pipeline Artifact created in my previous blog post. Afterwards, we configure the steps to deploy to Azure SQL. Near the end of this blog post, I will also include a link to my version of the YAML file.
Click through for those instructions.
Comments closed