Have you ever tried to create an object in SQL Server, but it failed due to a missing table, column, or other dependency? If so, you’ve hit a case where SQL Server doesn’t offer ‘deferred name resolution’.
This post is part of TSQLTuesday #140, “What have you been up to with containers?"
Disposable databases are indispensable for software developers, both for initial development work and in automation pipelines. Containers pair exceptionally well with temporary databases and provide a lightweight mechanism to spin up an environment on demand.
When I woke up today in the UK, Twitter was alive with jokes, hot takes, and sympathy about an email sent out to millions of folks on a contact list for HBO Max featuring the subject line, “Integration Test Email #1”.
One big gotcha that teams often encounter when automating deployments for databases is that it’s difficult– or sometimes impossible – to ensure that all changes to the production database are performed through the automation pipeline.
These out-of-band changes case the production database to “drift” away from the schema as defined in version control.
I believe that language matters, and that it is worth our effort to move away from language associated with slavery and racism whenever possible.
I used to make fun of YAML because I was scared of it. I still make fun of YAML, but I’m not scared of it anymore now that Rob Sewell showed me how to avoid having to write it myself.
I’m working on a project where it’s useful to automate environment setup and teardown for testing some devops deployment scenarios for databases using transactional replication.
When implementing any kind of automation for database deployments, it’s important to implement safeguards for your production environment. This is needed even in the best conditions when team members collaborate well and there is a high level of trust, for a very simple reason: accidents happen easily!
When people begin applying DevOps principles to database development using Redgate tooling, often one of the first steps in the process involves getting database code into version control. Questions naturally come up about how to manage the flow of changes to database objects from development into production once changes begin occurring.
The other day, I was looking back at an excellent blog post my colleague Jamie Wallis wrote about what Product Marketing Managers do at Redgate. I really like the chart he created which explains how Product Marketing Managers work with Product Managers – what each role focuses on, and where they collaborate.
I realized that my own role as an Advocate can also be hard to understand.
Fall is in swing, and it’s officially webinar season! Here’s a bunch of free events I’ve got on my calendar.
In this video, Freyja the puppy and I talk about a recent workshop which I facilitated at the IDC DevOps conference in London.
Here’s a quick post on something simple which stumped me for a while, in the hopes that search engines help someone else who gets confused in the same way.
Recently, I was doing a bit of work in Azure DevOps Services, preparing a demo for an upcoming webinar. I ran into a simple but frustrating problem.
This is the first in a series of posts about simple things that I had a hard time figuring out in Azure DevOps services.
It can be very useful to enable Continuous Integration for multiple folders in your DevOps pipeline – say, for every branch created under releases/ or features/. But configuring this can be strangely confusing!
Like a lot of developers and database administrators, I do a fair amount of short-term problem solving during the course of my normal work week.
Building your database code is an essential practice to ensure that it compiles from source and that dependencies are met. But things can get tricky when you have objects in some databases which is dependent upon objects in other databases – or even circular dependencies.
I recent chatted with some folks who have a permissions problem in SQL Server. The permissions problem isn’t technical – it’s a process problem.
One of the cool things that I do as an Evangelist at Redgate is to periodically visit company headquarters in Cambridge. The other Evangelists and I get to meet with every software developer, product manager, and UX designer at Redgate over a series of meetings. That’s really cool. We talk about things that they’ve released lately, what they’re looking at doing in the near future, and we get to give feedback based on what we hear from the community and from folks in the sales process. We also get to share what we personally think should happen in these products now.