February 13, 2003 at 9:24 am
Has anyone else had any experience with this problem.
We have an application that, depending on the user logged in, will connect to a different database which has identical data structures, procedures, UDFs, etc. Each database effectively holds data for a different company within our umberella, and the reason that they are kept separate is so that no one company can inadvertently see data for another company. Also, whilst the companies have identical administration and processes at present, they may diverse, their data may move to another SQL server and go off-site, etc.
The problem that we have is that one or more developers could well end up working on the same stored procedure but within different databases to comply with a change for that company. Usually this code change will then apply to all companies, so as each developer finished and tests their changes, they have to be rolled out to all databases in the QA and live environments.
A problem occurs when two developers have made changes to the same stored procedure but in different databases. When the changes are implemented, the two stored procedure changes have to be checked, merged and tested to ensure that the code for one isn't going to upset the code for another.
This is further complicated when a procedure changes the way it works specifically for one company, and a bug-fix is later implemented for that stored procedure across all databases. Great care has to be excercised to ensure that the changes are made manually as opposed to simply scripting the procedure out and running it against all databases.
This is turning into an administrative nightmare for both ourselves and the development team.
If anyone else has had experience with this kind of scenario and has found a workable solution (bearing in mind that the developers will not maintain a system if it requires effort (such as updating an 'I am working on this procedure' web page or project planner, and will try and publish code live themselves if they can find a way to do it), then we'd be extremely grateful to hear it.
Hope this all made sense.
---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
February 13, 2003 at 10:28 am
If you want to maintain a single code base, then you ahve to do that. You need a standard projcet in CVS/VSS/PVCS/whatever from which people check out code and work on it.
Personally I'd follow my same process (Part4 - links to other parts - http://qa.sqlservercentral.com/columnists/sjones/vcspart4.asp), but once a procedure was changed, I'd branch it to the specific db project to which is applies. Then continue to branch it as I rolled it out to other dbs.
There's no way to get around this. It's the same problem coding in C, VB, whatever. If there are multiple code bases and you want to allow concurrent development, you need to either deal with the merges or have a single source of "data" or code from which everyone works on. That doesn't mean that all the production code bases are the same at a point in time, but they all spring from or inherit from the same spot.
Steve Jones
http://qa.sqlservercentral.com/columnists/sjones
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
February 14, 2003 at 2:43 am
Many thanks for pointing me to the article.
It basically confirms the thoughts and plan that I've been putting together.
My biggest problem is going to be that fact that the IT department has grown over the past few years from 1 person to a team of 10. There was huge resistance within the team to networking splitting off from development and restricting access to what could and couldn't be done on the network.
Now I'm going to face the same problem with preventing the developers access to the QA and Production servers (both IIS and SQL). So far they have had the freedom to publish live what they have wanted and when, and even though this has caused problems in the past when someone hasn't been careful, they will still regard it as being treated like children. Unfortunately we are now at a size within the department and the company, and the way that we are developing, that it has to be done.
Many thanks for the article and the comments. Sometimes it's just good to know I'm not the only one with these problems 🙂
---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
February 14, 2003 at 7:58 am
I've got a similar situation, both in terms of databases=clients and a need for better change control, plus a way to control deployment. I've looked at Steve's system and I know it works for him, I just dont think I like it (sorry Steve!). Think we're going to write our own, have part done, thinking part of it through.
Andy
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply