An Introduction to GitHub for DBAs - Brent Ozar

Monitor your servers for free with Quest Spotlight Cloud.
24/7 operational monitoring
for up to 5 SQL Servers.
Mobile dashboard for
iOS and Android, too.
Totally free! BrentOzar.com/go/spotlight

Save the Date!
2019
June 9-14
We’re back in Orlando!
www.SQLintersection.com
Leave the every day behind and enter a world of wonder and enchantment at the Walt Disney World® Resort.
Located in the heart of the most magical place on earth, the Walt Disney World Swan and Dolphin Resort
provides a truly extraordinary backdrop for our event! Beautiful tropical landscaping, tranquil waterways,
and classic art and architecture work together to create a stunning landmark!

SQLintersection
Session: Wednesday, 9:45am-11:00am
An Introduction to GitHub (for DBAs)
BrentOzar.com/go/githubfordbas

© SQLintersection. All rights reserved.
http://www.SQLintersection.com
2010-current: consulting DBA
08-10: MCM, Quest Software
05-08: DBA, VM, SAN admin
99-05: dev, architect, DBA
Still today: source control n00b
www.BrentOzar.com
Help@BrentOzar.com

Distributed source control is really intimidating: branches, pull requests,
merges - will somebody just take my code, for crying out loud? Why does it
have to be so complicated and involved?
I'm with you: I'm Brent Ozar, and I hated GitHub. For years, I struggled with it,
but I've come to a gradual truce. I'm not a GitHub pro by any means, but in
the span of one session, I can explain the most important terms to you in a
way that'll make sense for non-developers. I'll show you how to contribute to
someone else's open source project, and how to get started putting your own
scripts under source control.

What we’re gonna do
Understand where distributed source control comes from, and its language
Open an issue with something we want to fix in sp_Blitz
Contribute that change, and see how the management looks
Contribute an improvement to someone else’s repo
Keep it simple: use the official GitHub client and a text editor

What we’re NOT gonna do
Debate the differences between Git, GitHub, GitLab, etc.
Move projects from TFS to GitHub
Create GitHub.com accounts and walk through installing the Github tools
Debate the merits of different client tools (I’ll use the official one)
Type things at the command line
Build continuous integration or continuous deployment
Keep your SQL Server in sync with source control
End the war between tabs and spaces
Solve a merge conflict

When I was your age…

Times changed. Developers faced new problems.
Open source happened:
people wanted to collaborate on the same files at the same time.
The Internet happened:
collaborators were spread globally, and not employees of a company.
Linux happened:
people wanted to collaborate on BIG files, and a lot of them,
and they wanted to work on big changes over time.
13

Distributed version control became popular.
 2005: Linus Torvalds creates Git to solve those problems.
 2008: GitHub.com launched as a hosting company to run Git for you
(and make their own improvements.)
 2010s: GitHub became the dominant source-control-as-a-service.
 2012: we put sp_Blitz & FRK in there (because they’re code, not data.)
 2018: Microsoft acquired GitHub for $7.5B.

GitHub is designed for code, not databases.
 It’s designed for collaboration across company lines, not single users.
 It’s designed by developers, for developers
(and initially on Linux first, so cross-platform support is great.)
 It’s great for units of code that can be entirely overwritten.
(Great example: a stored procedure.)
 Because it’s a developer tool, IDEs
(VS, VS Code, text editors) integrate it.

Let’s contribute a change to sp_BlitzLock.

The thing I wanna fix

Here’s the spot in the code

Where the code lives: FirstResponderKit.org

Terms
 GitHub account: owned by a person or organization
 Repository: an application’s source code, owned by an account
 Branch: a version of a repository
 Master branch: always ready for customer deployments
 Dev branch: the next candidate for master, but maybe not ready yet
 Issue branches: kinda like opening the dev branch and clicking File, Save As, and having a
separate space to work without bothering other developers
 Commit: backing up your local code up to your branch (GitHub, cloud)
 Pull request: asking the dev maintainer to “pull” your code into a branch
 Issue: bug or feature request. Discussion is normal here.

23
Changes have happened
in this branch lately.
I need to pull them down
to my local computer.
I haven’t made
any changes.

Wanna make a change? Make a branch.
 Master branch: always ready for deployments.
 Development branch: the next candidate to become master.
 Where we’ll work:
 Create an issue describing what we wanna do
 Create a branch with a name that points to that issue
24

It’s a lot of work, but it pays off for team projects.
Check out the “Blame” and “History” buttons…
27

“Blame”

Working in someone else’s repo…

Terms
 Fork: a copy of a repository, copied into your own account
 If you want to work on someone else’s repository, you either have to:
 Get them to give you permissions in their repo (very unlikely), or
 Fork their repository into your own account, and work on it in your account

Forks can be controversial.
 1995: MySQL AB, private company
 2008: Sun Microsystems bought MySQL AB
(but MySQL was still open source)
 2009: a MySQL founder forked (save-as) the MySQL open source code
and started a “new” database called MariaDB
 2010: Oracle bought Sun (and inherited MySQL - but still open source)
 2012: MariaDB Foundation started, keeping MariaDB open source

