Implementation Architecture

I’m unclear from the docs (or the lack of docs) what the appropriate architecture is for creating new DocTypes and using them. Is the idea that I should be deploying my own Python package? Or, should I be adding DocTypes from the global menu?

For example, I added (from the global menu) a DocType “product”. I’d like to sync this product with my e-commerce store. Should this be done in the web gui? Should it have been done in code?

Ultimately, I’m unclear on where the “source of truth” lives. I guess it’s the Maria database. But, should I also have the schema mapped out using sqlalchemy code?

Then, I’m a bit stuck on how I actually make use of this new DocType. Do I need to create a form? And, do I need to create a background job? Links or long explanations welcome :slight_smile:

Alright. Made a bit of progress on getting it installed on my computer. Beside being a bit surprised that erpnext is still using py27, I followed this guide:

and got around what appears to be a bug install erpnext with this: Connect to Erpnext development from console - #6 by hereabdulla

What still remains is: what should I be deploying? Is it safe to just commit the template-maufactured frappe-bench to git, (change the database for production), and pull it down on a server?

Just commit your app to git, not the entire bench. If you have made a new app, you’ll have initialize a new git repository app’s folder, then commit and push the changes to a remote repository.

OK – so it’s then “frappe apps” that are version controlled. In order to move an implementation from dev → staging → production (again, an implementation), would that require fresh implementations for each? mysqldumps?

The piece I’m missing is “what is a good workflow for building an ERP for my business”.

Thanks @gvrvnk

Developer environment will have bench with a site, with erpnext and custom app installed on it.

The same steps will have to be followed for setting up the staging and production environments.

The developer would add custom fields, property setters locally as part of the custom app, export them as fixtures and push them to the app’s repository.

These can be pulled onto the staging server via a bench update or a git pull + bench migrate

All apps on the production server will on the master branch, and each can be pulled from their respective repositories, just like on the staging server.