Voice of the DBA

Tag: DevOps

  • When Work Isn’t Done

    Software development can be a challenge for each of us with lots of demands and the need to ensure your code solves a problem correctly, efficiently, and completely. Juggling the workload by yourself is one thing, but add in a team of developers, and the complexity quickly grows.

    The real world is chaotic and despite the best efforts of project managers and scrum masters, our software development life cycle doesn’t always proceed smoothly. I wonder how many of you run into this situation and how you deal with it.

    Developer 1 gets a piece of work, let’s call this A. They complete this and send it to the QA team. Somewhere during this process, Developer 2 get’s a different piece of work (B) and writes code. They send this to QA before A is completely tested.

    Now, Developer 1 finds a mistake. Something doesn’t work or they realize their solution is incomplete. QA is A + B, but A doesn’t work and needs revision. B passes testing and needs to be deployed. If your codebase and QA have both A and B in them, how do you strip out A or B and ensure B is deployed to production but A isn’t?

    If this is C# or Java, you might have one solution, even if both changes are in the same class. If this is database code, you might have a different set of issues to deal with.

    Really, the question is can you reorder work in your deployment process? I find many customers don’t consider this when they are evaluating their software pipeline. They somehow assume if code gets to QA that it’s good, which is nicely optimistic but not realistic. At some point, we’ll deploy code to QA that doesn’t work. The more developers we have, the more likely this is, and the more demands on our time, the more likely we need to reorder work and release one thing but not another.

    As a DB developer and DBA in a company 20 years ago, I built a process and forced us to reset the QA environment and redeploy B only (using a branch of code that stripped out A) for re-testing. This ensured that we tested what was going to be deployed. However, I find a lot of organizations can’t do this or don’t want to. They want to hope that a human and either extract all of B or strip out all of A and release partially tested code without issues.

    I find that to be a poor idea. In this era of regular staff changes, staff of varying quality, and the high complexity of software, this is asking for mistakes. With cheap hardware, virtualization, and the ability to provision copies of environments, we ought to do better.

    How do you handle this today? Depend on humans to not make mistakes? Hope for the best? Or follow a repeatable, reliable process that accounts for inexperience and human error?

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • Deleting a Git Branch–#SQLNewBlogger

    I had someone ask me recently about deleting branches. While I had known how to delete a local branch, I had to look up how to delete a remote one. Documenting these both will hopefully help me remember this.

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    Deleting Branches

    Most parameters have something do to with the action, and most people might guess a –d is used to delete a branch in Git. The actual syntax for a branch named “Feature123” is:

    git branch –d Feature123

    You can also use a –D, though be aware that –D is the same as –d with the –force option. The –d actually aliases to –delete, so you have three options:

    • -d
    • –delete
    • -D (this will run –-force)

    To delete a remote branch, you can use (with v1.7+)

    git push origin –-delete Feature123

    where origin is the remote name and Feature123 is the branch. This is better than the old syntax, and you ought to keep your git up to date.

    You can see this working for one of my branches below:

    2023-10-11 13_20_00-cmd

    Git docs for branch have more details.

    Use this to clean up branches if your changes are merged and you don’t need to send in any more PRs for this branch.

    SQL New Blogger

    This is a simple thing, but one that I don’t do often, so I wrote this as much to document it for myself as to put this out there as a piece of knowledge. If someone reads this post and asks the question in an interview, it’s likely an easy one for me to give.

    You can do this, help showcase your career knowledge and control the interview. This piece took me about 8 minutes to write. You could do your own version of this topic.

  • Bad Culture Bad Security

    I ran across a blog noting that Cisco has a vulnerability in a new product. The blog also lists two (one, two) articles showing that Cisco has had hard-coded credentials in the past. I understand that many times a known process is repeated, essentially copy-pasted between people, and we have similar issues as we have had in the past. However, in 2022 or 2023, it’s unacceptable to hard-code credentials in digital systems that will be used in today’s world.

    What’s worse than having this issue is stating that the fix is “an upgrade”. Their verbiage for those without a service contract is: “Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.” Which, to me, is not only bad for the world, but it’s equivalent to the stuff that bulls leave behind in the fields.

    I suspect that this product and software were based on something that already exists, and it was rushed out without a good security evaluation. Or perhaps there are developers and managers who don’t think that hard-coding credentials will compromise security.

    That’s a cultural problem. Either you’re going too fast, or you don’t take this seriously, either way, you don’t have a good culture that values quality and protection. Certainly, their disclaimer about needing valid contracts or proving you have a device to get a security patch for a flaw they built is also a sign of a poor culture that doesn’t really understand the problems they are creating, nor are they taking responsibility for the issues.

    At the very least, fixing their poor security ought to be free and easy. I get that there are likely some software upgrades included in this patch, given the nature of software development and limited branches under support. However, there are other ways to ensure those features aren’t enabled for customers who shouldn’t have them. Making the entire world of computer network infrastructure less secure because you want customers to pay for your mistakes isn’t a model I’d want to adapt.

    I know many people don’t want more regulation or guidelines from governments (or even from insurance), but if I were going to accept some universal restriction, this would be the place. If you use hard-coded passwords, your product can’t be sold and no insurance claims apply if you are sued.

    Maybe that would change the way Cisco and others build software.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • SQL Saturday Boston 2023 Slide Decks

    Thanks to everyone who came to my sessions at SQL Saturday Boston 2023. I’ve added the decks to the schedule, so you can click my session and will see the download there. You can see this below, and all speakers can edit their sessions and upload the deck. See the download below:

    2023-10-14 13_43_08-SQL Saturday Boston 2023 (#1046)

    I’ve also copied the links here for slides:

    For the first session, Architecting Zero Downtime Database Deployments, there is also a GitHub repo here. Clone the repo down (or fork) and you can follow the sessions along. The repo is at: https://github.com/way0utwest/ZeroDowntime

    In here, there are a few folders, as shown here:

    2023-10-14 13_45_44-way0utwest_ZeroDowntime_ Code for my zero downtime presentation

    The two items from the session are the DBClient, which is a Visual Studio 2019 project, and the SQL folder, which has all the setup (and teardown code). Each script is numbered, and you can run them in order. There are also some comments in each for when to flip feature flags.

    If you find issues, please submit an issue in the repo.