December 3, 2012 at 7:52 am
andycao (11/30/2012)
Seriously, if you architect things properly then DB changes can and should go out way ahead of the apps.
David Benoit (11/30/2012)
We deploy database changes separately from code changes and allow for a layer of abstraction. The benefits here are tremendous although there is a more complicated framework that has to be in place in order to support this. However, when you are able to make database changes, apply the data to those changes, all in preparation and before the application "knows" about it, can really be a huge savings on the day of an application release AND can allow for some pre-change testing to ensure that the application is going to perform as expected.
I agree with the above. If you are releasing on an agile schedule, you will almost always know about the database changes first, before the application code changes are complete. The design of the system and the release process should permit database changes to be released independently of the code changes. That way, database changes are already there when the application changes are released. This technique splits the testing of the two and can easily result in a reduction of implementation problems and issues.
December 3, 2012 at 8:27 am
David.Poole (12/2/2012)
...Go-live doesn't particularly worry me, it is roll back that causes me to tuck my trousers in my socks so no-one can see I'm scared.
When we submit change orders to production control for deployment, we're required to provide a rollback script or at least a text file containing a set of instructions. For the web application, services, and BI developers, that's relatively straightforward, simply copy in the previous version of the modules, even if it involves temporarily taking the application offline.
If I'm deploying something like an insert/update/delete script, I will perform a [ROLLBACK] within the batch in the event of an error of if @@ROWCOUNT returns an unexpected value. However, in the realm of the database, there is no easy and reliable way to rollback a batch of updates or schema changes... not hours or days after the batch has already been committed in a TB sized production database with several hundred users.
In many cases the rollback instructions would go something like this:
#1 Restore database to most recent backup prior to deployment date. (LOL!)
OR
#2 Contact me, we'll discuss what specifically needs to be restored, and then I'll write the script.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 26, 2012 at 4:17 am
David Benoit (11/30/2012)
We deploy database changes separately from code changes and allow for a layer of abstraction.
For this we have started using ALTER TABLE approach insead of TMP..INSERT approach plus keep columns nullable which makes the database chanegs independent of application side changes but finger crossed that nobody is useing "select *" in any SP or sql query :w00t:
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
April 7, 2017 at 6:40 am
I've been involved in all variations of deployments, most of which involve databases for which I did not originally develop. But like I said five years ago, if you have a logical layer of views, stored procedures, and meta-data between your tables and the application, then it makes rolling out changes much easier and less risky.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 7, 2017 at 6:41 am
Well, we already have the SQL code stored inside the database so it can be deployed along with database changes to the server. Maybe we should also make it possible to store and distribute application code to the database at the same time. Then when the application connects, it pulls and implements any changes as they are required, similar to Windows Update. Many commercial applications already check for new versions and advise us when available. Then you simply advise users ahead of time that changes will be available and/or required at a certain point so they can plan for the update time.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
April 13, 2017 at 1:12 am
In my experience most updates occur simultaneously. Sometimes you get database changes that do not alter the interface (i.e. stored procedures and/or views are used and do not change their specification). More rarely is the scenario where the interface is changed requiring both app and database changes followed in a later release by either the app and/or the database changes. The most rare though it the app deploying an alternative module that is switched on, thus replacing the current module, as the database changes with this switch occurring through either configuration or lookup data (e.g. dynamically loading assemblies and instantiating classes from them).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply