Voice of the DBA

Tag: software development

  • Ship Safe…Ship Often

    The Red Gate tag line has been Ship Often…Ship Safe, which works great for developers. Make the changes to code as fast as you can and get them deployed. Keep things smooth (or safe) with a routine and a standard way of deploying code. Everyone wins, right?

    When we were rehearsing the SQL in the City keynote last year, we came to this line in the script. I wanted it changed. As a DBA, I need to Ship Safe first. If I can do that, then I’m happy to Ship Often, as often as changes can be tested. I haven’t ever worried about changes being made too fast, as long as they can be made safely.

    These two principles seem to be fundamentally at odds with one another. Certainly there is some tension and conflict, but if those pushing through changes can follow a well engineered process, then dangers shrink. If the people responsible for stability and availability accept the changes coming through a process, then they can accept them rapidly and more often.

    Ultimately the closer we move to an engineering process, the more likely that we can deliver software at a higher quality level and quicker. However we need to define our engineering processes using the best practices and knowledge we have, and then stick to the the steps we’ve decided upon. Only then can we Ship Safe, and Ship Often.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.7MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Deploy the Database First

    One of the patterns I’ve seen in some environments is people are trying to deploy changes rapidly to their database backed applications. That’s not news, but what is interesting is some of them are staging the deployment of the database changes first. Not as in I deploy database changes at 8:00pm and then application changes at 8:30pm. These people try to deploy the database changes on Monday, and their application changes will follow on Tuesday, Wednesday, or even a month later.

    It’s an interesting concept, though I think it requires a lot of forethought in your designs, as well as very tight coding from your front ends that won’t be disturbed by extra columns in a result set.  That’s not easy to do, but it’s certainly possible, and it can even be useful if you deploy feature flags extensively in your application.

    As we become more dependent on databases for our applications, and our customers expect systems to be running constantly, I think it behooves us to find ways to make alter and enhance our applications without downtime. While there are patterns to keep applications running when the database goes down, I expect that the reality is that we need to find ways keep the database up as we alter it, which for me means making non-breaking changes.

    I think it’s possible in many cases to upgrade a database over time by carefully planning your schema changes and accounting for those changes in your front end architecture. However it’s not easy, as I mentioned, and you do need to commit to very stable and careful programming practices for your developers.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.9MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • The Cost of Switching

    I read the book Space Prison a few years ago. It’s about a group of humans, attacked and left as prisoners on a harsh planet. There’s a few hundred of them, many dying in the first few weeks. They must fight just to survive against the planet’s weather, as well as it’s plant and animal life. However they persevere and get revenge on the race that left them there. Not the survivors themselves, but their descendents, hundreds of years later. It’s a story about a group of people truly investing for the future. Not one they’ll see, but one their children’s children’s children will experience.

    I thought about that when I saw a post from Ray Terrill asking for AlwaysOn Availability Groups to be a part of Standard Edition in the next version of SQL Server. He makes a few arguments, but one that is interesting is the idea that the other possibilities for databases with good HA/DR cost less. I certainly agree that the cost of switching, and retraining (or rehiring) is high, it’s all about how you approach things.

    If a company really wants to play long ball, to look to the future and start making decisions for not the next year or two, but for ten years in the future, then is the cost of switching high? Imagine I’m a medium sized company with 500 employees. I have some IT staff (10-20) and say 20 SQL Server standard instances for various things. Replacing one SQL Server that provides basic database services now with something like PostgreSQL might slow me down in development for a couple years, but my staff would gain experience, and I’d have options. I might easily be able to replace more of, or all of, my instances in the next five years. Every decision from then on might be whether I get value specific to SQL Server, or can I use another platform that costs less.

    I know that overall SQL Server provides fantastic value and there isn’t anything else that can replace it wholesale, but the base level of database services that many applications need can be provided by other products, and unless Microsoft gives us good value in Standard Edition, I think it’s a matter of time before the people writing the checks start to think about other options. Good security, encryption, and HA/DR are becoming not “nice to haves”, but necessary for many applications. However not so necessary that I think I want to pay Enterprise Edition prices for most of my applications.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.4MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Debugging SQL Server

    One of the tools that I found useful early in my development career was the debugger. Being able to track the values of variables, check the call stack, and pause execution of programs was handy. Early in my career, the tools were very rudimentary, but the latest debuggers in Visual Studio are quite advanced. I remember using a great debugger in Rapid/SQL years ago that helped me with some SQL Server 2000 code.

    There are debugging tools included with SQL Server, but the last time I used them, they seemed to be a bit flaky. However the need to follow your code slowly along it’s execution plan hasn’t changed. I’m curious this week, what many of you do inside of SQL Server to debug your code. I wanted to ask you this week:

    How do you debug your applications that work with SQL Server?

    These could be .NET applications that query the database. You could have ETL processes using SSIS or some other tool that you work on. Perhaps you have a system that runs entirely inside SQL Server and you need to untangle your T-SQL.

    Do you use Visual Studio tools? Have you configured the T-SQL debugger? Are you a PRINT statement or temp-table-for-results developer? Perhaps you have logging or some other mechanism that you use?

    Let us know this week what works well for you, and if you’ve found a particular technique to be handy in a situation, we’d love an article that might teach someone else how to debug their code.

    Steve Jones

     

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.7MB) podcast or subscribe to the feed at iTunes and LibSyn.