Voice of the DBA

Tag: Redgate

  • The Company Meeting

    I’m leaving today for a trip to Cambridge, UK. I do this 2-3 times a year, but this one is a little different. I’m being joined by most of my American colleagues at Redgate, all of whom are being flown over to attend a company meeting and a company day out on Friday. It’s one of the rare chances, and quite possibly the only one that will happen again, to get everyone together in the company.

    It’s an expense, arguably an unnecessary one, but it’s also a treat. Spouses and partners have been invited to come along and participate in some fun on Friday. It’s something that stands out in my mind, and it solidifies that Redgate is a great company.

    It’s the kind of company I’d want to build, and it’s run as I’d want to run a company.

    That might be the highest complement I can pay to an employer. They run a company as I would want to do so. They treat people fairly. They treat people with respect. They try to treat customers well, as well as participate in the community. The company is not perfect, but they acknowledge mistakes and try to do better. They work to make a profit, but profit isn’t the most important thing. Perhaps best of all, the management work alongside employees and set good examples. They don’t treat themselves as above or more important than the other employees.

    I’ve worked at a lot of companies in my career, and almost none of them have been companies that I thought were well run with respect for employees balanced with the profit motive and participation in the community. Most were unbalanced in some way, often with respect to profit meaning much more than individuals.

    I’m proud to work at Redgate and am looking forward to the trip with my wife, and a nice weekend in Dublin.

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

  • Implementing Continuous Integration in Redmond

    On May 15, 2015, Redgate Software and one of our partners, Northwest Cadence, will be presenting one of the DLM Training Workshops I helped build in Redmond, WA. I’m excited to be traveling up to WA for the event and helping support Dan Wood as he delivers the training on Continuous Integration (CI).

    This is our Database Continuous Integration workshop, and it’s a great way to learn how you can take your database code and get it automatically tested and built in a CI process. CI has taken hold in many parts of the software industry, but not so much databases.

    This workshop uses the Redgate tools, which make the process easier. However you can just use concepts with your own scripting or other tools. Our goal here is to help you get comfortable with the idea of CI and

    Requirements

    The workshop assumes you have your database in a version control system (VCS). If you don’t, then you should. We have a workshop on using source control with databases as well, but really you should just script our your database and put is in SVN, Git, or something. Or just use SQL Source Control, which makes it really easy.

    The other requirement if you have a laptop with you. We’ve built a number of labs, and we really, really want you to try and implement this yourself. We’ll provide a virtual machine up in the cloud, but we want you to have the chance to actually do the work.

    Register and Learn

    You can register today and purchase a ticket if your company is interested and you want to get some hands on experience with the technology. If you want to learn how to better engineer your software development on SQL Server, and haven’t given this a try (or are worried about it), think about coming.

    Register today

    SQL Saturday #393 – Redmond

    Our workshop is the Friday before SQL Saturday #393 in Redmond, WA. That’s a free event, and you can come there as well. I’ll be delivering a talk there, hopefully on testing, which is certainly important to CI.

    Either way, you can get a full day of in depth training on Friday at the workshop, and then a variety of topics on Saturday at the SQL Saturday event.

    Hope to see you there.

  • Checking Baselines with SQL Monitor

    We’ve got a demo of SQL Monitor available that takes data from the actual SQLServerCentral systems and presents it publicly. The data is slightly delayed, but it’s the real data and it shows the performance of our system.

    I actually use this at times when the site isn’t responding well. It’s quicker for me to hit monitor.red-gate.com than log into VPN and check the real instance.

    I was reading a report for a customer recently and they mentioned they used the baseline feature to track performance of the system when they make changes, using this to decide if they think the changes were positive or negative.

    Note: they rarely roll back, instead using this data to determine if they need to dig into more specifics and then create a new deployment (roll forward) that can address issues.

    Baselines

    There has been a lot written about baselines, but essentially these are a way of capturing what is “normal” for your system. If current performance deviates from normal, you might have cause for concern.

    Of course, this is a gross way of looking at a system and you have to apply some of your own knowledge to determine if you have issues, or some transient workload is altering performance during your sample period.

    You can see a demo of baselines online and play with the ranges. It looks similar to this image below, in which case I can see the last 24 hours of my CPU time, and then compare that with the 24 hours before that.

    baseline

    Using this type of diagram, I can quickly visualize issues that might be occurring without resorting to complex analysis.

    This doesn’t give me the exact problem. I’d still need to dig into the code being run, look at execution plans and other detailed data (much of which I can get from SQL Monitor as well), but this does let me make an initial judgment on where to focus my time.

    I would highly encourage you to run, keep, and update baselines on your system. At the very least, you should have an idea of what types of performance should exist on critical systems.