[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: Development testing on Production (?) servers -- was

From: Rogerio Luz
Subject: [Gnumed-devel] Re: Development testing on Production (?) servers -- was 0.3-rc4 released
Date: Mon, 18 Aug 2008 21:53:16 -0300

I think it would work, but the VM part is not such a good idea, some times the VM does not work properly, has configuration issues and crashes a lot more than the real deal...

If the DEVEL database will NEVER interfere with the production one (as Karsten suggested) I would think that there would be no problem working with both on the same live system.


2008/8/18 James Busser <address@hidden>
On 17-Aug-08, at 2:37 PM, Rogerio Luz wrote:

It will always be the same database. And if the gnumed_v27
already exists it will be deleted.
So, wouldn´t it make sense to make the devel database use diferent names than the "packaged" versions? Something like gnumed_v9-dev ?
That way it wouldn´t delete nothing and the devel database would never be seen by the "normal" client and bootstrapping procedures?

I can understand the desire for anyone who would run a production backend version of GNUmed to also want to themselves test, and be satisfied what will happen, any new version(s).

I also understand that one codebase managing 2 different installs of the same version of GNUmed on the same system would be asking for trouble.

I also understand how having to rename a backend differently and to have to cascade the changes through all the scripts could be a big headache.

I wonder whether running devel inside a Virtual machine would be the way to safely manage the duality:

- production system runs on server
- doctor hacker installs and maintains a devel version inside a VM on their personal computer
- doctor hacker can get familiar with new backend and client changes inside VM
- VM can be cloned (at no charge if Linux?) to assist other staff to learn the changes
- when satisfied, doctor hacker can load a dump of real data into their VM backend for next stage of testing
- when satisfied, production can be migrated up into new GNUmed

Client updates *within* one version of the database are, I believe, less of a problem. As long as the database has not been upgraded, misbehaviour from a new client version should still allow the doctors and staff to go back to the prior version, is that correct?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]