I keep doing work at sites where none of the database code is stored in version control (source control) systems. I keep wondering why that is.
At a recent site, all the source code was in individual files just sitting in a single folder. That’s just not sensible.
I’m left wondering why it is that almost every team that I see working with higher-level languages just assumes that some form of source control would be used, yet it’s almost the opposite when I’m working with data teams.
Having decent source control makes such a difference:
- No more overwriting changes and losing them.
- No more wondering what changed between versions, or who changed them.
- And so on and so on.
There seems to have never been a culture of source control among DBAs; and database developers are somewhere in between these two worlds.
One aspect of this is tooling.
Vendors like Red-Gate do a reasonable job with their source control offerings for T-SQL but some clients want a “pure-Microsoft” solution for some reason.
In earlier versions of SQL Server Management Studio (SSMS), there was support for an SCCI (Source Code Control Interface) provider add-on. That would let you connect SQL Server script projects to source control. Sadly, that disappeared in recent versions of SSMS. I gather that there might be a way to attach the Visual Studio Team Explorer to it but I haven’t pursued that and I really hope that a standard interface will return soon. I feel that SSMS should interface directly with both TFS and Git as part of a default install. Having tools like this without source code interfaces built in, helps to push an inappropriate direction.
If however, you are using SQL Server Database Tools (SSDT) to build your databases, then both TFS and Git are standard connections from Team Explorer.
I just find that I can’t do my database development work directly in SSDT. I find very few people do that. Most use SSMS for development.
I’d love to hear others’ thoughts on why this culture has evolved this way, and how to change it.