Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id 1CC662E004E for ; Tue, 22 Apr 2008 08:17:30 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 74327-07 for ; Tue, 22 Apr 2008 08:17:20 -0300 (ADT) X-Greylist: delayed 00:10:07.040834 by SQLgrey-1.7.5 Received: from fmailhost01.isp.att.net (fmailhost04.isp.att.net [207.115.11.54]) by developer.postgresql.org (Postfix) with ESMTP id 7DB2C2E0044 for ; Tue, 22 Apr 2008 08:17:26 -0300 (ADT) Received: from [127.0.0.1] (adsl-12-104-37.gsp.bellsouth.net[65.12.104.37]) by isp.att.net (frfwmhc04) with ESMTP id <20080422110716H04009kdeee>; Tue, 22 Apr 2008 11:07:17 +0000 X-Originating-IP: [65.12.104.37] Message-ID: <480DC668.8080901@reedyriver.com> Date: Tue, 22 Apr 2008 07:05:12 -0400 From: "H. Hall" User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: postgresql-admin Subject: Re: Dev Process References: <8078a1730804181152m199faeb5j47efa7c72a9571c7@mail.gmail.com> In-Reply-To: <8078a1730804181152m199faeb5j47efa7c72a9571c7@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200804/221 X-Sequence-Number: 28985 Medi Montaseri wrote: > Hi, > > I was wondering if you could critique the following DB application > development process. > > Given a production DB and a Dev DB: > 1- Develope schema and code on Dev including test data which will > impact sequences, etc > 2- Dump the schema only (not the data) from Dev and restore it into > the production DB > 3- Populate DB with real data, usage begins > 4- Enhancement to schema on Dev DB including unit testing again with > impact on sequences > 5- Dump schema and move to production > 6- Goto 4 > > Thanks > Medi > > The first problem is that you will have to take the production DB down to update it. Another problem with this method is that if you encounter problems while restoring data, then the down time could extend farther than your plan. Problems reloading the data can arise from new constraints etc. Finally, you should consider testing the application program(s) as part of your update process. A better plan might be to: - Use only script files to update the dev server and use the same script files to update the test server (described below) and the production server. - Keep a log of changes to the dev and production servers. This shows when the script files were run on each server and gives you a quick view of the state of each. - Use a third server, a test server to test the update prior to updating the production server. The test server schema should be at the same state as the production server, prior to the update. Update the test server using the script files and test your applications against it. Then update the db server. The log let's you see what needs to be done. Use of the script files gives you the repeatability you need. Updating the test server first gives you the validation you need without the heart attacks. The test server can be very light, i.e. anything that will run postgres. --cheers HH H. Hall ReedyRiver Group LLC site: reedyriver.com