If developers cannot deploy their code locally, then there’s a significant problem here that needs addressing. That’s why, in the context of SQL Server database development, the use of a publish profile becomes almost essential, by allowing you to ignore problematic components, such as Active Directory scoped user credentials.
A few weeks ago, I did a post on the process involved when migrating Microsoft Azure Cloud Solutions Provider (CSP) subscriptions across tenants. Having done some actual work relating to this since then (shock horror!), I thought I'd follow up with a new post, sharing some additional thoughts and lessons learned.
Microsoft Azure can throw up all sorts of different error messages when creating and updating resources. Typically, it will be straightforward to resolve these, with the exception of one I recently had to deal with involving Azure SQL Server failover groups…
One of the best things about Azure Data Factory is its ability to incorporate continuous integration and automated deployments quickly alongside your solution. However, if you’re working with SQL Server data sources and are using square brackets to interact with tables, then you may be in for a bumpy ride…
I’ve worked with SQL Server for several years now, and I am continually amazed at its capabilities, Recently, my work in this area has focused on the products change tracking feature, a nifty tool that can assist you in monitoring how your data evolves.
Obscure error messages can be the bane of an IT professionals life, often hampering or even preventing outright any successful resolution of issues. An example of this happened to me recently, during what appeared to be a run-of-the-mill Azure SQL automated deployment.
When you are amid a pesky IT issue, it can be difficult determining whether the problem is down to a bug/system fault or human error. Like this recent example involving Azure Data Factory illustrates, it is generally best to assume the latter, to avoid any prolonged difficulty.
We saw a few weeks ago how to utilise Azure Active Directory (AAD) Security Groups to manage Azure SQL database access at scale. When using this feature, you must ensure database changes are deployed out using an AAD administrator account or similar, a task which may be difficult to achieve in an Azure DevOps Pipeline.
Azure SQL Server has long supported the ability to use Azure Active Directory user accounts to access and work with databases. What you may not know is that it is also possible to add users via membership of a security group, a feature which, I believe, is incredibly useful for managing large-scale deployments.
Web application releases are a scary affair and, depending on the criticality of your system, you may need to put yourself in a position where changes, such as a SQL Server database upgrades, can be rolled back immediately. Fortunately, when using Azure DevOps, it's easier to do then you may think...