frappe_docker

Table of Contents

Building custom images

Frappe Framework has two types of doctypes/fields: custom and not custom. custom doctypes are specific to a given client, while non-custom (built-in) are generic and applicable to many clients. For doctypes, this is specified by the Custom? checkbox when creating the doctype. For fields inside a doctype, this is specified by if the field starts with custom_. custom doctypes and fields are saved only to the database, while non-custom are saved to the filesystem. You can only make non-custom changes when in Dev mode. Once you are in Dev mode, any non-custom UI changes you make are mirrored to the filesystem, and should be source controlled.

For each change, we must decide if it is specific to this one client, or more general, such that we would want it to apply to all clients. Client-specific changes are custom and should be done through the UI. If you are unsure if a change is client-specific, treat it like client-specific for now, and if we find another client later that wants the same change, we can abstract it then. Most changes should be client-specific / custom.

Sometimes, client-specific changes will need to be made in the source code if the UI does not support making that sort of change. If possible, we should update the source code in a generic way that then allows us to use the UI to make the client-specific change.

Client-specific changes should be made first on the staging server, tested, then made again on the production server.
General changes should be done from your local dev environment in Dev mode, then committed into source control. After a change is made to the source code, we will need to rebuild the custom image and restart staging and prod.

Each developer should have their own accounts in staging and prod, so that changes can be tracked back to the developer for accountability. All changes made by "Administrator" can be assumed to have been done by Landry. Going forward, the Administrator account should only be used for provisioning other accounts.

Before we switch to this new process, we should backup the prod database and restore it to staging, so that they start in the same place. Then, as long as we make custom changes to staging first, staging should always be equal to or ahead of prod.

Building custom images

Edit build.sh in the repo root and change the TAG variable
Run ./build.sh (you have to login to githaven.org with docker if you haven't already before this will work)
Then edit the compose file to use the new tag on staging/prod and restart. If changing version, you'll need to run bench --site <site> clear-cache