Voice of the DBA

Tag: software development

  • Selling Automation to Ops

    The DevOps movement isn’t new in some companies. It’s the same coordination and teamwork that has existed for a long time between the development and operations staffs. Developers take advantage of the skills in Operations to get standardized environments for their work, and let the Ops people manage (and track) changes. Operations people talk to developers about the challenges and issues faced in production, and the let the developers build applications that can easily be deployed. The sharing of information ensures each group knows what the other faces, and the regular contact builds bonds and respect between employees. Neither wants to let the other down or make someone else’s job any harder than it needs to be.

    However that’s not the case in many companies where developers view Operational staff as complainers that slow the process down. Operations staff see developers as wild and irresponsible, tossing code into production that they don’t need to support and haven’t tested. Both of these views are correct in that each side sees a reality in the process that makes their job more difficult.

    Ultimately I believe it’s up to developers to change things. Those of us that build the software need to respect the problems that instability causes and learn to help ensure that our changes can be deployed smoothly. The development side of an organization has more skill in tracking changes in version control, in managing the movement of those changes among environments, and in programming systems. We should be working to help push that knowledge through to Operations personnel that become responsible for our applications.

    That means we need to build scripts and tools to migrate our changes and give them to Operations. I’d recommend that we learn how to automate the configuration of our development systems, as well as script our changes. Most modern platforms allow us to programmatically make changes, so let’s do that. Then let’s take a few hours and show Operations people how to use these scripts, and let them setup and change our development environments. It will be slow at first, but they’ll learn to make changes faster, but also bring stability to every environment from development to QA to production, and can ensure we have the same configurations everywhere. We’ll have one less thing to manage, and our changes will get deployed faster, but also more consistently.

    Ultimately we all want the same thing. Better software delivered to customers faster. We want to Ship Safe, and Ship Often.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Testing

    It seems that software always contains bugs. No matter how much time and effort is spent building an application, there will be issues. Sometimes this is because of a lack of testing, and sometimes this is because of poor testing, but in any case, the expectation that we will test our code is becoming more prevalent as we depend more and more on computer software. Users expect our software to work.

    It seems there is never enough time to properly test software after it is complete. Perhaps your deadlines are too tight, perhaps there aren’t enough resources to devote to comprehensive testing processes, but it really doesn’t matter. We will never have enough resources in our QA and testing teams to do as much testing as we would like. We need to expect this and find ways to raise the quality of our work, given those constraints.

    One solution to increasing code coverage and ensuring more testing takes place is to move some of the testing burden into the development process. While this sounds like a bad idea, overburdening developers that already struggle to meet deadlines, I’d note that part of the burden of development is fixing the mistakes they make. Perhaps a bit more testing in the development process will help us release fewer mistakes.

    The idea of regular, repeatable, automated unit testing has become quite commonplace in many software development tools and environments, but it hasn’t caught on in database development. There are some frameworks for testing T-SQL, and I’d encourage you to look at our Stairway for TDD as a way to get started or download tSQLt and give it a try.

    We can fix mistakes after our software is released, or we can fix them before the software is completed, but we’ll be fixing them either way.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Recovering from Bad Deployments

    Someone asked me recently if I stored backups of my database in version control. This person wanted to recover from a bad deployment and use a backup to do so. They felt that keeping a copy of the backup in a VCS, alongside the code being deployed, would be important. It might be, but I said that recovering from a bad deployment isn’t something I want to do with a restore if I can avoid it. Then I was asked how to recover from a bad deployment if you have a busy, 24×7 environment.

    I, of course, answered, “it depends.”

    It does depend on the deployment, but it also depends on your preparation. There are ways in which you can work to minimize the problems that might occur during a deployment. Obviously testing your scripts and deployment process is important, but it’s also good for you to understand how your scripts work and what techniques you can use to rollback problematic deployments.

    There’s a switch in SQL Compare that lets you build a deployment script, and then immediately generate a rollback script. It’s handy, but it’s also not going to always work. If you’ve added a column during deployment, you might not want to just remove it on rollback. 

    However you can prepare for issues, like having a script that might save data in the new column before you remove it. You might choose to copy the table as part of a pre-deployment process (or during deployment), having this copy of the table used in a rollback scenario. You might even bring up a warm copy of your database and prepare to swap entire databases if problems arise. This would allow you time to save and move data that was changed after your deployment, but before your rollback.

    There are lots of possibilities in how you might recover from a failed deployment, but as with many of the solutions that we build in technology, a well thought out plan makes everything run smoother.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Citizen Programmers

    The Citizen Programmer, a piece at Simple Talk, really made me stop and think a bit. On one hand, the idea of building a platform that enables any end-user to perform rudimentary programming is a noble goal. If you can do that, then you can dramatically reduce the costs associated with waiting for developers to build applications.

    On the other hand, the article praises the Visual Basic of the 90s, which allowed almost any one to build an application.

    And that was a problem. Despite the tremendous number of applications built, far, far too many of them were poorly written, prone to crashing computers, unable to scale to more than a single user in many cases, and were almost un-maintainable over time. These applications removed people from their knowledge work, having them spend time programming instead of their regular job. That might be good in some cases, where people had talent and desire to build software. It certainly forced the person coding the system to better understand the idea behind the work that they were doing.

    However in many cases, I think we might have ended up wasting lots of time. Certainly the people spending more and more time maintaining an application weren’t necessarily getting more work done. People dealing with buggy software might have been doing their job more slowly overall. There were also the problems with turning a VB application over to professional programmers who were loathe to work on it, and perhaps did little work to keep the application running. A lack of responsiveness from technology departments might restart the whole process with another poorly written VB application, each one a custom work of art that stumbled along inside of a business.

    I do think that giving tools to enable end users to perform some of their own analysis and review of data is important. I like the idea of PowerPivot and other tools that let users query data and build their own reports. I don’t know if we need professional developers for every piece of software, though I am sure we need software to be written faster and in a more agile fashion. In all cases, however, I know we do need professional DBAs to manage data and ensure it’s protected and intact as the speed and scale of our systems continue to grow.

    Steve Jones

    The Voice of the DBA Podcast

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