Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Staging Deployments Expand / Collapse
Author
Message
Posted Thursday, November 29, 2012 10:21 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 6:53 PM
Points: 31,177, Visits: 15,623
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
Posted Friday, November 30, 2012 6:38 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:44 PM
Points: 2,598, Visits: 3,944
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
Posted Friday, November 30, 2012 6:52 AM


Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, November 1, 2013 3:03 PM
Points: 1, Visits: 8
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
Posted Friday, November 30, 2012 7:16 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, October 8, 2014 9:37 AM
Points: 94, Visits: 77
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
Posted Friday, November 30, 2012 7:41 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Thursday, March 7, 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
Posted Friday, November 30, 2012 7:43 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 12:14 PM
Points: 1,706, Visits: 4,848
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.
Post #1391310
Posted Friday, November 30, 2012 8:04 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, October 13, 2014 6:00 AM
Points: 79, Visits: 756
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
Posted Friday, November 30, 2012 8:25 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
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
Posted Friday, November 30, 2012 8:47 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, October 17, 2014 12:12 PM
Points: 2,049, Visits: 3,587
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
Posted Friday, November 30, 2012 9:12 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, September 2, 2014 12:18 PM
Points: 350, Visits: 259
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 »

Add to briefcase 12»»

Permissions Expand / Collapse