August 22, 2015 at 11:30 am
Comments posted to this topic are about the item Why Use Version Control?
August 23, 2015 at 12:42 pm
Version control for database is totally useless... right up until the time that you actually need it to undo a mistake without having to call for a backup tape to restore or need to prove to an auditor that your following your documented release procedures to a "T". 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2015 at 4:24 am
We store ALL database code in Microsoft's Team Foundation Server (TFS), but we could just as easily gone with Subversion or GIT.
Why? History, my man. We have the full life span of Stored Procedures, Functions, Views etc. In TFS it is possible to compare one version to another, so when a bug is introduced (never happens of course), or there is a gnarly bit of code to unwind, then a quick source code compare gives the before and after picture - from any version against any other version of the DDL or DML.
We also reference TFS in change management. When promoting a piece of code, TFS is referenced for the restore position of the original. Of course, all change management instructions start with the words "back up database to provide a restore point or note the backup name of the last successful post-daily", but if only one or two stored procs are changing do you really need a full restore out? Especially in BI where the databases are of significant size.
As a side bar, TFS can be referenced directly from within SSMS using the "Visual Studio Team Foundation Server MSSCCI Provider".
August 24, 2015 at 7:05 am
We've been using a version control for at least a dozen years and have been glad we did a thousand times over.
August 24, 2015 at 7:07 am
back_of_the_fleet (8/24/2015)
We store ALL database code in Microsoft's Team Foundation Server (TFS), but we could just as easily gone with Subversion or GIT.
Though we started with Source Safe, we've been using Subversion for several years now. Source Safe started corrupting some files so we switched.
August 24, 2015 at 8:29 am
Glad to hear a few of you find value in a VCS. I certainly have many times, and even when I haven't, I'm glad it's there in case I do need something.
August 24, 2015 at 11:27 am
I've been using it for a while, but the hardest part was knowing how to get started. We initially started with just the "upgrade" scripts, but after a really bad merge/prep experience we switched to DB Projects. That worked quite a bit better, with the main issue I've found being moving/renaming files with something like Git as the backend. Tracking back through that history gets a little harder - not impossible, but harder.
Having the change history has really helped, especially when people add the appropriate comments to their commits/check-ins so we know _why_ changes were made. It has also helped us make changes in branches instead of all changes being done in shared databases or locally with the possibility that something was missed or lost on the way to release.
August 24, 2015 at 1:47 pm
<GRIN>
Except that to continue the analogy, you also have to worry about the people who keep walking under you, seeing the safety net and packing it up, moving it, finding a way to temporarily disable it without any warning to others, or even upgrading it to safety net 2.0 without telling you!.
</GRIN>
Having a VCS is a great idea, if you use it, and if the team agrees and does in fact use it.
Dave
August 24, 2015 at 1:54 pm
It helps when you use VCS and all builds to the databases (except local) have to come from the source control system. We had all of the systems locked down so no schema changes could happen by the developers. While production was not completely locked down, practice was to push all changes through the VCS. We had rare instances for emergency changes or changes that would not work as well through the automated system -those were done in controlled updates, but all other changes were done from versions checked in to the mainline branch.
And yes, getting buy-in from the developers can be challenging at times. 🙂 It helps when they understand the benefits of keeping versions and knowing what's being released.
August 24, 2015 at 5:25 pm
djackson 22568 (8/24/2015)
<GRIN>Except that to continue the analogy, you also have to worry about the people who keep walking under you, seeing the safety net and packing it up, moving it, finding a way to temporarily disable it without any warning to others, or even upgrading it to safety net 2.0 without telling you!.
</GRIN>
Ah yes! The fantastic version 2.0 of the safety net that has the larger holes in it to save on the cost of netting material! Let's hope the netting material is rope and they use the saved rope to hang themselves. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
August 25, 2015 at 8:14 am
I'm probably not using it near as efficiently as I could, but I simply couldn't live without version control. I use Subversion and it has not only saved my backside on occasion, it also keeps work more organized, lets me try out all kind of crazy ideas with no worry about screwing up production and even functions as a "time machine" of sorts. Just the ability to nuke a working copy, check out a new one and start over from scratch is worth its weight in gold, to say nothing of more advanced capabilities.
I had even more fun when I finally got comfortable with branching and re-integrating. It's to the point now when I create a new branch I have this little Floyd in the back of my head saying "Oh boy! Are we going to try something dangerous now?" (Yes, I'm that old)
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
August 25, 2015 at 12:29 pm
It's 45 years since last I worked without source control; and I can't understand why people still do it.
When I arrived at a new job in 2002 I was absolutely flabbergasted to discover that the database stuff wasn't in source control. The first thing I did apart from starting an internal war over security (the software from the development team was wide open to attack) was to get scripts for the databases' schemata into source control; and then get bug fixes and other upgrade scripts into source control too.
I was really amazed to discover someone in 2002 doing serious database development without source control. They were lucky that the absence of it hadn't caused a disaster before then (see Jeff's first comment in this thread) - they were a fairly new startup and hadn't been running very long on customer sites, if they had carried on as they had started it would have been catastrophic when they discovered they needed different schemata at different customer sites because of the companies commitment to customisation, and then on top of that would find that even with customers with the same facility sets some would accept version upgrades while others wouldn't - supporting many versions without any version control wasn't going to be fun. Or maybe they'd never have been able to get those customer sites all around the world because they wouldn't have been able to provide the different versions.
Tom
August 26, 2015 at 7:35 am
Here is a great list from a StackOverflow question that I quote a lot. I bolded the ones I think apply to SQL Server.
Made a change to code, realised it was a mistake and wanted to revert back?
Lost code or had a backup that was too old?
Had to maintain multiple versions of a product?
Wanted to see the difference between two (or more) versions of your code?
Wanted to prove that a particular change broke or fixed a piece of code?
Wanted to review the history of some code?
Wanted to submit a change to someone else's code?
Wanted to share your code, or let other people work on your code?
Wanted to see how much work is being done, and where, when and by whom?
Wanted to experiment with a new feature without interfering with working code?
Keeping track of what happens in your SQL code, schema changes and so forth is good. It creates a standard that everyone can follow. Even though the code is accessible to all, making requests properly, tracking those changes outside of in-code documentation, having the ability to revert those changes and comparing code are all pretty good features to have.
September 2, 2015 at 7:03 am
I have used version control (SourceSafe, StarTeam, RCS, TFS, and a couple others) at several jobs now, and I think it's very important, for all of the reasons previously mentioned in this thread. What bothers me is when someone else checks in some code without putting in a comment. I asked someone about that one time, and was told that "you can just use the diff functionality to find out what changed". This is true, if the file is a text file (good luck if it's a spreadsheet), and even then, it takes time to compare versions and figure out why the changes were made, especially if they were for a rare edge condition. I usually err on the side of comments that are (almost) too long.
September 2, 2015 at 7:23 am
Stephen, you bring up a good point about text files. Technically, DTSX files are text (just XML, right), but trying to maintain diffs of those is a beating because of all of the fluff that's maintained. What are people using to diff DTSX files and version those appropriately? The best I've seen so far is to go to more of a "checkout" system there, but even then it doesn't really allow for the concept of branching and merging. While it's not a huge issue, it is a challenge and has prevented people from doing much with SSIS files in version control.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply