[dba-SQLServer] Version Control Integration

Arthur Fuller fuller.artful at gmail.com
Sat Jun 28 05:35:07 CDT 2008


Thanks for the insights, Nancy. My situation is approximately this, give or
take a detail. I have been brought on to take ownership of the database,
which has been previously maintained by one guy who is actually a trader but
he sure knows his way around databases. He's made a mistake or two here and
there, and some decisions which I might question here and there, but given
the 150 tables or so and the attending sprocs, he's done a remarkable job
for a guy whose profession is stock-trading not database design. We have one
.NET guy who is entirely responsible for the web interface. He writes most
everything of consequence in C#. We have the traditional db units in place,
to wit Dev, Staging and Production, but there is no concrete and verifiable
version control. I persuaded them to license the Red Gate Toolbelt so we are
beginning to get on the right track, and can do comparisons between Dev and
Staging and Production, for example, but we still don't have version control
in place, and this worries me. Ideally, I want to get to a single solution
that handles both my changes to the database and the changes to the front
end (the .NET part) and can do all the expected things like Diff the
versions, roll back to yesterday's or last week's version, and so on.

A.

On Fri, Jun 27, 2008 at 5:37 PM, Nancy Lytle <word_diva at hotmail.com> wrote:

> I don't know what your situation is about developers (how many, etc) but
> TFS
> lets DBAs and Developers share so much more than just version control.  You
> can add tasks across from Dev to DBA and have it included in their project
> monitoring, etc.  The only problem can be if you use Linked Servers, then
> setting up the version control can be a bit more of a pain, depending on
> your environment.
>
> Nancy
>



More information about the dba-SQLServer mailing list