My 2 cents: cut out the Nke syndrome. -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Sami Vaaraniemi Sent: Thursday, April 22, 2004 2:26 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] OT Continous Integration
On Wed, 21 Apr 2004 16:36:51 -0400, Gary Davidson <[EMAIL PROTECTED]> wrote: >The db is a different story. A developer opens enterprise mgr and makes >a quick change and then "forgets" to notify anyone of the change >script. We don't find out until the build or someone happens to do a >get latest and steps on that code. Then it turn in to a finger pointing >discussion with the >developers wanting some magic "process" to fix it. They blame lack of >process and I say they aren't following the process we have. > >I guess it is the human element I am trying to factor out. I am trying >to automate the process for db development builds and find the >integration errors sooner. > >Maybe "That dog just won't hunt". > >Gary Davidson Gary, You should really make the database building part of the build process, and make it a rule that no-one modifies the database outside of the build process. This is what we do: We have a set of SQL script files that create the database from scratch. One creates the schema, one adds initial data, and another one adds test data. These scripts are in the source control. We have a nant script that drives the build process. The full build begins by checking out all the sources from source control, it runs the SQL scripts to build the database, it then compiles the sources and finally runs unit tests. At the end the developer has the complete system locally on his/her dev machine. If I need to change a schema, I do the changes locally on my dev machine usually through Visio. I first reverse-engineer the current schema, do the changes and have Visio output a script that incrementally applies the changes to the database. I then check this script into the build system. This way all developers get the changes the next time they check out and run the build. The tool used to make the changes does not really matter as long as the end result is an SQL script that incrementally updates the schema. After the changes have been applied to production using the incremental script, these statements become part of the master SQL script that creates the schema. This system has worked pretty well for us for small/medium sized projects. Regards, Sami =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