But forks keep open source projects safe.
 Anyone can fork a repo at any time, without permission
 If the original maintainer does something stupid, you still have the code
 (Although that by itself doesn’t grant you legal rights to do stuff)

Understand the license you’re working with
 Most repos have a license.md file in their repo with the exact license
 First Responder Kit, DBAtools, Ola Hallengren: MIT License, open source
 VS Code, Azure Data Studio: source code is MIT, but the binaries aren’t

Back to our simple example
 The sqlcollaborative owns the dbatools repository, and I don’t want
to ask for permissions from that team
 I need to fork the dbatools repository to my own account

What I should really do:
 For the dbatools repository to my own account
 Make a branch for the work I want to do
(even in my own account – because when I love a project, I may end
up making several contributions, and they may not all get accepted
at the same time)
 Do my work locally, then commit it (to my branch)
 Send a pull request to the sqlcollaborative

That probably doesn’t seem elegant.
 “Why do I have to clone somebody else’s repo to my own account?”
 “Can’t I just ask for permissions in their repo, and edit it live?”
 “What’s the benefit of all this complexity?”
It wasn’t designed for tiny projects.
It was designed for big ones like…

There have been 9,437 changes
to SQL Server Books Online
since my client updated.

Lessons I learned the hard way

What’s still hard
 Source control for binary files (Excel, PowerBI, Word files)
 Conflict resolution (I’ve been known to nuke my files and start over, or
copy/paste them out into other folders and discard my changes)
 Source control for databases:
 Schema (table structure, indexes)
 Data (configuration rows)
 Machine configuration (trace flags, server settings)
 Integration between Github and SQL Server tools: SSMS, ADS
 Red Gate SQL Source Control: ~$500 per user, integrates with SSMS
 Microsoft Azure Data Studio: new query-writing tool, based on VS Code

Developers are ahead of us.
Development tools & text editors have more GitHub integration.
Because of that, when doing work on code saved in GitHub,
I’m more likely to use developer tools that make source control easier.
For example, my favorite Mac text editor (TextMate) automatically shows
when I’m editing a file in a GitHub repo, plus what branch I’m in:

Learn Markdown.
Like Word, but with plain text
Useful in Github, Stack Overflow, and
just general note-taking apps
Cheat sheets:
MarkdownGuide.org
MarkdownTutorial.org

Be polite, upbeat, and thankful.
 Read a project’s contributing guide before jumping in.
 Maintainers are often doing this as a hobby or a labor of love.
 Take time and really test things before you ask a question or try to
contribute code: the maintainer is usually a volunteer.
 They’re doing you a favor by sharing their work. Be thankful.

Filing a bug, issue, or feature request
 Open source doesn’t mean free contractors.
 If you’re passionate enough to help out with code,
read the project’s contributing guide,
and then open an issue talking about what you’d like to contribute.
 Other people will discuss the thing you want to add – sometimes it’s
not a good fit for the project, or they have input that may change the
way you want to write the code.

Branching guidelines
 Never work in the master or dev branches directly.
 Create new branches off the dev branch.
 Name your branch with the issue number you’re working on.
 Commit often. It’s like taking a backup.
(However, maintainers may ask you to “squash” your commits.)

Don’t learn from Microsoft repos.
Microsoft has invested a TON in their repos like:
 Making it easier to contribute to Books Online pages
 Automating code review notifications and license acceptance
But no other repos offer that level of tooling.
Don’t think that the way Microsoft repos work
is the way all other repos work. It’s not even close.

Recap, next steps, and your career

The most important terms
 Fork: copying someone else’s repo into your account (and it’s fine!)
 Branch: a version of a repository
 Master branch: always ready for customer deployments
 Dev branch: the next candidate for master, but maybe not ready yet
 Issue branches: kinda like opening the dev branch and clicking File, Save As, and having a
separate space to work without bothering other developers
 Commit: backing up your local code up to your branch (GitHub, cloud)
 Pull request: asking the dev maintainer to “pull” your code into a branch

Next steps: BrentOzar.com/go/githubfordbas
 Official resources:
 GitHub’s training videos: https://www.youtube.com/githubguides
 Lab exercises: https://lab.github.com/githubtraining/introduction-to-github
 The documentation, kinda like Books Online: https://help.github.com/
 Really big picture: jobs, maintainers, conduct: https://opensource.guide/
 Popular repos:
 First Responder Kit: http://FirstResponderKit.org
 DBAtools (PowerShell): https://dbatools.io/
 Microsoft SQL Server docs: https://github.com/MicrosoftDocs/sql-docs
 Finding more cool stuff: Hacker News: https://news.ycombinator.com/

Your Github profile
is a verified resume.
53

An Introduction to GitHub for DBAs - Brent Ozar

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie An Introduction to GitHub for DBAs - Brent Ozar

Ähnlich wie An Introduction to GitHub for DBAs - Brent Ozar (20)

Mehr von Brent Ozar

Mehr von Brent Ozar (13)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

An Introduction to GitHub for DBAs - Brent Ozar