Voice of the DBA

Tag: version control

  • Communicate Through Commit

    Using Version Control is a skill, and it’s one that most technical professionals should learn. Even sysadmins and infrastructure people can benefit from version control, especially as people use infrastructure as code and GitOps with products like Terraform.

    Writing a commit message is a bit of an art, and it’s a good skill to have. I saw a post on how to write one, and I like the overall advice. Talk about why you’re making the change, not what you’re doing.

    The post has good practical advice about structuring a commit message, especially to ensure the messages are terse and easy to understand. Like much of coding, to do this well requires practice, and feedback. Ensuring your team agrees on how to do this and reviewing messages to help everyone improve will build a more cohesive team as well as reduce the amount of explicit communication you need to have.

    Our time is precious as developers, but our attention is even more precious. Every interruption from Slack, a text, or any synchronous communication could break our flow. Many of us complain about meetings taking time out of our day, but the small questions and queries from others, especially at random times, can be worse than meetings.

    Building standards, habits, and providing short documentation in common areas, like commit messages, can reduce the need for one developer to interrupt another. The more we work together as a team, by agreeing on and adopting standards, the better we work together as a team.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Build the VCS Habit

    I’ve preached the value of Version Control Systems (VCS) for many years now. In various writings, in the talks I’ve given on development, CI, DevOps, and more, I always talk about the value of a VCS. One thing I often say is that if someone won’t use version control, they aren’t a professional. I don’t say professional developer, professional DBA, or anything else. You’re not a technology professional without knowing how to use a VCS in 2020. You certainly can’t work for me if you won’t use one.

    I saw a nice, short post from Kevin Chant on the ways in which a SQL Server professional can benefit from a VCS. Many of us working with SQL Server aren’t developers, we may not be some DevOps engineer. We might be someone that manages systems or handles backups. We might be someone that deals with complex HA, DR, or replication processes. We may be report writers or ETL developers.

    In all those cases, we have scripts, and these days, the majority of us need to work with others and often share these scripts with a team. We need to update the code over time, and we need to ensure that if anyone edits the code, we know what was changed. In other words, we need versioning, and we certainly need some easy way of sharing things.

    There are lots of choices, but there’s no downside to using a VCS and lots of upside. Changes are you have some VCS in your organization and adding another repo (database) of code is easy. I recommend git, but really, I think Subversion, TFS, Perforce, VCS, Vault, Mercurial, etc. are all fine. Even Visual Sourcesafe (VSS) works, though I’d say you could do better at a lower cost these days.

    Outside of becoming better at SQL coding, I think learning to use a VCS and becoming comfortable with it is a core skill for a tech professional. You can get git for free, and it’s easy to learn. I’ve written some basics on my blog and SQLServerCentral. There are plenty of tutorials out there (I like Atlassian), and you can even practice skills online. Do yourself a favor and become a better professional today. Start using a VCS for all your scripts and code.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Building Helpful Commit Messages

    Using a VCS (Version Control System) is important in any modern software development environment. I still can’t believe that both application and database developers are using a VCS at less than the 95% level, but surveys constantly show this. I’m not sure if this is because of laziness, ignorance, stubbornness, or something else, but it’s a bad idea. Start using a VCS. Talk to your management, and let them know Git is free and can be run on premises, much like a file share for code, except it’s better.  Even if you hand craft scripts (or use the SSMS GUI), just start saving those scripts in a VCS.

    There are lots of tutorials and examples of how to use git (or any VCS), and this is a skill you want to build over time. To start, just learn to build a habit of committing code to the repo as you make changes. This is fairly easy, but there is one skill you need to develop over time: how to write a good commit message.

    When we commit code, we usually need to enter some comment. This is a bit of an art, and should be designed to quickly convey information to the next developer (who may be your own future self). While people may have their own view on what to include, my thought if usually to include the “why” of the commit. This helps me to go back later and understand what I was thinking. I don’t need “what” was changed, because a quick diff of the file will explain that. If possible, I like to relate a commit to a specific request, like a Work Item, a help ticket, or some place that describes the requirements in more detail.

    I ran across a nice post that describes the art of the commit, and I think there are some good ideas here. Certainly being brief and understanding that often your message is a headline is good advice. The most important parts of the post, for me, are the need to understand that I’m working with others, and it’s important that my message help them and vice versa.

    Learning to use a VCS is a critical skill for anyone working in the technology field. We know most application developers need this, and slowly I find more database developers doing the same. However, as we move to GitOps and Configuration and Code, as compliance becomes more impactful with more auditing requirements, as we try to do more with less, the infrastructure staff and others need to learn how to capture their changes in a VCS as well.

    Do yourself a favor and start learning how to use a VCS. Git makes it easy or you can play with Azure DevOps in the cloud. Just start saving some files and building skills. Your career will thank you. Learn to write good commit messages and your team will appreciate you.

    Steve Jones

     

  • Great Developers Use Source Control

    I was rewatching Ike Ellis (b|t) talk on the habits of Great SQL Developers from SQL in the City 2018, and his first item was “Use Source Control“. I happen to agree with Ike, which is why I’m writing this, and I really hope you do as well. Certainly at Redgate we’ve built tools that help you get your T-SQL code into a VCS, but whether you want to work manually, use someone else’s tool, use our SQL Source Control or ReadyRoll, I’d ask that you consider getting all your code into some sort of VCS (Version Control System).

    Ike notes that if viewers did this one thing, he’d be thrilled. I agree. Please, learn to use version control. If you wonder why, listen to Ike’s talk. He relates a story that notes that using source control doesn’t make you a better developer, but that better developers do use a VCS. This is a habit that helps build better habits and is a step on the journey to you becoming a great developer.

    Does it help? Well, I think it does in some sense. Developers that use a VCS often build a habit of checking in changes before they try something that might be problematic. They also in a more integrated fashion with their work, and easily rollback problematic code without wasting time (or focus) trying to undo something. They get a previous version back and move forward.

    I do think that this one thing changes the way you view code, and it provides you with a safety net. This is one of those skills that I’d really recommend you learning, as it will pay back it’s value tremendously over time as you learn to depend on the VCS and stop doing things like keeping multiple objects or files around, and trying to sort out what code is where. As you work with others, or even with your past self, you’ll learn to include better comments that help you change focus quickly and understand the particular reason behind a version of code. This will help you learn to be a better developer.

    There are numerous ways to get your T-SQL code into a VCS. There are tools, but there are plenty of PoSh or other scripting methods. In fact, every DBA should get in the habit of scripting out instance level objects (which most tools don’t handle). Store them away, and then repeat as you need to make changes. You might be surprised how often you’ll be glad you have the previous version of a job, a schedule, a linked server, or more. I learned to keep all my scripts, from replication to running a quick report for a business user, in a VCS. I’ve never regretted this choice.

    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.