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.

Options for filtering when generating migrations and when reporting on database drift help teams make the best of tricky database environments. From Enterprises to tiny startups, most developers prefer to do work in small teams these days. But when it comes to database development, teams in Enterprises often have a hard time keeping these small teams fully separate in the development process.

Like every industry sector, 2020 has been a tough year in tech. The pandemic has changed the way we work, it’s changed the way our customers work, and it’s been a rollercoaster ride. In August 2020, IDC’s Global ICT Spending Forecast 2020 – 2023 predicted 2020 revenue in the sector would fall to $4.8 trillion compared to its original estimate of $5.2 trillion.