Since 1999, we’ve been developing tools at Redgate to support database deployments for SQL Server. In the past couple of years, we’ve increased our effort in this space by further developing our proprietary technologies based on SQL Compare, and acquiring others like Flyway, the most popular database migration engine. As a result, we now offer tools which provide more options for SQL Server and also support deployments for 20 different database systems.

Many organizations use out-of-date architecture patterns for developing relational databases which are a pain to manage, slow developers down, and limit testing and innovation. It’s time to modernize these environments and improve standards for database development. In the years I worked as a consultant specializing in SQL Server administration and tuning, I frequently fielded questions from customers about how to best manage databases in development and test environments.

When it comes to reputational risk, a reactive approach is generally taken by organizations, with efforts focused on handling threats to their business they are already aware of. As much as this enables short term damage limitation, it may not be enough to manage and protect your risk in the long term. Instead, a more proactive approach is key to success.

We recently invited our customers to share their top tips for improving productivity in the first Redgate Tool Tips Swap. This post outlines their hints for using Redgate products to boost productivity and includes relevant training resources to further your learning.

Making sure your SQL Servers are secured against malicious users is difficult. How can you know that you’ve done enough? How do you know you’re protected from the things that actually worry you? The United States Defense Information Systems Agency (DISA) publishes a set of guidelines for organizations securing different pieces of software that connect to the US Department of Defense’s networks (DoD).

When PASS announced in December last year that it was ceasing all operations from January 16, 2021, it came as a surprise to many people. For 21 years, it’s represented a global community of over 300,000 data professionals who use the Microsoft data platform. From the PASS Summit to online learning, SQLSaturdays to opportunities to network, its’s been a permanent fixture throughout the year.

Every year, Redgate’s State of Database Monitoring Report reveals how businesses and organizations are monitoring their database estates. Are they using in-house or third-party monitoring tools? Who has access to the data? What are their biggest challenges? The thousands of responses to the survey behind the report offer the answers, and also provide an opportunity to dive deeper and examine those issues at an industry sector level.

How do you handle deployment failures with a single-tenant database architecture? We’ve had a question come up from a couple of customers regarding an interesting use case with Redgate’s SQL Change Automation. In this scenario, customers say: A natural question that arises is what to do when a deployment fails against a single database. For example: One approach that seems simplest to folks is wrapping the entire multi-database deployment into a single transaction.

Why a GitHub account or an Azure DevOps subscription isn't enough to implement database DevOps. A colleague recently relayed a great question from the community: why isn’t a hosted development, collaboration, and automation environment such as Azure DevOps enough by itself to implement Database DevOps? In short, generalized DevOps development and automation tooling does an excellent job at hosting version control repositories and at enabling automation.

Sometimes, people start their DevOps journey by getting their database into source control, but then, they don’t deploy from source control. Instead, they continue their manual deployments to production. Quickly they find that the database code in their production instances and the database code in their source control system don’t match.