We are planning on using Red Gate SQL Source Control, but have not yet decided which source control system to use yet: you can use Subversion (SVN) or Team Foundation Server (TFS).
Which one should we choose and how does that affect the way Red Gate SQL Source Control?
Here are some factors that might affect our choice:
We use SQL Server 2008 R2
We do not currently use SVN or TFS
We will not be using either SVN or TFS to source control our non-database code
We get TFS with our MSDN license, so cost is not a factor
We work both in the same office and remotely
Any help or advice would be appreciated.
EDIT: For non-database code we use VSS, which we are going to replace with Mercurial (with Kiln) later this week.
EDIT: Since posting this question, I have found out that Red Gate SQL Source Control will work with any source control system that has a suitable command line. So, we could get it to work with our implementation of Mercurial/Kiln and would definitely consider that. Any advice on that would be very helpful.
I have only worked with SVN with Redgate Sql Source Control, though I have worked with TFS outside of the context of database source control.
My take is this: barring deep integration with the methodology templates in TFS, there's no advantage to using TFS in this situation. The integration with SSMS is very common-sense and intuitive for SVN, so it's worked very well for my team.
I personally found TFS pretty heavy, administration-wise, and have found SVN server very light and easy to work with. If you've got someone who already has TFS Administration experience, that might be an argument for TFS, but barring that, I'd recommend SVN.
I keep coming back to one factor: I could have SVN up and running with this system inside of an hour, and God knows how long with TFS.
As per your update - if it's possible, I strongly recommend getting it integrated with your existing repository, but if it's a choice between waiting for the perfect integration and getting your db's under version control today, there's no choice in my mind.
SQL Source Control has an Early Access Release that works with Mercurial. It would be great if you could try it out. You can find out more information at http://www.red-gate.com/messageboard/viewtopic.php?t=12786. Like Chris said, it's probably best to have one source control system for both your application and db code if possible.
Related
I have an ERP system which I maintain with a team of people. However lately we seem to be loosing track of who's changing what and we need a solution to be able to control these changes. We are looking into the enterprise version of GIT as all our software development and web development would work perfectly with it. Not to mention I have some experience with GIT already.
The problem is we need the version control to extend to our SQL Server which we use SQL Server Management Studio to maintain. We have thousands of tables in 6 main databases which have a lot of stored procedures which are being changed.
It's not so much we want to control the source as in, permissions and refuse changes by people. It's more, we need a way of tracking changes and attaching explanations to help our future selves.
Does anyone know any solid solutions which would fit our purpose?
Assume the cost isn't a main factor.
I was using RedGate tool. It can integrate with Git.
RedGate SQL Source Control
I have been asking myself this question once. So I've found following solution which I can suggest you to use.
It is a SQL Server Data Tools that solves the problem.
The tools include SQL server database project for visual studio. This project will store your database structure. You can just add it to you solution. Then run a schema comparison with your database to take a snapshot of your current database state. You can choose what objects to compare. Since this moment your have all your changes being tracked by your VCS. Every change is documented now.
You can make changes in DB project and when you are done just run schema comparison, get the update script and apply those changes to your SQL server database. It is really not that hard to work with your schema from DB project as it provides intellisense, syntax validation. Also it is possible to write and execute SQL queries against you database.
We currently have our database objects in TFS2012 and happily use redgate sql source control to check in & getlatest. So far this works great.
I now want to use SSDT in order to create a dacpac that defines the latest schema.
What I'm missing is how to link the SQL Server database project so that a check-in via redgate source control would ripple through to the database project (upon a getlatest) and therefore schema changes would be shown in the dacpac upon a recompile?
thanks
As it's 3+ months after I posted the question, and https://blog.stackoverflow.com/2011/07/its-ok-to-ask-and-answer-your-own-questions/ I guess I should state what the outcome was...
We had a number of unresolved (at the time at least) issues automating SQL Compare, which was the reason for looking into SSDT in the first place. The more we looked at SSDT the more we became impressed with it (still has some issues, but doesn't everything?) to the extent that we have now dropped our use of redgate, therefore the need for SSDT to play nicely with redgate is no longer required.
This is not to say we're not a fan of Redgates products or that the answer is to drop redgates products - just that they didn't meet our requirements when our requirements changed (we started to automate everything).
I'll still be sending Redgate a Christmas card, honest :)
Here's a document describing how to use SQL Source Control and SQL Compare in conjunction with SSDT database projects. It's beta functionality, and we're aware of a few issues, but please report them to us (support#red-gate.com) so we can prioritize our backlog.
We are planning to put out SQL Objects (Tables, StoredProcedures, UDF's and Views) under our existing TFS 2010 versio control.
Is is possible that any check-in's made to the objects under TFS version control gets automatically sync'd to our Development server. The technical team here are not so interested in having to make changes at 2 different places (Development Server + Check-in at TFS server). Its an overhead process change for them.
Late answer, but I hope it can be useful:
Recently, I've tried to find the solution for a similar problem, and I've bumped into a sql source control add-in for SSMS that works with the TFS, and I found some answers by reading this article:
SQL source control reduce database development time
I think it can be useful for you too (in case you couldn't solve your problem)
Hope I helped.
The best solution by far to do this is to use Red-Gate Source-Control. You will not find a better and easier product to do this, and all the other benefits you get from using it is huge. For example, it integrates 100% into SQL Management Studio.
You should use Visual Studio Database Projects. You'll get the best of both worlds! Source control and automated builds and deployment.
I found the solution to my unique scenario. I used the Sql server management studio project by using the TFS plugin for SSMS. Team can now easily make changes in the Development environment using SSMS and make check-ins at the same place. Nice and easy way to do things without additional overheads. However, this only solves the purpose of version control. I am still researching on how can we do schema compare and automated deployments using SSMS projects.
I've been searching for some time for a good solution to implement the idea of managing schema on an SQL Server Compact 3.5 database.
I know of several ways of managing schema on SQL Server Express, SQL Server Standard, SQL Server Enterprise, but the Compact Edition doesn't support the necessary tools required to use the same methodology.
Any suggestions/tips?
I should expand this to say that it is for 100+ clients with wrapperware software. As the system changes, I need to publish update scripts alongside the new binaries to the client. I was looking for a decent method by which to publish this without having to just hand the client a script file and say "Run this in SSMSE". Most clients are not capable of doing such a beast.
A buddy of mine disclosed a partial script on how to handle the SQL Server piece of my task, but never worked on Compact Edition. It looks like I'll be on my own for this.
What I think that I've decided to do, and it's going to need a "geek week" to accomplish, is to write some sort of a tool much like how WiX and NAnt works, so that I can just write an overzealous XML document to handle the work.
If I think that it is worthwhile, I'll publish it on CodePlex and/or The Code Project because I've used both sites a bit to gain better understanding of concepts for jobs I've done in the past, and I think it is probably worthwhile to give back a little.
Edit on 5/3/2010:
If someone is willing to "name" the project, I'll upload the dirty/nasty version that I've written for MS SQL to CodePlex so that maybe we can start hacking out a version of SQL Compact. Although, I think with the next revision of the initial application that I was planning, I'm going to be abandoning SQL Compact and just use XML Files for storage, as the software is being converted from an Installable package to being a Silverlight application. Silverlight just gives a better access strategy.
I am currently looking into Migrator.Net.
This allows you to write changes to your database, called migrations, directly in C#.
These migrations can contain everything from simple table additions/drops, column modifications, to complicated data update code.
When your application boots, it can verify what version the database is currently in and apply any migrations that are required to bring it up to date. All this is handled automatically. The code to run this update is as simple as:
Assembly asm = Assembly.Load("LocalModels.migration");
Migrator m = new Migrator("SqlServerCe", "Data Source=LocalModels.sdf", asm, false);
m.MigrateToLastVersion();
I am having a couple minor issues with the Compact support (it assumes the default schema is dbo). But I don't think it will be too difficult to fix them.
some random thoughts (not sure I can fully answer though)
the Microsoft Sync Framework is one option. I haven't had a chance to fully appreciate what it can do once you've deployed it after the initial first time (which seems to work fine). There's a MSDN site for it here
You can execute scripts on a mobile device, but not through something like SQL Management Studio, so in theory you could manage/maintain T-SQL scripts but the down side is that the T-SQL would be convoluted (to CE's supported statements) and I don't know a way to "automate" execution - but the Sync Framework might hold some answers..
If one of your key criteria is going to be working efficiently over a small pipe, the only real choice you have is to store a DB Schema Version (maybe somehow tied to the scripts checked into your CMS) and when an update is needed, the change scripts are sent over the wire and applied in order. You would probably want to keep a log in your DB as well of these scripts being applied so you can gracefully handle disconnects, reboots and other potentially nasty problems.
Is SQL Server Management Studio any use for you?
http://technet.microsoft.com/en-us/library/ms172933.aspx
Interested if anyone has used VSTS Database Edition extensively and, if so, which features did you find the most useful over the standard Visual Studio database projects?
What are the most compelling features as opposed to alternative schema management options or tools like RedGate's SqlCompare etc?
Edit: Microsoft just released the RTM version of Database Edition (GDR) which adds support for SQL Server 2008 - link is here. I've previously blogged (briefly) about it here.
Has anyone had a chance to do any real work with the GDR? It looks like there are some real enhancements including refactoring support. I'd be really interested to hear if people are using it with SQL Server 2008...
Download From: [http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en]
We use the database edition functionality of Team Suite on Stack Overflow. As Vaibhav said, mostly it is useful because it gives you a one-click way to reverse engineer a database into source control, and keep it up to date.
Note that it also has decent Data and Schema compare tools as well. You can compare projects to physical databases and vice-versa. This makes it pretty easy to keep your database up to date, no matter where you make changes -- in the filesystem database project, or in the physical database itself.
If you compare it to tool like RedGates, that are specifically taylored for SQL Server, the benefits are that if you have the proper MSDN subscription you do not have to spend more money for other tools (but keep in mind that RedGate tools are much more mature) and it covers some points (like regression tests and unit tests at the DB level) that other tools do not cover and it make so in a integrate manner with other testing tool of VSTS, so that you can record results in Team System.
Compared to a tool like Embarcadero ErStudio (my solution of choice) it misses the cross database features, and this is a big problem, at least for me.
If you are a "all Microsoft" shop with the proper MSDN subscription it could be worth spending time on it.
We are currently using the GDR 2008 projects for managing our entire database development and deployment on a greenfield system. We use a TFS build script to call out to the MSBuild task for deploying the databases along with executing the data generation plans for pre populating the testing environment with data.
The key with the data generation plans was finding the build task to use which is :
TaskName="DataGeneratorTask"
AssemblyName="Microsoft.Data.Schema.Tasks, Version=9.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
All of this gdr project work has been unbelievably helpful and I think it is well worth the learning curve to get to know these project types. The value they provide is astronomical in productivity and visibility.
It allows us all to view the entire system in a single visual studio solution along with allowing us to start with a clean slate of our system at any point in time with either a click of the deploy command or a custom build configuration.
This blog
will help with getting the TFSBuild script to run if you're interested.
The VSDB test integration is so painful to configure that we abandoned it, and that's the only thing it's got that Red-Gate doesn't.
Red-Gate's tool is miles more useful. It does live DB and scripts in folders, but also has "snapshots." The aspect of Red-Gate SQL Compare that gives it the win is its Snapshot ability and the fact that your license allows you to deploy their assemblies and use them to perform database maintenance at customer run-time.
It has made upgrades in the COTS application that I develop a breeze. A Snapshot is a binary schema representation. You can package them as resources in an assembly, then use the snapshot in a customer run-time schema compare to bring an existing database up to the current rev.
Probably the best advantages are around being able to version control individual DB schema objects (which you could do with the older "Database Projects"), but have the power to "build"/deploy the project and convert those individual scripts into a complete database.
The ability to import scripts and have the Wizard covert individual schema items into separate files is very handy if you've inherited a DB schema.
Given that recently the licensing model changed, it makes it even more enticing because it's included with the Developer edition SKU. It also provised support for "Database Unit Tests" which might be useful.
From the 2008 GDR, I understand that they now support SQL Server 2008.
You can do database versioning for one. That is useful.
The other thing that is really useful is the ability to define type of seed data for testing. Through this Visual Studio will populate the database with random data and this is great for testing purposes.
There are other benefits as well of course.
It is always useful to put everything under the same source control, so your data-dude can be shelving, checking in, compare with history, and even resolve workitems and bugs using the same tools that other team members are using.
Also to be able to have one versionning mechanism across the whole application, in other words, it doesn't make sense to say that my source control has all the versions of my project while your database can't fit with any of these old versions, unless you take a backup or a snapshot of the database with each build.