Version Control for Stored Procedures

,

Last year Steve

Jones (or is it Jeve Stones?) did a great

series on version control. At the stage where tools are now, source code for

SQL just isn't fun. Or easy. Is there a better way? Not sure this is better, but

this week I'd like to discuss a technique that Sean,

Leon & I

used recently that has a bit different focus.

It started with an enterprise application that had to go from design to

production in 90 days, with a team of three developers. The new application was

to be a new UI over an existing schema, in places we would be able to add or

change things, in others we were stuck with it because of the number of legacy

applications we already had in place. The old app uses a total of about four

stored procedures - let me tell you that this is NOT the way to get great

performance. One of our main goals in building was to move as much code as we

could into stored procedures.

By the time we rolled out the first beta for testing, we already had fifty or

more procs. Fairly well organized, lightly commented, but a good initial

structure. That was on about day 30. By the time we hit our final roll out date

2 months later,  we had done more than a hundred builds, almost everyone

having at least one new or changed procedure. To make matters a little more

complex, we had a test db that we used for development, then we would deploy our

changes to yet another test database. We had about 10 people testing different

portions of the app, often with different versions.

We used VSS for the application code (two projects, one UI and one dll), but

NO source control for the procs.

Amazed? Astounded? Aghast? Im out of "a" words, so I'll continue.

If the tools had better integration we probably would have put them in source

control, but as Steve discusses in his series it's not that easy. Not

impossible, but takes a bit of work AND a system. We didn't really have a system

in place that we were used to for team development. Growing pains of a small

company I guess!

Anyway, what we decided to do was anytime we changed a procedure, we

versioned it by creating a new proc and appending the version number to it,

something like this:

Create proc usp_test @param

varchar(12) as

--blah blah

Then when we versioned, the next

one would look like this:

Create proc usp_test1 @param

varchar(12), @other param varchar(10) output

--blah blah

Some of the procs never got changed. Others wound up having 10 versions. The

nice part was that any point we could look back in VSS and see which version of

the proc we were using at the time. Even better, we could have many different

versions deployed and working at the same time, all while we continued to make

changes based on test results. Worked pretty well for a low tech solution. More

importantly, we didn't have to spend a lot of time managing it.

Now to digress a bit, a couple weeks ago I finished reading SQL

Server 2000 Performance Tuning and came across a trick that I mentioned in

the review I wrote - and that is interesting enough that I'd like to repeat it

here. You can use a little known feature of SQL (little known to me anyway!) to

create multiple versions a different way, like this:

Create proc usp_test as ..........

Create proc usp_test;2 as .........

If you do this, you wind up with the source code for both (or more) procs in

syscomments. You can just call usp_test and it calls the original/default proc,

or you can qualify it as usp_test;2 to execute the later one. It's interesting,

but I think confusing to administer since you only see one proc in Enterprise

Manager or Query Analyzer. You have to look at the source to see that there are

multiple versions.

Would I use the same system again? You bet! At the end of the development

cycle it had never caused us a problem and turned out to be as efficient as we

could have hoped. I'm looking forward to your comments on this one:-)

Rate

1 (1)

Share

Share

Rate

1 (1)