This month’s invitation is from Mala Mahadevan, who has hosted 5 times. This latest one is one that is near and dear to my heart as I use source control most days and I think it’s important for database code.
I’ll explain why below, but I’m glad to see this as a topic. We have a wide variety of technical topics being proposed, but not a lot about software engineering as a discipline, which is part of what version control is. Not building features, but better managing your process.
If you want to host a T-SQL Tuesday, ping me.
Capturing Database Code
There are many ways to capture code, but I work for Redgate Software, so I use Flyway. Since I work there, I get a paid version, but I work with customers all the time and see a variety of things. If I didn’t have Redgate tools, I’d likely use something like SQL Compare to capture off database code, since that’s easy. Or SMO through SSMS.
As for how I work with code, I use Git to store the code. Git is ubiquitous and I rarely find customers without Git. Sometimes the data teams aren’t using it or don’t know how, but that’s why I’ve written some Git articles on getting started.
I also try to work in branches, with a protected main branch. This means no one can commit code to main, but rather need to commit it elsewhere and use a PR (pull request) to move the code into main. I do this with a lot of customers, helping them understand how to use version control to manage their code.
For my git work, I primarily work in GitHub in public repos. I’m at https://github.com/way0utwest, where I keep a lot of sample projects for things I work on with customers to demonstrate how to use Redgate tools, or just manage code better.
There are lots of ways to capture code, format it, and deploy it. However, you should use git and learn to manage your code within a team. I’d also suggest you use Flyway to deploy the code. There is an OSS version, and because it supports many platforms, if your company adopts PostgreSQL or DataBricks, you can still use a similar process to deploy code. Learn it and use it.
But first, get code into a Git repo.
Voice of the DBA 
We have our own method. A bit long to go into here.
As for a Git Repo… nope. No way.
LikeLike
I think saying no way to Git is short sighted and perhaps not thinking well about how teams work and manage software in the modern world.
LikeLike
Why would saying no to Git be short sighted when we have something that has worked just fine for almost 2 decades? And, as I said, we have a method that works just fine, which means “for our entire team”. Would you say saying no to GI is short sighted? Perhaps people using GIT are the short sighted ones because they don’t know of our methods… which are available even if “the internet goes down”, like it has so often.
LikeLike
Sorry, caught my in a busy stretch with this one.
You saying “nope no way” means you’re not considering it. Not that it isn’t as good as what you have, but that you’re dismissing a very important and valuable software development and code management tool.
The fact that you say the Internet being down as related to Git also tells me you don’t understand Git. You don’t need the Internet for Git.
LikeLike
The part I took offense to was you saying that we don’t know how teams work. You don’t need to use GIT to know how teams work.
I could say the same of you if you think that GIT is necessary to know how teams work. It’s just not the only show in town.
LikeLike
I said you might not be thinking about teams managing code in the modern world. Which includes changing team members over time and adapting to the evolution of software engineering. Lots of people are learning/using git. That means it’s a known skill for more and more people, and taking advantage of that is a good idea.
I don’t know how you work, and maybe you have something that works as well or better. But not being open to looking at Git, or giving any reasoning why another solution is better makes me question what you do.
I see plenty of orgs that have home grown solutions and they move to more well-known, widely used systems as their creators or highly-skilled employees near retirement. Having something home-grown isn’t always good. Sometimes it is, but often having a supported, more commonly used system is better over time.
LikeLike
Pingback: T-SQL Tuesday 177 roundup: Managing database code – Curious..about data