Kendra Little

9 July 2020

The Manager’s Guide to Git Training for Database Administrators

Teams implementing DevOps often encounter a significant obstacle: database folks are not all used to working with Version Control Systems (VCS).

It’s important to overcome this obstacle because a VCS such as Git offers significant benefits for collaboration between database administrators and developers. Git provides:

• A platform for early review of code changes by the database team, including automated options to identify which changes need review
• The ability for database team members to propose database changes based on insights gained from managing the production environment
• A centralized resource upon which to build automation to increase the quality and reliability of database changes over time

But learning Git feels overwhelming to database teams when getting started — and more senior members of database teams may feel embarrassed or worried about being a newbie in tooling which is very familiar to developers. We often see that managers aren’t sure how to scope the training, as well: how much do people need to learn, and which tools should they use? There are so many options.

Here are three tips to help you shape your training initiative.

Note: If you prefer a portable audio version of this content, check out this episode of the Dear SQL DBA podcast.

Branching and merging are essential, do not place them out of scope

One mistake happens often in cases where the database administration team is tasked with getting database code into Git, and they are not working closely with a development team who has already been using Git successfully: the database team is often scared of branching and merging.

Based on this fear, the team’s lead or manager decides that creating branches and merging them back to a shared branch is out of scope for the team. They will all commit to the same branch, as this sounds simpler and like it will be less to learn. Perhaps, they say, the team will learn branching and merging later.

This is a problem with Git, because…

Git encourages workflows that branch and merge often, even multiple times in a day

Branching in a Nutshell

Another way to say this is that working with Git is harder if you don’t have a practice of creating branches as temporary workspaces for your changes, and frequently merging your changes back into shared branches.

If you have multiple people making changes to the same branch in a repo, you’ll often run into problems where one person has committed modifications to existing files, but they can’t push their changes or pull down changes because someone else has changed the one of these files upstream in that branch in the central repo. There are ways to sort this out, but they are NOT simple — and the whole idea around not creating branches was that simplicity was valued.

It is generally simpler to include basic branching and merging into your training plan in the first place. Working in a temporary branch and merging changes in frequently from other branches is the foundation of simpler workflows with less frustration when dealing with conflicts.

Tooling: don’t fear the command line, but consider starting with a lightweight free graphic tool

I’m not always one to use command lines over graphic interfaces, but I find the Git Command Line Interface (CLI) to be very simple and easy to use. A simple cheat sheet helps people learn syntax as they are getting started.

However, there’s no reason to insist that your team use only the CLI. I personally often use a mixture of source control commands built into Redgate’s tooling, then periodically also use the Git CLI. I use the graphic source control client in VS Code when I need to handle a merge conflict.

When your team is first getting started, it makes sense for most folks to begin with the Git client in VS Code (or Azure Data Studio, which is built upon VS Code and features the same client). The interface is simple enough to not be overwhelming to new users, and the tools are also free.

Appoint a coach to ensure success

The secret to learning to use Git is simple: keep practicing, and it becomes easy. But how do you make sure your team keeps practicing?

The team needs a coach. This could be someone on the team who is learning, and who has the time and interest to be a coach. This could be someone from another team who is more experienced in Git and who would like to serve as a coach. Or this could be an internal or external consultant — possibly from a central DevOps team or Center of Excellence if you are in a larger company. Either way, the role of the coach will be to:

• Schedule sessions to get the project going over the course of a few weeks
  • For the purpose of learning source control, these could be group learning sessions where the team works in a demo environment practicing tasks using Git and helping each other work — perhaps following an online tutorial, that’s up to the coach
• Regularly check in with team members to identify pain points and help identify solutions
• Identify when resources or help from other groups would be beneficial
• Summarize the team’s experience and help share results with other teams

As a relatively small project, this can be a good experience for someone who is interested in coaching, but who has not taken on the role before.

Learning Git empowers database administrators and is well worth their time

Database teams have many responsibilities, and DBAs often don’t have a wealth of free time in their workday. Still, it is well worth the time and effort to train your DBA teams up on version control systems, then work to ensure that all database code is treated as real code, utilizing a VCS. This is the foundation not only of healthy change management practices, but also empowers future collaboration and automation.