Using Git on a shared development model
buinauskas
Posts: 10 Bronze 1
I'm in a discussion with my team about one of our databases versioning. We currently have a shared development database where all changes committed to TFS. We'd like to migrate to Git and I'm advocating to move into a dedicated development model because that's how Git is designed to work. My team wants to migrate to Git and keep shared development model and I'm against that.
What would be strong arguments not to use Git in a shared development model?
What would be strong arguments not to use Git in a shared development model?
Tagged:
Best Answers
-
Mike U Posts: 316 Gold 1SQL Source Control does not support the shared model when using Git because we agree with you - it doesn't make sense to use a shared development database with a distributed version control system. The shared model relies on having a 1:1 mapping between the shared database and a single central repository version (like in SVN or TFS).Development Lead
Redgate Software -
LeeRobinson Posts: 19 Bronze 2to create multiple test databases we would also have to create multiple program environments, link them to the databases, keep the test data updated. The overhead in time, diskspace, servers and effort would be enormous, just to make a small change in a stored procedure.
Answers
Product Manager
Redgate Software
Product Manager
Redgate Software
Product Manager
Redgate Software
Product Manager
Redgate Software
Product Manager
Redgate Software
Product Manager
Redgate Software
Product Manager
Redgate Software
Product Manager
Redgate Software
My team is now moving from TFVC to Git, because it's the defacto standard source control provider just about everywhere. We have SQL Source Control through the SQL Toolbelt. So we will be "trying" to develop database changes using Git and a Shared DB model.
I agree with @LeeRobinson that the cost (in disk space (close to 2TB of data), effort, and time) to have dedicated development SQL Server environments setup locally precludes us from diving deep into that "distributed" model for DB development.
@David Atkinson you mentioned the Flyway Desktop project. What's frustrating is that Flyway, if truly a rewrite of SQL Source Control, is now a separate cost. Selling that to my IT procurement team would be next to impossible. I love the Redgate tools, but me and my team are in the minority. So there's no path forward here to use Flyway. That means we are "stuck" using Git on SQL Source Control and developing in-house processes to make sure we don't do something stupid, or going back to TFVC for our database code.
Product Manager
Redgate Software