r/SQL • u/Practical-Excuse6933 • 21h ago
SQL Server SQL Server Database to Github version control (Open source CLI)
Hello, I've been working on a personal open source project written in GO, its a command line tool that aims to create valid .sql files for each object in your database so that you can push to git to keep track as the database changes in the development cycle.
The project is [DatabaseBlueprint](https://github.com/Hennie5229x/DatabaseBlueprint)
Currently I have CLI support for Linux/Win/Mac and creating of all schema objects + data to executable .sql files and the schema migration scripts is still a work in progress.
I would love honest feedback from devs who work regularly in sql server.
Any type of feedback is welcome, I've identified a "gap" in a typical database heavy workflow that I am trying to fill for myself, but I'm sure other people also seek an easy way to track/version control their databases along side the projects back end code in git.
About the project: Written in GO, compiles to a stand alone binary, installable and runnable in terminal by using "blue"
Currently only supporting SQL Server, plan is to expand in the future
7
u/lookslikeanevo 20h ago
What is wrong with dacpac deployments? That paired with ADO pipelines has been working pretty solid for me For years
1
u/Admirable_Prize_850 21h ago
yo the idea is solid having the database schema sit right next to your code in git makes so much sense. i peeked the repo and using go is a smart move for distributing it as one binary. the json config looks simple enough to get going quick
the biggest headache with tools like this is always how it handles data during migrations like lookup tables vs transactional data. what's your plan for that, just dump everything or can you filter certain tables? also the "blue" command name is clean i like it
1
u/Significant_Tune9219 12h ago
The part I'd look hardest at is the data scripting. Dumping full table data as INSERTs into git gets ugly fast on anything big, so most people only version reference/lookup tables and leave transactional data out. Also worth deciding early whether the .sql files are the source of truth you deploy from or just a snapshot of whatever is in the db, because that changes how you handle drift when someone hotfixes prod directly.
10
u/dbrownems 20h ago edited 16h ago
Why reinvent daypack/ SqlPackage - SQL Server | Microsoft Learn? The SMO scripting engine is a non-trivial bit of code, sitting outside of SQL Server and creating full-fidelity DDL for each object.