|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Make a meal using a recipe or ingredient you’ve not tried before I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
Delivering Patches Quickly I love cars. In my life, I've owned and regularly driven well over 20 cars. If I count the ones I purchased for my kids and lightly drove, it's over 30. Just writing this paragraph gets me a little itchy about looking for another car. Actually, I'm looking lightly now, as I expect two kids to move on next year and handle their own expenses. So, next year I'm hoping to add another vehicle. Recently I saw a note that there was an exploit against Tesla cars, which are rarely stolen, but there have been a few issues. This one was against the fobs that communicate with the car. Tesla is working on a patch, which is interesting. They've not only devised their cars, but also their fobs, to get firmware updates. Good, and bad, as this increases attack surface area. Tesla can patch their cars in real time, and they do this fairly quickly. I have a 2012 BMW, and I have updated the firmware in it, but patches are rare, and most of them seem to be stuck in the "visit a dealer" paradigm. It seems many other makes of cars fall into the same paradigm, and aren't built for regular updates. In some sense, this reminds me of the way many people deal with the their SQL Server databases. We put code out there, in tables, functions, procs, etc., and often we struggle to update that code quickly. This becomes especially true with applications that use our objects. I often find that changes seem to come slower and slower over time, much like the traditional way that your car is updated by a dealer only. Ideally, we'd be able to more quickly update code when there are issues. This is especially true if you have procs or other code that could potentially have security issues. DevOps asks us to move towards this type of flow, making changes, and adjusting quickly. There are certainly still challenges with changing code and adapting applications, but if front end developers and database developers worth together, we can deploy code quicker. Our customers don't care about our challenges we face with writing and deploying code. What they want are new features, functions, better performance, and meeting their needs. DevOps helps, but it's not easy. You have to automate things, deploy code sooner AND be willing to fix your code mistakes. You not only need testing, but testing that improves over time. It is, however, worth the effort. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
