[Gnumed-devel] Development testing on Production (?) servers -- was 0.3-rc4 released

[James Busser]

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?