We are running ERPNext in house on our own VM server. So we have some options to clone the production VM, but then some things need to be changed to point to dev.erp.local instead of prod.erp.local on the configuration.
I am just wondering if there is a standard or best practice way to maintain a production and development environment for ERPnext so that you are not attempting configuration tests on the live production server.
I’m sure many people here with PRODUCTION environments have a QA/TEST environment and they are not testing their erpnext configuration changes in the their live production environment.
I am just asking what is your process for keeping your production and qa/test/dev environments somewhat in sync? And what needs to be changed configuration wise for frappe/erpnext so that you can have
I assume someone is using ERPNEXT in production environments?
Can anyone share your process for maintaining development and production environments?
How do you maintain similar or synchornized-to-production dev environment?
How do you move approved configuration changes from Development to Production?
I’m getting to the point where I may release some very basic things in production, which means all of my “Testing” will stop in that environmnet. Any tips would be appreciated.
I have the exact need, the only difference is that I’m running my environments on docker containers.
Did you find the answer?
or someone can solve this mystery, please!
The easiest way to move between two servers is via backups. Dump the backup from your source server, and load into your target server. If you’re doing this frequently, it’s relatively easy to automate with shell scripts.
You can deploy multibench environment, one bench for develop and one bench for production, and connect both via github repositories.
Each bench can run different versions of frappe/erpnext/apps , and different sites at time.
I am not an expert, but I think multibench is a pretty “unknown” technique which give you many posibilities. Maybe there are a “dead body in the suitcase” that i didn’t found yet.
I don’t know how that will help?
Since they’re two separate benches, they most likely have their separate data and settings.
The only advantage that I can see from that approach is to limit the resources to a single server and a single database! Or did I miss something?
Sharing database for production and development enviroments sounds pretty dangerous for me… Anyway, you can connect development environment to the production database if you want … modifying site configuration. You can even host db externally …
Running both environments on the same server have pros and cons. It’s easy to manage in my case.