April 3, 2008 at 3:49 am
Hi All,
Just a general question to find out how you control releases onto your live enviroment. Do you use third party apps to store the scripts or do you implement a manual process requiring the DBA to make notes on what objects have changed etc, as well as storing the scripts in a "release" folder.
Am just interested on seeing what other people do.
John
April 3, 2008 at 6:41 am
We currently have two processes, both effectively the same. One of them we use an in-house developed tool that generates scripts based on a manifest of changes. We basically just have to keep a list of locations of files in source control (VSS or TFS) and then the tool will generate a deployment script that we test on a pre-release environment and then run in production. The other approach is to use Microsoft's Visual Studio Team Edition for Database Developers. It has a whole paradigm for deployments that we're buying into whole hog. It works pretty well. Again, it generates a script based on changes in source control. Only it generates it's changes based on comparing what's in source control to a database. We generate that script against the pre-release environment and then run it in production.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 3, 2008 at 11:57 am
I like using ApexSQL Diff (similar to a RedGate product). Checks for differences between dev and test, and differences between test and production. Generates the scripts for me.
Then I review the scripts, test them against a fresh copy of the production database, make sure everything will work. Then, and only then, do they get run in production.
(I have to admit that this is the official and standard practice, but that the developers here, being ... well, I can't write my opinion in a public forum .... Let's just say they're in the habit from before I was hired of just running scripts in production every now and then, without real testing first. And my "requisition requests" for things like straightjackets and tasers to keep them away from the production databases haven't been approved yet.)
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 3, 2008 at 12:34 pm
Don't forget to ask for the electrified razor wire too.
I work for a large organization. We have a few rogues who still think that Dev/QA/Staging are all wrapped up in the Production server. Convincing these groups of the desirability of "stability" is an up-hill battle.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 3, 2008 at 1:58 pm
GSquared (4/3/2008)
I like using ApexSQL Diff (similar to a RedGate product). Checks for differences between dev and test, and differences between test and production. Generates the scripts for me.Then I review the scripts, test them against a fresh copy of the production database, make sure everything will work. Then, and only then, do they get run in production.
(I have to admit that this is the official and standard practice, but that the developers here, being ... well, I can't write my opinion in a public forum .... Let's just say they're in the habit from before I was hired of just running scripts in production every now and then, without real testing first. And my "requisition requests" for things like straightjackets and tasers to keep them away from the production databases haven't been approved yet.)
Just wire in that DDL trigger you have set up on the production server:
CREATE TRIGGER Zap ON Create, Alter, Drop
as
Begin
declare @i int
declare @voltage bigint
Set @i=0;
While @i<20
BEGIN
Set @voltage=@i*10,000
Exec Fire_Taser @voltage=@voltage
END
EXEC Cleanup_DeskChair
END
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply