Voice of the DBA

Tag: DevOps

  • DevOps is Mostly About People

    I was giving a talk on DevOps recently and one of the questions from a person in the audience was how to get others to buy in. This person also had complaints that “DevOps” wouldn’t work because their boss wasn’t interested.

    I think these are great examples of things that many developers and managers don’t think about when they look to embrace DevOps. While there is no shortage of technical articles and videos on how to introduce automation or deliver features in a new way, what gets lost is the need for cultural change.

    DevOps is all about people. It’s about learning to trust each other and work together. It’s about adapting and changing how you write or deploy code to make the process smoother. It’s about sharing your knowledge with others and learning from them. It’s about being blameless and also accountable. It’s about support from management to improve the software and the process.

    It’s about people.

    The automation is cool and it’s a lot of what is easy to demo and explain. I show that because I don’t know the people involved in your environment and I can’t explain how you can get them to change how they work. Instead, we tend to focus on the tangible things that an individual can learn: the technology. Use version control, validate and test with CI, deploy consistently with release servers, and build packages that are versioned and reviewed. Those are the easy parts.

    The culture is what really matters, both in development teams, in conjunction with ops teams, and with support for management. There is no magic to software development and DevOps doesn’t bring any. All it helps you understand is that you need to be a team to build great software.

    Steve Jones

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

  • GitHub vs. Azure DevOps

    I work often with Azure DevOps. I have enjoyed the platform and it does what I need. I also work regularly with GitHub and GitHub Actions. Those rebuild SQL Saturday and SQL Memorial when I need to make changes. It also works very well.

    This week I saw a post on choosing between Azure DevOps and GitHub, which is something I get asked at times. The post goes into some of the differences and provides a lot of links that you can use to read about features. There also are plenty of links on using the two products together, which is something I see regularly. Code in GitHub and the build/test/release in Azure DevOps.

    On the question of which one, the author doesn’t give a recommendation, but rather some questions on things you might think about. The author asks about the features you use or think you will need and using that information to help guide your decision. I think that’s fair, but here’s what I’d say.

    If you have no automated version control or build/test/release tool in your organization, then choose Azure DevOps. It has a lot built in that I like and it’s simple to use. I think it’s visually pleasing and I think it is easier to teach people how to use it for this reason. GitHub is fine, but I find it slightly more confusing to move around in, though to be clear, I spend more time in Azure DevOps, so I’m likely biased.

    I’ll also separate out version control. I assume your organization has someone using version control. Whatever system they use is the one to adopt. There’s no reason to argue or get them to change. Most people use Git and all Git host services are essentially the same. We could argue some small thing you want, but really Git is Git. Use what others use.

    I would say the same thing for build, test, and release. Use what software developers use. These systems are all good, and they all have pros and cons. They all do some things well and have some disadvantages, but they are really interchangeable. I wouldn’t move build systems or release systems without a really good set of reasons to do so. Just because the new lead or CTO likes another system or has experience there isn’t a good reason. If you don’t have any system in your organization, then see my recommendation above.

    Modern software development needs a team, and for teams to work well and efficiently, you need version control and an automated build/release system. Use what others use, or have some people conduct a few pilots and then take vote and go with the results. Really, all these systems are similar enough that it’s not worth more than a few minutes of discussion.

    Steve Jones

  • Adopting a DevOps Process for your Database – SQL Saturday New Jersey 2022

    I had a great talk today at SQL Saturday New Jersey 2022 on DevOps and databases. Good crowd and good questions.

    Got caught in a spotlight picture as well:

    FYXKqXBWQAE82F_

    The slides are available for download.

  • Accounting for Typos

    When I watched Star Trek as a kid, I was amazed by the technology. Talking to the computer, the touch screens, the handheld communicators. We have most of those devices now, without the space travel. Hopefully that will start to change with all the efforts being made by various organizations.

    One of the things that always bothered me was the chance for mistakes. A mis-spoken (or mis-heard) command to a computer that didn’t verify things as a human might. The chance to hit the wrong part of the screen as the starship moved. It seemed as though soft buttons would have allowed more mistakes than hard ones. Certainly humans make mistakes with physical switches, but I think I make more mistakes trying to hit a part of the screen in my Tesla than using one of the (few) buttons or wheels to change something. Interestingly enough, my 23 year old decided on a slightly older car because it had more physical buttons and fewer soft ones.

    We are human. Frail and faulty. We make mistakes. Some are small (I ran a SELECT query on the wrong database), some are bigger. A mistaken copy paste error sent US$36 million away. That is the type of mistake that could happen to any of us, though hopefully not at this scale of financial loss.

    This type of mistake is a main reason why I think DevOps and automated flows for development, testing, and even for production updates are a good idea. This doesn’t prevent human error, but it does serve to limit it and reduce silly mistakes. Often these types of errors are caught when we force someone to work through a bit of a process. An easy and quick process, but still a process.

    In the case in the article, you would hope that someone looking to make changes would write an update that can be tested in a second environment before applying to the production blockchain. Perhaps with some idempotent wrapper and a pre-check that verifies the target. That might seem like overkill, but it’s the type of care that most of us take when we know we aren’t going to be the one executing the code. If you submitted a script to a DevOps process, you’d want to be sure the process running your code made the proper decision of whether to run the code or stop because of some error.

    We won’t prevent all errors, but a lot of automation and light DevOps process is designed to limit simple, silly human errors because we are tired, distracted, or otherwise unfocused. I am a proponent of having humans design systems and processes, but then letting the computer handle the drudgery of following the process over and over on a regular basis.

    Steve Jones

     

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