November 29, 2012 at 10:21 pm
Comments posted to this topic are about the item Staging Deployments
November 30, 2012 at 6:38 am
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.
November 30, 2012 at 6:52 am
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.
November 30, 2012 at 7:16 am
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..
November 30, 2012 at 7:41 am
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
November 30, 2012 at 7:43 am
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 30, 2012 at 8:04 am
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.
November 30, 2012 at 8:25 am
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. ...:-D"
November 30, 2012 at 8:47 am
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“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
November 30, 2012 at 9:12 am
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)
November 30, 2012 at 9:22 am
Eric M Russell (11/30/2012)
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.
Almost all (if not all - a sweeping statement I hesitate to make!) of our application code is coupled loosely enough to the DB to allow us to deploy database changes ahead of application changes. We insist that all stored procedure calls pass the parameters by name (i.e., EXEC storedProc @parameter1 = 'x', @parameter2 = 'y' rather than EXEC storedProc 'x','y'), so we can add parameters, with acceptable default values if necessary, without breaking the application code. Our application developers also write their code such that it works so long as the columns it expects are present in result sets and does not break if columns are returned in a different order or additional columns are included.
Since we database developers have to complete our work to a significant degree before the application developers can begin coding against it, the database changes are almost always ready for security review, testing, and deployment before the application code is finished. We usually push database changes through security review and QA and sometimes even deploy it to production before the corresponding application code. This keeps our security review and QA teams from being unduly burdened by big changes involving both database and application code. It also lets us find and fix any problems that show up in security review and testing while the application developers still have the hood up on their code to make any changes needed there more conveniently. Plus, we can deploy the database code to production at a time when we can roll back any changes if unexpected problems occur without necessitating a corresponding rollback of the application code.
Jason Wolfkill
November 30, 2012 at 9:50 am
Usually we deploy the database and application changes together, but not always. We actually use SQL Compare to make all of our database changes in an environment where multiple people review the changes before we decide if the database change is "in" or "out." If we know that the db change won't impact the application then we are okay pushing it out in advance of the application changes.
November 30, 2012 at 10:26 am
Most of the time, they happen in parallel, especially for new features. But, since most of our business rule are in SP's, it's common to release a new version of an SP without changing the .NET code.
November 30, 2012 at 1:51 pm
Generally we do the database changes first. Usually these are just adding more nullable fields and using optional parameters at first for the extra functionality we've added. Which after we get all the application code up to date we might make these parameters optional no longer and the extra fields no long nullable. If the changes are going to break programs basic functionality we usually deploy both at the same time. Or as close as possible.
December 2, 2012 at 3:17 pm
For us it depends. Each release goes through an evaluation and sanity check prior to go-live.
Continuous integration and test driven development mean that we have a high degree of confidence that things will work as rehearsed in the pre-live environment.
Some releases are code only, some are DB only. Some require both but the DB can go first shortly prior to the live deployment. Some require that the changes be made together.
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.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply