<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQLServerCentral.com
»
Editorials
»
Staging Deployments
18 posts, Page 1 of 2
1
2
»»
Staging Deployments
Rate Topic
Display Mode
Topic Options
Author
Message
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Thursday, November 29, 2012 10:21 PM
SSC-Dedicated
Group: Administrators
Last Login: Yesterday @ 2:54 PM
Points: 31,410,
Visits: 13,726
Comments posted to this topic are about the item
Staging Deployments
Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
Post #1391011
OCTom
OCTom
Posted Friday, November 30, 2012 6:38 AM
SSCrazy
Group: General Forum Members
Last Login: Yesterday @ 7:34 AM
Points: 2,013,
Visits: 2,840
For me, the database and code changes occur simultaneously. I don't recall haing a database change not affect applications in some way. Some database changes such as adding new fields may not affect the application. The application may run OK. But, whenever a field is added, someone wants to use it right away. That means an application change.
Post #1391274
Jerome Thomas
Jerome Thomas
Posted Friday, November 30, 2012 6:52 AM
Forum Newbie
Group: General Forum Members
Last Login: Thursday, December 27, 2012 5:21 PM
Points: 1,
Visits: 7
We try to roll out schema and code changes together. The exception to this is deploying features in phases. For example, a use based licensing option had the usage of logging deployed two versions before the licensing feature so that the data would be available.
Post #1391283
SCGJohn
SCGJohn
Posted Friday, November 30, 2012 7:16 AM
SSC Journeyman
Group: General Forum Members
Last Login: Friday, April 19, 2013 1:07 PM
Points: 92,
Visits: 42
I would say that about 20% of the time that we're doing application updates it requires db schema changes. Of these about 50% end up requiring us to coordinate the deployment with an application code update do to the complexities of the data and/or enhancement that was required. Most of the time we're able to get around that coordination using defaults either in the table itself or stored procedures that handle the new table data..
Post #1391296
NF Scott Smith
NF Scott Smith
Posted Friday, November 30, 2012 7:41 AM
Mr or Mrs. 500
Group: General Forum Members
Last Login: Thursday, March 07, 2013 6:48 AM
Points: 587,
Visits: 351
In most situations (minor updates & fixes) I keep the updates together, but some particular projects with have worked better with a phased implementation using optional parameters etc.
It's been very case by case for me.
Also, I'm doing both parts of this myself as the DB & application developer... so there aren't separate teams or even different people to coordinate it all with.
Cheers,
Scott
Post #1391308
Eric M Russell
Eric M Russell
Posted Friday, November 30, 2012 7:43 AM
Ten Centuries
Group: General Forum Members
Last Login: Yesterday @ 2:02 PM
Points: 1,162,
Visits: 3,333
If an application is loosely coupled (if the term is appropriate here) with the database using stored procedures, web services, and meta-data configuration, then even significant changes to the database may not require any changes to the application at all. The application should also be coded to accomodate things like the addition of optional stored procedure parameters or new columns in the resultset without breaking. That's the ideal architecture.
Yes, where I work there are separate teams working on the database changes and application changes; they submit change orders seperately to the production control / DBA team, and database vs. application changes typically get deployed at different times, sometimes even days or weeks apart with no adverse affect on the users.
"Wise people understand the 10,000 things without going to each one.
They know them without having to look at each one,
and they transform all without acting on each one." - The Tao Te Ching: Verse 47
Post #1391310
andycao
andycao
Posted Friday, November 30, 2012 8:04 AM
Valued Member
Group: General Forum Members
Last Login: Friday, May 17, 2013 7:02 AM
Points: 74,
Visits: 640
Wow, then I guess we have the "ideal"! Seriously, if you architect things properly then DB changes can and should go out way ahead of the apps. DBAs are faster at their jobs than Web Devs anyway.
Just make sure to nuke all select *'s (and even worse, select * into #temp) and be very careful with SPs that call other SPs for a resultset.
Only the major DB changes should need to be done in a maintenance window, like switching to nvarchars now that you have international clients.
Post #1391337
TravisDBA
TravisDBA
Posted Friday, November 30, 2012 8:25 AM
Ten Centuries
Group: General Forum Members
Last Login: Thursday, May 09, 2013 9:23 AM
Points: 1,288,
Visits: 2,996
OCTom (11/30/2012)
For me, the database and code changes occur simultaneously. I don't recall haing a database change not affect applications in some way. Some database changes such as adding new fields may not affect the application. The application may run OK. But, whenever a field is added, someone wants to use it right away. That means an application change.
Same here Tom. We call this Change Control and database changes and applications per a particular project or even a trouble ticket, are always rolled out at the same time to our QA and Production environments. We do so many block changes that to do otherwise is just inviting disaster. The Development environment is a different story. That is usually up to the developers how they want to handle this. That is their sandbox, so we don't get that involved in the sequence of their development cycle. Change Control does not currently dictate sequence of events in that environment. But a block change in QA and production, database and application code always pushes together. The only exception to this in QA and Production is when there is a change to the application and not the database, or vice versa. Then just the app code or database code is pushed and that does happen occasionally.
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...
"
Post #1391362
David Benoit
David Benoit
Posted Friday, November 30, 2012 8:47 AM
SSCrazy
Group: General Forum Members
Last Login: Saturday, May 18, 2013 8:26 AM
Points: 2,063,
Visits: 3,440
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.
David
@SQLTentmaker
SQL Tentmaker
“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Post #1391382
Chris.C-977504
Chris.C-977504
Posted Friday, November 30, 2012 9:12 AM
Old Hand
Group: General Forum Members
Last Login: Tuesday, May 14, 2013 2:10 PM
Points: 349,
Visits: 256
They happen at the same time here. We are a almost always a one person per project shop, so I'm not sure my input is worth much to others.
I have considered doing things like 'extra architecturing' of the db so it can be flexible, but generally either the client can't give me enough guidance about where they will be headed in the future* or they can't/don't want to pay for it.
FWIW,
-Chris C.
* - sometimes a client gives me a very accurate vision about where they will go in the next version, and I don't believe them; haven't been wrong yet (generally these are non-technical people doing their first project and the naiveté is more than obvious)
Post #1391409
« Prev Topic
|
Next Topic »
18 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
