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
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
Comment