Voice of the DBA

Category: Editorial

  • What’s Your Smoke Test?

    Many DBAs and operational staff regularly stress over software deployments to production systems. Even when the administrator has built and tested the deployment scripts, there is still a nagging fear that something will be missed, incurring downtime for systems. I think automation, building an ALM And DLM process, as well practicing deployments in other environments is the way to alleviate concerns, but that’s a discussion for another day.

    However, I had a question this week that is related to the deployment process. I’m curious, do you smoke test your production deployments?

    Perhaps the first question is do you know what a smoke test is? If you don’t, maybe you want to read a bit about smoke tests. If you know about smoke tests, do you have anything more than testing if a server or service is running?

    If you don’t, that’s fine. In fact, throughout most of my career our smoke tests consisted of checking that we could connect to a server or database. In fact, in most cases, we did this manually. We’d deploy some change or patch, then see if we could connect to the server. Sometimes a person would connect with an application, but not much more than logging in. Since many apps were fairly simple client-server applications, this was usually sufficient, but there were times we had problems with not all changes being deployed. A few times we didn’t realize this for days.

    If you deploy changes, there should be some small things that you check as an method of validating that your systems are working correctly. There may be initial checks that machines are actually running. If those checks fail, there’s no point in going further. However, if the basic connections work, perhaps you should have a few critical functions that can be called and ensure that basic functionality of the application is there. Or that your new changes actually are deployed. If you have complex, interconnected systems, maybe you want a few smoke tests that you can automate and quickly ensure everything is running as expected and communicating.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.0MB) podcast or subscribe to the feed at iTunes and Mevio

  • Designing for the Public

    I’m a bit believer that better data, and better software can help our governments around the world operate more efficiently, and better work for our citizens. I appreciate what Tim O’Reilly has said where he notes that we want governments to “specify less and do more.” Whatever your political leanings, I think that most of us would like to have our governments work better, whatever that might mean for us.

    I ran across a short piece on the design principles of the GDS (Government Digital Service) in the UK. The details are inside of a set of tutorials that you get when you subscribe to Safari Books Online, but I did find a short list of their basic principles. The first seven are:

    • Digital by default
    • Putting users first
    • Learning from the journey
    • Building a network of trust
    • Moving barriers aside
    • Creating an environment for technology leaders to flourish
    • Don’t do everything yourself (you can’t)

    There are more, but I think that these are overall good design principles for anyone that builds digital services. These are agile ideas, or DevOps ideas, Six Sigma ideas, the ways in which we can be better by learning and evolving as we move forward. Certainly I think governments struggle with the pace of the digital transformation of the world, and trying to solve problems in one large effort doesn’t work. We need the ability to debug, and modify our systems on a regular basis. Both in public and private sectors.

    The last item might be one you don’t think about in some private industries, but certainly the idea that you can’t provide everything for customers. Perhaps you may to include an API or integration method to let customers build on what you do, and learn from what your customers might build, including those features in your next iteration. Designing for a diverse audience is hard, and certainly requires flexibility, but also the ability to make hard decisions and focus on the things you can do well, rather than trying to meet every goal and every need.

    Hopefully we’ll see more governments doing this in the future.

    Steve Jones

    The Voice of the DBA Podcast

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

  • A Slower Job

    I noticed that my company, Red Gate Software, was looking for a support engineer in our CA office awhile back. It’s a good job, and while the salary is lower than that which experienced SQL Server professionals might make elsewhere, there are some good benefits, not the least of which are a generous vacation allowance and the chance to get a sabbatical. At first, I suggested looking at recent graduates from local colleges for candidates, as well as junior people at user groups or SQL Saturdays, but then I had another thought.

    Working as a support engineer can be an interesting job, seeing lots of different types of problems with software. It can also be less stressful since you work on lots of small issues without looming,  deadlines. With great benefits, it might be the kind of job that an older technology worker would want. Especially if this were a part time position. Experienced, semi-retired professionals might really enjoy this job. I know this is something that might intrigue me in 15 or 20 years.

    QA certainly needs more quality workers, and with the sporadic nature of the job, I could see organizations benefiting from using flexible workers that might not even want or need a full time job. Perhaps having a larger group of people available on demand, as many customer support centers use, might be a good way to take advantage of skilled workers that are looking for extra money.

    We have lots of positions in technology that require lots of experience, but aren’t necessarily full time engagements in many companies. I would expect that much like Remote DBA services, we will see more and more limited engagements in the future, either part time or contract based. Hopefully many of us will find both fulfillment and excitement throughout our careers, perhaps slowing down over time, but still being engaged and excited in technology.

    Steve Jones

    The Voice of the DBA Podcast

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

  • To Infinity and Beyond

    This isn’t data related, but a story caught my eye recently, and I suspect quite a few of you will enjoy reading it.

    One of the tasks I had to do in university was try and rewrite the landing software for the Mars Viking lander. This was in a software engineering class, and we treated the task like a project, each of us having to work on different parts and integrate them together. We had the same requirements in terms of memory and disk space, though not CPU. We ended up building a small piece of software that worked in the professor’s simulation, but the real joy was going through the process and solving the problem. It was quite a challenge.

    In the real world, quite a few people around the globe have been disappointed by the very limited space travel efforts of our species. After sending multiple missions to the moon, not much happened outside Earth orbit for decades. A few recent actions with rockets have gathered attention, and with the interest shown by SpaceX and other companies, it seems that we might be poised for more exciting opportunities in space across the next few decades.

    A company’s application to send a commercial mission to the moon has been approved by the US federal government. There are rules that require each country to authorize and supervise space activities, and it’s quite a process in the US. However Moon Express has gotten the approval and they want to send a spacecraft to the moon. And not before the end of the decade, as the US tried to do in the 60s. They’re looking to land on the moon before the end of 2017. That’s just over a year away.

    I think the idea of space travel is really cool. Well, it’s cool for others. Not for me. Until there’s artificial gravity, I’m not interested, but I know plenty of others are. Friends in technology dream of going. The DBA in Space contest from Redgate was a hit that many people wanted to win, and get the chance to ride a rocket. My son even wants to study aeronautical engineering in college, hoping to get the chance to work in space someday. Even as launching rockets gets to be commonplace, there are many people that dream of the chance to one day leave the planet.

    The explosion in aircraft innovation came when a variety of private companies began to build and fly aircraft. I suspect a similar thing will happen with space flight, especially as the technology advances in computing, 3D printing, and more have become affordable for many private concerns. I expect that the next few years will start to see space tourism become a regular, expensive but affordable option, even as a few private groups will make the first steps toward moon exploration, and someday, colonization.

    Steve Jones

    The Voice of the DBA Podcast

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