Voice of the DBA

Tag: continuous delivery

  • What is the DLM Maturity Model?

    I’ve written a few posts on the Redgate Software blog to try and show how I see the DLM model, and how we see things at Redgate. We have a lot of developers that work in a similar way when building application software in C#, Java, Python, or other languages, and much of the company is trying to bring more engineering to database development.

    Part of what the DLM maturity model aims to do is help us classify how we progress to a more engineered, repeatable, and reliable way of managing database development. You can read my overview, and then dive into each of the various levels we’ve built. The levels are:

    Some of this is based on the CMMI model from the SEI, and some is based on what application developers are doing with their own continuous delivery mode. Simple Talk has written a What is DLM? article as well, and includes a different view of a maturity mode.

    I think this process becomes more important over time as we depend more on software and the databases behind them, with fewer and fewer tolerances for downtime or human mistakes in the deployment process.

    I’d like to get feedback from people on what they think of this model, and of the idea of engineering better database development. I know many people have built their own process, but far too many of the processes rely on custom scripts that are built and edited for each deployment, sometimes in the middle of the deployment. I think we could actually make database development better if we applied some better structure to our deployment.

    Redgate is working on tools to support this, in a few ways, but this isn’t about Redgate. Rather, it’s about building better software for everyone, whether you use Redgate tools, another vendor’s tools, or build your own. Follow a better engineering process.

    If you’d like to know more about the CMMI model, Alex Nordeen built a fools guide to the framework. It’s easier to read and understand than the CMMI site.

  • SQL Saturday #390 – Philadelphia Recap

    I was at SQL Saturday #390 in Philadelphia last week and it was an exciting, but short time. The event was at the end of a  five day trip for me, Seattle first and then Philadelphia, so I was tired by Saturday morning. However I enjoyed it, met lots of people, and learned a few interesting things.

    Unit Testing with SQL Server and tSQLt

    Friday I taught a pre-con event with Sebastian Meine on unit testing your T-SQL code with tSQLt. We had 9 people signed up, which was encouraging. Not a raging success, but certainly better than the 2 people that some friends had predicted. Everyone was interested in unit testing and producing better code.

    The day went well, and we ended a touch early. There were some good comments and suggestions from people on unit testing techniques, including a solution to one of our exercises that I hadn’t expected. I learned a few places need the demos to be expanded a bit, but overall it felt like a good start to teaching unit testing. I’m looking forward to trying this at a few other events in the future.

    standing in front of the class

    Better Development at SQL Saturday

    I was really only able to attend a few sessions (in addition to the one I taught) at SQL Saturday #390. However I was pleased to see that after my CI session, there was one on Continuous Delivery, and then one on Git for DBAs. Both of these topics are important, and well attended, which makes me think that more people are starting to lean towards building more engineered database development processes.

    My CI session went well. I didn’t get to show the failing CI process based on a test and more data, but I did get lots of good questions that I need to answer in the next few weeks. A few of them (for me to remember).

    • How do I get started with a small development team?
    • How do I start adding tests in an existing software project?
    • Can you demo a column rename (or table rename)?
    • Show static data flowing through the process

    It’s good to get questions, and I hope I answered them all. If I didn’t, or you need clarification, let me know.

    Once I finished, I wandered over to see Mark Wojciechowicz talk about Continuous Delivery. Mark is a consultant that’s trying to keep a CD process working at a client’s site. He’s been working at it for awhile and we talked about it Friday (he was in my class) and Saturday. It sounds like he has some good things going, and using a home grown process that works well.

    He showed some of the reasons why CD matters, especially for his client. They make lots of changes, and use a smooth process to push through bug fixes as well when there are issues with something in production. I hope he gets his deck up soon because he had some good quotes and notes in the PPT.

    I especially like his thoughts that if something hurts in software, you should do it more. That comes from Thoughworks and some of the progressive companies that are rapidly building high quality software and don’t let the problems of deployment slow them down. They tackle those issues just like others, and you should, too.

    From there I saw Justin Dearing talk about Git and DBAs. He’s a developer and tends to like the command line, but he showed how we can use Git for a VCS in the command line, but also from SSDT. That’s an interesting approach, and while I liked his message, I think some of the people there using a CVCS, like TFS, didn’t understand why Git matters. I need to write more on this as well.

    Justin had a minor issue with branching, not because he doesn’t do it well or understand it, but because he’s moving fast and talking. That’s what I am, in general, against branching. The real world moves fast, it’s easy to get caught up with some other thoughts and get lost with branching. I need to formalize my thoughts as I’ll be talking branching at DevConnections (register and come see me in September).

    Overall a good time and people seemed to really enjoy the SQL Saturday. I had about 20% of my attendees that were new, which is great. I hope to see more and more people coming to the events in the future.

  • Database Lifecycle Workshops

    Trying to implement version control, and Continuous Integration (CI), and automated releases of code is hard. The concept is simple, but all of the various processes, tools, and links that need to be connected can be hard. I’ve seen too many organizations that struggle to get started, often because they see the entire process as just too complex and overwhelming.

    It’s not.

    Whether you’re trying to release application code or database code, you need to treat them in a similar manner. While there are lots of books, tools, blogs, and companies that can help you work with application code, the database has been more challenging.

    At Redgate, we’ve put together a few workshops to help break down the stages of engineering your database delivery and get you moving to help smooth the process of making database changes. These workshops are coming to locations all around the US and UK in the next few months. Check out our schedule, which has dates in :

    • Bellevue, WA (May 15)
    • London, UK (May 20)
    • Philadelphia (June 4)
    • Belfast, Northern Ireland (June 26)
    • London (July 8)
    • San Diego, CA (July 16)
    • Manchester, UK (July 24)
    • Baton Rouge, LA (July 31)

    There are more dates, and we’re certainly open to scheduling more locations and even private classes if you’d like. Contact us if you have a request.

    Most of these classes are delivered by experienced partners of Redgate, often consultancy organizations that have been working with clients for years to build smoother application delivery processes, and are moving into the database space. The classes use our tools, and Grant, myself, or one of our other Redgate experts will be on hand to help you learn the skills you need to start implementing DLM concepts. We can even recommend consultants to work with you for a two day DLM Health Check or on longer term projects that help you build better software. Contact DLMPartners@red-gate.com for more information.

    We find that many of our customers are struggling with different parts of building a smooth software pipeline. They want to get better, and they find the Redgate tools help, but they need a little push or confidence to implement an engineered process.

    Our three workshops are designed to teach you about different parts of a DLM environment. They map to the Database Lifecycle, helping you move to a different stage and a better engineered process at each step. The three workshops are:

    • Database Source Control – getting your database code into a Version Control System and dealing with the issues of branching, merging, team coordination and more.
    • Database Continuous Integration – learning to automate the building and testing of your code each time a change is checked into a VCS. This lets you find issues quickly.
    • Automated Database Deployment – Gain the skills to automatically generate upgrade scripts and ensure they are tested and deployed smoothly, without any of the release day stress many of you experience.

    These classes won’t solve your DLM challenges in a day, but they’ll give you the skills and confidence to move forward. Ask you boss to send you and get a bit of training to help you start building better software.

    Come join us and learn to ship often and ship safe.

  • No State Based Deployments

    I’ve been studying deployment ideas and technologies for quite some time now, but it’s been a focus for the last year or two as my employer is interested in this area. I’ve been reading books and talking to people, comparing their experiences with my own. I’ve found that deployments for databases are much more complex than those for other software, but essentially there are two approaches that people choose: migrations and state based migrations based deployments.

    Migrations based deployments are based on tracking each change to a database in a separate script and then executing each script, in order, on your production database. This is hard to do, requires discipline, and is what most people find difficult to do. Scripts get quite numerous, ordering is hard, and deployments become scary and largely unsuccessful without a lot of care. The scripts require tweaks and fixes to work efficiently, and you need smart DBAs and developers.

    State based deployments are what many people try to use. They look at the state of production, the state of development, run some tool like SQL Compare, or a process, and determine what changes need to be made to production to get it to match development. There are variations, but this is the basis for how many people try to create a deployment process. It seems easier.

    The problem is that at some point a state based deployment process won’t work. It’s actually impossible for a state based approach to work in all situations. Simple actions, like renames, can’t be handled by examining two states. In order to properly manage changes, and keep your data intact and safe, you need to understand “what” happened during the process, not just the end result.

    In many situations, state based deployments can work, and they can be used successfully, but there is always the possibility that you’ll need to customize your state based approach to include some migrations scripting. Keep that in mind, and make sure that any process or tool you choose has that flexibility. If you understand you need to review and modify scripts at times, you should be successful.

    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.