I have to say I agree with the comments so far and to add I have used ORM since "InfoModeler Q" and have all Terry's books on the subject.
In a new db design I would always start with ORM but after serveral iterations I find this not to be practical because of developer skill levels and turnover. So then I have to hire a DBA who does nothing but script change integration.
For source code I have a source control system that is well integrated in the IDE and I can run reports showing who changed what & when and who has code still checked out. I can also automate the build process from the source control system
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
From: Frans Bouma <[EMAIL PROTECTED]> Reply-To: "Unmoderated discussion of advanced .NET topics." <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] OT Continous Integration Date: Wed, 21 Apr 2004 22:01:24 +0200
> I'll add to my own post that the conceptual/ORM approach is > really for the structure, and won't help with the scripts > that generate procedures, functions and such. Fundamentally, > you'd end up with one physical schema create DDL script from > an ORM or ERD tool, many sproc/function DDL scripts and one > or more "dummy data" creation mechanisms.
I'd like to add to Paul's excellent analysis that migration of already existing data has to be taken into account as well. This can give some extra problems along the way, especially when tables are split up, constraints are added/changed etc. To avoid a big misery, the more the model is finalized prior to development, the better, i.e.: the more ad-hoc changes are required, the more migration issues will pop up.
FB. -------------------------------------------------------------------- Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com My .NET Blog : http://weblogs.asp.net/FBouma Microsoft MVP (C#) --------------------------------------------------------------------
> > _________________________________ > Paul Tiseo, Systems Programmer > Research Computing Facility > Mayo Clinic Jacksonville, Griffin 371 > [EMAIL PROTECTED] > > > > > -----Original Message----- > > From: Unmoderated discussion of advanced .NET topics. > > [mailto:ADVANCED- [EMAIL PROTECTED] On Behalf Of > Tiseo, Paul > > Sent: Wednesday, April 21, 2004 2:55 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [ADVANCED-DOTNET] OT Continous Integration > > > > Curious, are you using CruiseControl or Draco? > > > > To some degree, Frans is right. Controlling the design of a (large) > > relational database at the physical level can be dangerous, > unless all > > the individuals with the right to do so know what they are > doing. If > > you pull up the edits to a more logical (ERDs) or conceptual > > (NIAM/ORM) level, then this is much better. Then, you > create scripts > > from the higher abstractions and push those generated > scripts out into > > the source control mechanism. The changed file should then trigger > > your build. However, you might not have this choice. > > > > At any rate, the end product for CI is that there should be > a master > > DDL script as part of the build process. This script (or a > collection > > thereof) is what is used to create, re-create and/or populate the > > database with data with every build. > > > > Also, look into what the "Database Project" in "Other Projects" in > > VSNET can do for you as far as collecting and managing DDL scripts. > > Here's more information than I have time to type. Now, it could be > > that you use that, or that a repository of some sort holds > the master > > DDL collection. > > > > http://www.devx.com/assets/download/5865.pdf > > > > (Be careful that the scripts are executed alphabetically in > the build, > > although there are ways to get around this.) > > > > _________________________________ > > Paul Tiseo, Systems Programmer > > Research Computing Facility > > Mayo Clinic Jacksonville, Griffin 371 > > [EMAIL PROTECTED] > > > > > > > > > -----Original Message----- > > > From: Unmoderated discussion of advanced .NET topics. > > > [mailto:ADVANCED- [EMAIL PROTECTED] On Behalf Of Gary > > > Davidson > > > Sent: Wednesday, April 21, 2004 10:54 AM > > > To: [EMAIL PROTECTED] > > > Subject: [ADVANCED-DOTNET] OT Continous Integration > > > > > > Are there any Continous Integration shops on the list? How do you > > > handle database changes? > > > > > > I am working toward having my team use continous > integration as part > > > of our move to AGILE programming methodologies. > > > > > > The one problem I can't seem to solve (i.e make everyone happy) is > > changes > > > to the database. Currently eveyone has their own local db and > > distributes > > > scripts via email and the developers don't like this and > want to all > > > develop on a "Central Database". > > > > > > I had to change from this because I was having problems > with scripts > > being > > > left out of SS and when it came time to build to > production It was a > > > nightmare of scripts and diffs and late nights and a very > pissed off > > wife. > > > > > > I am not afraid, except for the wife :) to make an SOP > and enforce > > > it, I am just looking for the best solution. > > > > > > Very soon the source build will be automated so I want to > solve the > > > db part. > > > > > > Any ideas or help will be appreciated > > > > > > Gary Davidson > > > > > > _________________________________________________________________ > > > From must-see cities to the best beaches, plan a getaway with the > > > Spring Travel Guide! > http://special.msn.com/local/springtravel.armx > > > > > > =================================== > > > 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 > > > > =================================== > > 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 > > =================================== > 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 > > > >
=================================== 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
_________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page � FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/
=================================== 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
