Voice of the DBA

Tag: DevOps

  • All Day DevOps–A Free, Virtual Conference

    All Day DevOps is coming on Oct 24. This is a 24 hour event, with 100 sessions live, online. You can register now and join in the event, watching from work, home, or even the train on your commute.

    The schedule is packed, with speakers from all over the world covering a variety of software development topics from a DevOps perspective. You can learn:

    • CI/CD
    • Security
    • Databases (me)
    • Serverless
    • and more

    Most of the speakers deliver these talks at other events, and if you’d like to get away and talk DevOps in person, join me in Orlando in November for DevOps East.

    Register today and join me for this online event on using DevOps to build better software, faster.

  • How Mature are you in Database DevOps?

    I remember seeing the Carnegie Mellon Software Capability  Maturity Model (CMM) when I was in university. It was fascinating, and I was sure this was the way to write software. Across many jobs and many years, I realized that few organizations even try to become more efficient and capable in how they write software.

    That’s changed a bit in the last 4-5 years as more organizations try to move to DevOps and become better at building software. Some do well, some just want to build software faster and not change the way they work.

    In any case, Redgate has built a maturity model for Database DevOps. You can take the assessment now in a few areas and get an idea how you stack up against other companies.

    Benchmark Your Database DevOps maturity level today

  • I Will Write Bad Code

    I’ll write bad code. I know it will happen. I’ll produce a bad query, incorrect logic, or the wrong data transformation being returned.

    This won’t be a malicious act. It might be because of ignorance, or perhaps just a simple mistake. My code might be the result of short-sightedness or not accounting for a potential situation. I might even misinterpret poorly written specifications and place the blame on others. Maybe I’ll misread the code and won’t realize there’s a problem.

    And, for sure, this code will get deployed to production.

    At some point I know this will happen, to me or someone else. And for whatever reason, I need to account for that fact in my software development process. I can’t prevent mistakes, as decades of software development have proven. Despite my best efforts, code reviews, the tests implemented in QA and elsewhere, bad code is going to get deployed.

    The important thing in any software development project is how you handle the mistakes. How do you move forward, and certainly, how do you apply a patch? Can you do it quick enough to minimize the impact to clients? Or must they deal with the issues, developing the workaround or missing functionality for a significant portion of time? Or will they consider abandoning your software for some other vendor?

    One of the reasons I continue to advocate for a DevOps approach is that a known process can enable you to fix your mistakes in a timely manner. With a consistent approach to writing, testing, and deploying software, you can apply a patch when it is needed. Certainly the code needs to be logically fixed, but a reliable process will help ease all the overhead of getting your code to a production system.

    DevOps can be implemented many ways, and if applied in name only, things won’t improve. We can’t say we’re using DevOps, or we’re coding faster, or we release every week. We need to really implement the three ways. However, if you approach your project and staff with the idea that although things are flawed, they can be improved and made better, you’ll find that you can deliver those fixes for clients in an extremely timely manner with a minimum of risk.

    DevOps allows us to move faster, but that’s not the goal. The goal is that we improve things and have confidence that we can release when we want to, in a repeatable, reliable, less risky fashion.

    Steve Jones

    The Voice of the DBA Podcast

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

  • DevOps Basics–Git Clients

    This is also a part of a basic series on git and how to use it.

    There are lots of git clients. If you look at the top list for this year, you’ll see quite a few. I’ve used a couple of these, but they all give you roughly the same information. Where am I in the commit tree, and what branches are out there. I tend to prefer the command line most times, but clients are handy to have.

    There are two main ones that I have been using, trading off and on between them, so a quick look at both Sourcetree and Gitkrakken.

    Sourcetree

    Sourcetree is a free client from Atlassian. They’re a software company, much like Redgate, that gives back to the community. One of the ways they do this is with Sourcetree and Bitbucket . This client is available for Windows and MacOS, so it’s cross platform.

    It’s simple and easy to setup, and the install isn’t worth covering. Amazing how simple most installs are these days. Once installed, you can open or create repositories easily.

    The interface is clean and easy to understand. All the main features (push, pull, commit, branch, etc.) are large buttons at the top. The graph, comments, and other information is in the middle.

    2017-08-25 11_36_24-SourceTree_1.9

    Below here are the staged and unstaged files in my repo, so I can easily see the state of my work.

    There are tabs for each repo, so if you open multiple ones, you’ll see them listed at the top and can easily switch between them. Handy if you need to work on multiple projects.

    Sourcetree will check for updates and let you know when they are available. As with most software, this will download the patch and then let you know that you need to close the app to start the install.

    2017-08-25 11_33_48-Found Updates for SourceTree

    After using other clients, I find this sometimes a bit slow, but usually commit/push time isn’t a large factor in work. I can start the process and go get coffee or take some break.

    I’d say Sourcetree is a nice client, and it’s easy to use. There’s also a nice button to pop open a Git Bash terminal, which is helpful if you want to work in a text format.

    Gitkraken

    I stumbled on this client somewhere. I think someone recommended it on Twitter, and I decided to give it a try. Sourcetree was working, but I was curious if there was something else.

    Gitkraken bills itself as the most popular client. It might be, but even if it’s not, I like some of the simplicity. This client is available for Windows, MacOS, and Linux, so you might prefer this if you move across all those platforms.

    It’s also cool to look at. The animation when it starts is neat.

    Others

    There are other clients, including some MS tools in Visual Studio (regular and code) that work with git. I don’t really use those, as I tend to work with the command line or simple interfaces for commits, not examining differences or looking at branches. For those tasks, I do like these two clients.

    Of course, at some point you may need to drop into the command line if you find yourself in a pickle. While I’m sure you’ll google most issues, be comfortable solving them in the command line and practice a few tasks periodically by typing the syntax.