Disorganised mess

[techno]

Even something like SQLDelta will help enormously. We use it here for roll-outs and it has served its purpose well.

[bledubd]

get the redgate database script compare tool, that will save you a lot of headaches. create a sandbox on your machine if not possible to get one from the db, I am assuming you can install a sql developer edition on your machine

[Ruprect]

Easy. Day one. Here's a script file. Just paste all your changes in here. Keep appending your changes in here. Do not test. Day of roll out find that one long list of ALTER TABLE and ALTER Procedure statements executed in chronological order is not a goer. Manually ease every change through and hope for the best.

Do not learn from this, despite advising to the contrary. Ignore contractor. Carry on creating ANOTHER flipping script file for the next release, leaving the previous one broken. Contractor then gets pencilled in to do a release late this Friday. Contractor thinks, not on your nelly this will be one huge flip up.

Contractor asks for a sandbox db. Contractor gets refused. Contractor sweet talks DBA he quite gets on with to create a sandbox DB anyway.

Contractor lets the scripts rip. All hell breaks loose. Contractor is forced to work into the evening, ignoring most of what he has been asked to do, and on best endeavours bails out the sinking ship.

Contractor is at work this morning, feeling like he should be in an establishment working out the anchor points in his dream too.

Did contractor forget to change database names in said script then?

[suityou01]

How can all hell break loose on your sandbox db?

Easy. Day one. Here's a script file. Just paste all your changes in here. Keep appending your changes in here. Do not test. Day of roll out find that one long list of ALTER TABLE and ALTER Procedure statements executed in chronological order is not a goer. Manually ease every change through and hope for the best.

Do not learn from this, despite advising to the contrary. Ignore contractor. Carry on creating ANOTHER flipping script file for the next release, leaving the previous one broken. Contractor then gets pencilled in to do a release late this Friday. Contractor thinks, not on your nelly this will be one huge flip up.

Contractor asks for a sandbox db. Contractor gets refused. Contractor sweet talks DBA he quite gets on with to create a sandbox DB anyway.

Contractor lets the scripts rip. All hell breaks loose. Contractor is forced to work into the evening, ignoring most of what he has been asked to do, and on best endeavours bails out the sinking ship.

Contractor is at work this morning, feeling like he should be in an establishment working out the anchor points in his dream too.

[minestrone]

I don't really know that much about DB development but anywhere I have been that has had pretty big scripts the difference between dev and live is not touching it for 2 weeks, in fact you don't even use it, it's just accepted if it sits in source control unused and untouched for 2 weeks it's safe for live.

Since I started contracting I wonder if I am actually heavily medicated in a mental hospital suffering from delusions that I work in IT. Maybe CUK is just another anchor into that dream I have.

[MPwannadecentincome]

How can all hell break loose on your sandbox db?

[BrilloPad]

"how would you do it better"?

I would have replied "I already did it better than you numpties ever managed" then turned very aggressive.

[suityou01]

In a gig at the moment picking up some shambles of a project where ClientCo told the consultancy to hop it, and get a contractor in to sort.

Towing the rope as far as departmental procedures are concerned (I am the new kid on the block, with no remit to suggest changes - I am just here to get this release out)

The deployment process is somewhat unstructured. Specifically for database changes, and this is where I am having problems.

They want two scripts, one for regular DDL such as table creation, and one specifically for stored procedure creation.

Here's the rub. Every time a table or stored procedure changes, script it and append it to the appropriate script.

Then, as there is no database to test these monolithic scripts on, find out on the day of rollout that there are problems and firefight.

I spoke with one of the DBAs and kindly got him to set me up a sandbox database for my purposes. I then tested these scripts, and all hell broke loose. I tried to patch and firefight, but in the end just had to trim them down so that not every incremental change was in them and only the latest ones.

I then got put on the spot, and asked "how would you do it better" and the whole pack turned on me. I stated that overall, it was not best advised to have only LIVE under change control, rather the process of change should be managed from the development environment upwards, and that there are many fine tools available on the market to help create change scripts such as Embarcadero studio for one. They are not prepared to invest in such a tool, even though they are a chuffing big civil engineering firm.

Lots of head shaking, and only one person in the dept who spoke up for me and said that they were disorganised - I think he knows he is on his way out.

How on earth should I have approached this? I followed their processes until they broke and then offered alternatives to which they shook their heads and made me the bad guy.

Has anyone had similar config management problems (specifically around database change management) in the past, and if so what did you do

In the interim
Longer term