git Best Practices?
tclimis
Posts: 5 Bronze 1
Migration scripts seem to only work if a database is only moving forward. So let me lay out a standard practice I have, and you can see where this breaks down totally and completely.
In my git repo, I have 1 folder which is linked to a dedicated database. In March, I create a branch off of the stable code base to begin a project. That project is expected to take 3 months.
In April, another developer on my team creates a branch off of the stable code base (which has now changed since I branched in March, because it has bug fixes and such in it) to fix a bug. Once the bug is fixed, I'm tasked with doing a double check to make sure it's fixed.
I check out my colleague's branch. And then do a "Get Latest" in source control. It syncs up my database with his branch. It undoes my changes, runs his migration scripts. I do my testing, and find something that's broken. I kick it back to him to fix it.
I checkout my own branch again, and Get Latest to sync my database back to the project I'm working on. It undoes his changes (sort of - it's not like it can run a reverse of the migration scripts). My migration scripts don't run, because they already ran once, so the Get Latest fails. I fix stuff in the deploy script manually and go on working.
My colleague fixes the problems with his bug, so then I checkout his branch again, Get Latest to sync-up, and now that doesn't work, because his migration scripts already ran the first time I checked the branch out.
As you can see, switching back and forth between branches is really straightforward in git. But really not straight forward in Source Control.
So is there some guidance on how we're expected to use branches? Browsing through the forum here and on user voice, it seems like we're supposed to have
You must have had some business process in mind when you designed all this stuff. What was it?
In my git repo, I have 1 folder which is linked to a dedicated database. In March, I create a branch off of the stable code base to begin a project. That project is expected to take 3 months.
In April, another developer on my team creates a branch off of the stable code base (which has now changed since I branched in March, because it has bug fixes and such in it) to fix a bug. Once the bug is fixed, I'm tasked with doing a double check to make sure it's fixed.
I check out my colleague's branch. And then do a "Get Latest" in source control. It syncs up my database with his branch. It undoes my changes, runs his migration scripts. I do my testing, and find something that's broken. I kick it back to him to fix it.
I checkout my own branch again, and Get Latest to sync my database back to the project I'm working on. It undoes his changes (sort of - it's not like it can run a reverse of the migration scripts). My migration scripts don't run, because they already ran once, so the Get Latest fails. I fix stuff in the deploy script manually and go on working.
My colleague fixes the problems with his bug, so then I checkout his branch again, Get Latest to sync-up, and now that doesn't work, because his migration scripts already ran the first time I checked the branch out.
As you can see, switching back and forth between branches is really straightforward in git. But really not straight forward in Source Control.
So is there some guidance on how we're expected to use branches? Browsing through the forum here and on user voice, it seems like we're supposed to have
- a different database folder for each branch (I'm not even sure how that would work, because then you'd end up with multiple copies of the database when you merge the branches together), or
- a copy of the database for each branch. Again that seems not really feasible - if you have 15-20 branches in progress at a time, you have to have images of each database? Where would you store them? Checking out a branch (an operation that I do 5 to 10 times per day) would mean backing up a database, unlinking it, deleting it, checking out the branch, fetching the right copy of the database from somewhere, restoring it, and linking it? That's really cumbersome.
You must have had some business process in mind when you designed all this stuff. What was it?
Tagged:
Comments
Please see below the information on our documentation page on how to use branches in SQL Source Control:
http://documentation.red-gate.com/display/SOC5/Working+with+branches
http://documentation.red-gate.com/display/SOC5/Merging+branches
Please note that you can make Migration Scripts run more than once by following the instructions in the following page:
http://documentation.red-gate.com/display/SOC5/Mark+migration+script+as+undeployed
I hope this helps you, but if you require any further clarification please let us know!
Thank you,
Product Support Engineer
Redgate Software Ltd
Please see our Help Center for detailed guides on how to use our tools