SQL Server Performance Forum – Threads Archive

How other companies handles Schema Change Request

I’m trying to gather some information on how other organizations handle Schema Change Request from developers during the development cycle. For example, week 1 you start at build 10 and during the week you add 2 new tables and 2 new fks. So these are coded and check into change control for now week 2 comes along and build 11 is now complete that included the 2 new tables and 2 new fks from the week before. The development team upgrades their environment from build 10 to build 11 to include the latest changes. Our process is:
1. – that we request developers to submit a form that tells us if they are adding a new table or adding new fields, adding/changing indexes, and foreign keys to an existing/new table.
2. – then we check out the sql scripts from change control, modify/add the sql code, check the sql script back into change control.
3. – We then place the form submitted by the developer out on a share on the network so the env. folks can have documentation to the sql change.
4. – Then weekly a build is conducted with the latest change control code. Each development team conducts weekly builds to get the latest changes. The form is manually emailed to us and then we manually update/add the sql scripts. The builds are all done automatically. I wondering how other folks handle changes/documentation when developers request schema changes to see if we can be more efficient. I appriciate any feedback.
Chuck

Haven’t worked much with this but if I was going to I would probably start by taking a look at Bill Wunder’s DDL Archive Utility:
http://home.comcast.net/~b.wunder/
http://home.comcast.net/~b.wunder/16408.htm

thanks Argyle i’ll check out the links. I’m just wondering if other companies use a manual submission of a schema form of some type to keep track of requested changes between version release. I’m always looking for ways to improve or automate our process. Especially for the development teams that just want the new fields/tables without filling out forms. Thanks for the feedback.
Chuck

At our end the process is controlled using a inhouse developed application where Developers will provide the required information with valid business justifiation and later the code is managed using Visual Source Safe by integrating the required changes. A piece of suggestion :
– If there is any major changes like database schema change and changes in public methods of your classes which are used by other developers, it can be immediately passed on to other team members. So, you won’t hear the complaint "if you had told me earlier about this change, I need not have wasted so much time. Now I have to re write my code due to your changes." – It is very important for any project to follow certain standards. There is no need to strictly follow some standards provided by others. – Weekly code review meeting. – Build and test your software at regular intervals of time and make sure it still works as expected. The common steps involved with our process is in continuous integration process are:
– Use source control to manage source code.
– Automate the build process so that build happens automatically at regular intervals of time.
– Automate the testing so that you can run a suite of tests on the system at any time.
– Save the executables of the system with version numbers, so that anyone can go back and get a copy of the application executables of any version.
Satya SKJ
Moderator
http://www.SQL-Server-Performance.Com/forum
This posting is provided â€œAS ISâ€ with no rights for the sake of knowledge sharing.

]]>