Not quite sure about how to phrase the question - but I am trying to work out the best development architecture to ensure that we have a robust framework that protects the production environment.
We have a production server running servoy server + SQL server. It runs just fine and the repository DB holds the solution. The other DBs hold real user data. I have servoy developer on my workstation that points to the repository on the server. (ie uses the jdbc connector to point at the real databases in the SQL server).
Now I can check out the solution to my local dev box - modify, and then commit back to the repository. That all works just fine BUT I am working with the real Dbs - which is a significant risk. I dont want to stuff the real data while I am developing
I could make copies of the DBs - but then of course the connectors would be different betwen the dev environment and the prod environment. Is this the way to go? Can someone either point me at a white paper/howto or describe in simple terms how to setup/use servoy in a dev->test->prod architecture?
Is there a best-practise guide anywhere?
Thanks
Al
alb:
I could make copies of the DBs - but then of course the connectors would be different betwen the dev environment and the prod environment. Is this the way to go? Can someone either point me at a white paper/howto or describe in simple terms how to setup/use servoy in a dev->test->prod architecture?
First of all your situation might dictate what the ‘best practice’ might be.
Also what do you mean with the “connectors would be different between the dev environment and the prod environment”. Sure the databases are different but the connection name stays the same. This is JDBC/ODBC 1on1. You can use the same connection name but use a completely different database at the back end, completely different server even.
I think the general- or best practice is this:
developers that have their own workspace and connect to a development or local database for their test-data
test Servoy server that connects to a test repository database and test-data database. This to test the multi-client environment.
deployment environment where you have Servoy server connect to all production databases.
Some developers might skip the second step. But again, this all depends on your situation.
thanks for the reply - i think i am clearer now…problem was I was thinking that the databse connection info was in the repository db…which of course its not
Al.
one final clarification - in the scenario you have outlined are the dev test and prod repositories different dbs?
I get that the data dbs are.
just wondering how the machanics of the developer changing the solution within the dev repository - then pushing that into the test/prod repository…do they use solutuion export/import?
how does this interrelate (if at all) with the ‘versioning’ capability available through the server admin pages?
alb:
one final clarification - in the scenario you have outlined are the dev test and prod repositories different dbs?
I get that the data dbs are.
Correct. The test-server uses it’s own repository database.
alb:
just wondering how the machanics of the developer changing the solution within the dev repository - then pushing that into the test/prod repository…do they use solutuion export/import?
Correct. It’s best practice to import the solution through the servoy-admin pages. This way you don’t have to restart the Servoy server to see the changes.
alb:
how does this interrelate (if at all) with the ‘versioning’ capability available through the server admin pages?
Each repository (including a repository like Subversion) keeps track of it’s own version numbering.