I’m really excited for Redgate’s new SQL Change Automation plugin for SQL Server Management Studio (SSMS). SQL Change Automation lets DBAs and developers use a migrations-first approach to create precise scripts to apply changes to your database. If you’re curious about what I mean by “migrations-first”, read more about this approach, and how it compares to a state-first approach here.
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!
Sometimes you keep a classic around.
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.
You’re a DBA, and your development team is all-in on doing DevOps, and they want to include the database. Should your DBA team limit the permissions or options for automation? Or should you instead re-think how your two teams work together?
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.
Today I was looped in on an email thread about the pros and cons of attending a specific event. One person on the thread asked if any of us had attended the event in the past, and whether or not event attendees were engaged with presenters and vendor representatives.
My immediate thought was: of course the attendees were engaged, because the event is a SQL Saturday. I’ve never been to a SQL Saturday where the attendees weren’t engaged.
But, I realized that it’s a fair question.
I recently realized that I’m in the early stages of burnout.
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.
Today I got a bit closer to a meaningful definition of automation, as it applies to the software development process. I’ve been turning this concept over in my head for a while, which is partly related to the dreaded question of licensing.
I got a question recently about a panel discussion on Database Development Disasters at SQL in the City Streamed. I had framed a question as, “how fast should development go without load or performance testing?”
I’m excited to be teaching a full day session with Steve Jones at the SQL PASS Summit on Tuesday, November 5, in Seattle.
Steve and I will be discussing proven patterns to version and deploy changes successfully.
Calling all Database Administrators, Developers, Analysts, Consultants, and Managers: Redgate has a survey open asking how you monitor your SQL Servers.
This morning, I received the following question from a user:
Could you please clarify SQLServer “Data Row” size:
If I run the script below on SQL Server 2012, then Slot(row) Size is 710 bytes
if I run the same script against SQL Server 2016 and above, then Slot(row) Size is 724 bytes.
I’ve recently published an article, “Why You Shouldn’t Hardcode the Current Database Name in Your Views, Functions, and Stored Procedures,” over on Simple Talk.
Are you interested in speaking at the Professional Association for SQL Server’s annual Summit conference? The call for speakers is now open, and you may submit up to three sessions between now and March 31, 2019.
Redgate is building a library of real-world stories about database development disasters.