Voice of the DBA

Tag: Redgate

  • Learning Continuous Integration for Databases – LA Apr 10

    I’ve been talking about continuous integration for databases for a couple years now as a part of my job. My employer, Red Gate Software, has been building tools to help database developers build better software. We (Red Gate) want to sell software, but we also really want to help people build better software. It’s a big reason why I’m employed there. Red Gate truly wants to make the world a better place while we run a business.

    I’ve gotten lots of interest and questions from my one hour talk and late last year Red Gate decided we needed to do more. We built some all day continuous delivery classes last year and they went over well. Over the winter, Grant, myself, and a few others at Red Gate got together and we’ve been working on adding depth to our instruction and have come up with 3 full days of training to help you build better database software, quicker.

    Continuous Integration in LA

    The middle class we’ve developed is an all day look at how you implement a continuous integration process with a database and application. On April 10, 2015, I’ll be coming to Los Angeles, CA, along with one of our partners, Ike Ellis, to work on a full day of training. It’s a $500 class, but you’ll walk through a couple of different ways to set up a CI process, actually perform the steps yourself, and make changes to the database that get built and tested.

    We think it’s a great way to smooth out your development process and bring more engineering to the way you deploy database updates. Ike is an expert SQL Server consultant and he’ll show you how to create your own CI process. I’ll be in the background to help out, and we think you’ll gain some in depth knowledge that you can use at your job right away.

    If you want to advance your database development, register today and join us in LA on April 10, 2015.

    register

    I’m excited to be a part of these classes, and I hope you are as well.

    We do cover a number of Red Gate tools in the classes, but the procedures and steps are applicable to other methods of accomplishing the same tasks. Even if you choose to use other tools, or write your own, the skills we teach you will be applicable.

    I wouldn’t write my own, however. I’d easily burn the cost of the tools many times over trying to iron out the bugs in my own process.

    The Continuous Delivery Process

    The whole idea of continuous delivery is that you can make changes at anytime. It isn’t sloppy work, untested development, or anything else. This is a way to bring more engineering to software development, and I really believe in it.

    It’s not easy, however, and that’s why we’ve built three days of training. We cover these items in the three days.

    • Day 1 – Version Control for Databases
    • Day 2 – Continuous Integration for Databases
    • Day 3 – Automated Deployment

    We haven’t set these up all in one week, mainly because it’s too much information for you at once. Ideally we want to tour around, running one of these classes each quarter, because it will take you a few months to implement the information and understand it.

    If you get past these courses, we’re also partnering with expert ALM consultancy shops that can help you even more.

    We’ve got a number of all day events coming up for you to consider, so check out our list of training days. We’re adding more all the time, and let us know if you want us to come to your area.

  • 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.

  • DLM Workshops

    We’ve got a bunch of DLM workshops coming up in the next few months from Red Gate Software. We’ve been working on trying to bring some depth to our education, helping DBAs and developers learn how to built smoother software development pipelines for their databases.

    The list of workshops is at http://www.red-gate.com/training/workshops/ and we’ll be updating it throughout the year. In this series, I’ll be at these events

    • Mar 10 – Dublin
    • Apr 10 – LA

    Certainly more are coming later in the year that I’ll deliver or help out at.

    We’ve built a series of three days of in depth instruction, each one building on the next. Our hope is to help you move through the subjects. Right now the days are covering these topics.

    • Version Control for Databases
    • Continuous Integration
    • Automating Deployments

    We are looking to try and schedule these over time in a city, so that you’ll be able to learn about VCS for databases, then come back in 3-4 months and take the next step to CI. We might do all three days consecutively, but it’s a lot to learn and cover, and I’d really hope that companies would learn one area, implement it, and then come back to learn the next step.

    If you have requests for dates or cities, or even private instruction, let us know. We’re growing a list of partners as well because Grant and I can’t be everywhere, so we hope to be able to help more people learn ways to build software smoother and quicker.

  • 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.