How can I effectively migrate changes made to ERP Next 15 from a development server (named ‘45’) to a production server (named ‘30’) without affecting existing data?
In the development environment (server ‘45’), I’m making modifications to ERP Next 15 using the “edit doctypes” and “add doctypes” features. These changes are stored in a backup file format like “20240305_174638-aalamerp_com-database.sql.gz”, alongside mock data created during development.
However, when attempting to transfer these changes to the production server (‘30’), I encounter challenges. The database file containing the changes also includes mock data, making it difficult to isolate and apply only the necessary modifications without affecting existing production data. Additionally, when I restore the backed-up database from development and restore it in production, the data in the development environment appears in the production environment, overriding the existing production data.
How can I ensure that only the changes made in the development environment are transferred to the production server without impacting existing data? Additionally, how can I prevent the transfer of mock data and ensure that the production server retains its existing data?
For “portable” development, you don’t need what’s in the database. You should not edit core docTypes. You can edit docTypes created in your custom app.
To make your custom app installable it best to use a service like GitHub to push your changes.
Technically you should be able to creat the apps on your dev server and rsync the file system folders (after creating the skeleton app on prod. After sync files run bench build and bench migrate.
If you have changes in the database (customized docTypes) you can export them to a custom app to make them portable.
You are confusing with Logical development with Database data. Do not edit standard doctypes of any standard Apps like ERPNext, Frappe etc.
First, create your custom app in bench using bench new-app custom_app_name. Always customize standard doctypes. As you keep on customizing the doctypes there is Action button under which you will find Export Customization. Click on it and it will ask to select module for export. Select your custom_app_name which is created earlier. Also follow same process even if you want customize standard child tables. All such exported changes are stored in bench/apps/custom_app_name/custom_app_name/custom_module/custom.
Second, when you want to create your own doctype then it asks you to select module for your doctype. Never select module of any standard apps. Here select your custom app’s module name. This will create metadata, boiler plate for your doctype in your custom app. Always edit doctypes which are created by you and do not customize it. You can customize it, but you have to always keep exporting the changes which is not recommended for developmental sanity.
Now about code. If you want to code for your custom doctypes then there are .js and .py files in doctypes directory of your custom app, add code here. If you want to write server side code for standard doctypes then you can create specific directory in your custom app to store all server side codes and use hooks.py to hook all necessary functions from your server codes. And if want to write client side codes then store it in apps/custom_app/custom_app/ public/js directory. For this you can read frappe documentation under Frappe hooks.
To move all your implementation-customizations, custom doctypes, codes attach git to your custom app and push all changes from dev server to github and pull these changes in production server.
Now the confusion related to backup file .sql. This file only contains records created in various doctypes. This file does not contain your UI modifications made in doctypes. So when you restore database backup file from dev server to prod server, it will definitely overwrite production data. Never ever restore database backup of dev server to prod server.