| Database change/release management [message #296111] |
Thu, 24 January 2008 11:27  |
jhinds
Messages: 4
Registered: December 2007
Location: United States
|
Junior Member |
|
|
Hello all,
Longtime lurker, first time poster. I would like to gather some information about
how we all handle change/release management of database code - more focus on the
release management side of things. First of all, let me give you a brief explanation
of how we do this at my current employer.
1) Database developer receives change request.
2) Developer implements change and unit/integration tests - hopefully  .
3) Code is packaged and submitted to a QA environment and tested.
4) After successful QA testing, code is submitted to a client test region (can
be an internal or external client).
5) Client provides acceptance sign-off and requests move to production.
6) Production install is scheduled and implemented - developers have to be present
to perform a checkout.
Obviously this is pretty high level - there is a bit more going on but this covers
the basics. This is an ASP environment and we have code that we write for Oracle
10g, SQL Server 2000/2005, MySQL, and PostgreSQL - all follow the same basic release
process.
So now I am curious how similiar/dissimilar this process is to how you handle
release management. Does anyone automate the release to the production
environment? Much of the reasoning behind requesting this information is that
we are considering a move to a more automated system for deployment to production.
We often have several production deployments a week - most, but not all, include
a database of some sort - and with most of our clients being 24/7, we do most
production deployments late night/early morning. With the production deployment
team and developers, that can be as many as a dozen individuals having to come in
to support the deployment. How does your release process compare? Feel free
to take shots at how we do it - I am not saying it's wrong or right, it's just
how it is currently done.
Also, if anyone knows of a good resource that is specific to database change/release
processes, please point me to it. Appreciate your comments!
Jason
|
|
|
|
| Re: Database change/release management [message #296114 is a reply to message #296111] |
Thu, 24 January 2008 12:03  |
MarcL
Messages: 455
Registered: November 2006
Location: Connecticut, USA
|
Senior Member |
|
|
You're steps 1-5 are basically what is done in our shop.
Here are some deviations.
Once the developer exports the objects for QA testing, he is out of the loop other than bug fixes back on the development database, and then a re-packaging of the entire patchset.
Also, the script that we deliver, is all encompassing and is run by the client that we are delivering to.
So unless there are issues during the patch application, there is no involvement at all from our team.
|
|
|
|
| Re: Database change/release management [message #296117 is a reply to message #296114] |
Thu, 24 January 2008 12:33 |
jhinds
Messages: 4
Registered: December 2007
Location: United States
|
Junior Member |
|
|
| MarcL wrote on Thu, 24 January 2008 11:03 |
Once the developer exports the objects for QA testing, he is out of the loop other than bug fixes back on the development database, and then a re-packaging of the entire patchset.
|
So, just for clarification, if an issue is found by the client after deployment, who owns the support/troubleshooting of that issue? Is it the production DBA? Is the original developer sourced at all in the support process. Thanks for your comments.
Jason
|
|
|
|
| Re: Database change/release management [message #296119 is a reply to message #296111] |
Thu, 24 January 2008 12:40 |
jhinds
Messages: 4
Registered: December 2007
Location: United States
|
Junior Member |
|
|
Another question to add to the mix - how do all of you handle the backing out of database code.
Do you restore a backup of the database, are your developers required to create a rollback script or do you have some other process? Thanks.
Jason
|
|
|
|
| Re: Database change/release management [message #296123 is a reply to message #296117] |
Thu, 24 January 2008 13:47 |
MarcL
Messages: 455
Registered: November 2006
Location: Connecticut, USA
|
Senior Member |
|
|
If an issue is found after deployment, then the ownership of the issue depends on the nature of the problem.
But generally if re-work is needed, unless it is a production down situation, we would do the rework in development and go through the entire deployment cycle again for the changes.
As far as backing out of code, again that is dependent on the nature of the changes, but we use version management software (Subversion in our case), to control and track changes, so we can go back to a point in time before the patch.
The issue can be if there are data issues that need to be rolled back, this unfortunately is not such a simple process unless the customer is willing to go to a restored copy of the database (highly unlikely unless the problem is found immediately).
But, once both the customer and our Analyst have signed off on one of the customer QA instances, which is restored on a fairly regular basis from production, any further requests are handled as change orders, and not rework of the original request.
|
|
|
|
| Database change/release management [message #296288 is a reply to message #296123] |
Fri, 25 January 2008 10:22 |
jhinds
Messages: 4
Registered: December 2007
Location: United States
|
Junior Member |
|
|
Does anyone automate part or all of the rollout of database code? Just curious to see if automation is a part of your process, how much is automated and how successful that process has been. Thanks for your comments.
Jason
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
