January 18, 2017 at 12:03 am
Comments posted to this topic are about the item Put your Database under Source Control
Thomas LiddleSQL Server AdministratorVideo Blog - YouTubeWeb Blog - www.thomasliddledba.comTwitter - @thomasliddledbaFacebook - @thomasliddledba
January 18, 2017 at 4:50 am
thomasliddledba - Wednesday, January 18, 2017 12:03 AMComments posted to this topic are about the item Put your Database under Source Control
The Red Gate tools look nice, but we've actually done something where we've created a nightly job that scripts out all of the objects in every database on our SQL server to a folder structure on a network drive, and then runs GIT, which checks in any files that have changed since the previous night. This gives us automatic DDL backups of everything, and it's pretty nice.
January 18, 2017 at 6:51 am
Nice article. Please note that with Visual Studio you can also use SSDT and source control your database project. VS now integrates with GIT nicely so it can be the source repository
January 18, 2017 at 7:10 am
rgp151 - Wednesday, January 18, 2017 4:50 AMthomasliddledba - Wednesday, January 18, 2017 12:03 AMComments posted to this topic are about the item Put your Database under Source ControlThe Red Gate tools look nice, but we've actually done something where we've created a nightly job that scripts out all of the objects in every database on our SQL server to a folder structure on a network drive, and then runs GIT, which checks in any files that have changed since the previous night. This gives us automatic DDL backups of everything, and it's pretty nice.
rgp151 - That's a great way to perform backups of DDL's in all your databases. I hope you can share the code. 🙂 Another way to think about this is from a development perspective. In my world as a DBA, I support a common database on each of the servers I manage. The two teams (Engineering and Operations) we are always tweaking code and use the RedGate Source Control/Jenkins to source control and deployement.
I use the SVN repository we have (moving to GIT really soon) as my backup/version control.
I've always been in the mindset with Database Administration is that there are 1000 ways to skin a cat. I like your thought process.
Thomas LiddleSQL Server AdministratorVideo Blog - YouTubeWeb Blog - www.thomasliddledba.comTwitter - @thomasliddledbaFacebook - @thomasliddledba
January 18, 2017 at 7:11 am
browndog - Wednesday, January 18, 2017 6:51 AMNice article. Please note that with Visual Studio you can also use SSDT and source control your database project. VS now integrates with GIT nicely so it can be the source repository
browndog - Thanks. I'll need to do some more research with VS and GIT to become familiar with it.
Thomas LiddleSQL Server AdministratorVideo Blog - YouTubeWeb Blog - www.thomasliddledba.comTwitter - @thomasliddledbaFacebook - @thomasliddledba
January 18, 2017 at 9:40 am
browndog - Wednesday, January 18, 2017 6:51 AMNice article. Please note that with Visual Studio you can also use SSDT and source control your database project. VS now integrates with GIT nicely so it can be the source repository
True, BUT, this assumes all DDL changes are taking place though SSDT. If that's true then this works just fine, but in many environment many changes can and do take place outside of SSDT. The nice thing about the approaches being discussed is that they will version ALL DLL changes to source control, regardless of how they were performed.
January 18, 2017 at 10:09 am
rgp151 - Wednesday, January 18, 2017 9:40 AMbrowndog - Wednesday, January 18, 2017 6:51 AMNice article. Please note that with Visual Studio you can also use SSDT and source control your database project. VS now integrates with GIT nicely so it can be the source repositoryTrue, BUT, this assumes all DDL changes are taking place though SSDT. If that's true then this works just fine, but in many environment many changes can and do take place outside of SSDT. The nice thing about the approaches being discussed is that they will version ALL DLL changes to source control, regardless of how they were performed.
Agreed. You'd have to do a compare in the SSDT database project from source to the target DB to catch any changes made outside of the SSDT
January 23, 2017 at 3:18 pm
rgp151 - Wednesday, January 18, 2017 4:50 AMthomasliddledba - Wednesday, January 18, 2017 12:03 AMComments posted to this topic are about the item Put your Database under Source ControlThe Red Gate tools look nice, but we've actually done something where we've created a nightly job that scripts out all of the objects in every database on our SQL server to a folder structure on a network drive, and then runs GIT, which checks in any files that have changed since the previous night. This gives us automatic DDL backups of everything, and it's pretty nice.
@rgp151 - have you taken a look at DLM Dashboard, a free Redgate tool which uses the same approach? If it doesn't do what you want I'd be keen to understand why.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply