Shiloh/frappe_docker
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update [RFC] Development & Deployment Process for Brotherton

steffeydev 2025-01-11 17:44:12 +00:00
parent 053beb6c20
commit 1bcbfd754d
2 changed files with 12 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
%5BRFC%5D-Development-%26-Deployment-Process-for-Brotherton.md Normal file

@ -0,0 +1,12 @@
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 apply 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.

8
%5BWIP%5D-%5BRFC%5D-Development-%26-Deployment-Process-for-Brotherton.md

@ -1,8 +0,0 @@
Here is what I think is the best approach, given the current timeline. Please comment your thoughts below.
- If confident, make changes directly in prod UI
- If not confident, make changes in staging UI, then test, then make same changes in prod UI
- If change is not supported in UI, then make change at framework level, re-generate custom image, and deploy on staging/prod
- We can either make the change directly to the framework, or we can update the framework to support making the changes we need in the UI, then make changes in the UI
- When needed, make a backup of prod DB and restore it into the staging env
- We can do this manually to start as needed, but check with other developers first to make sure they are ok with staging-specific changes being wiped
- Eventually we could automate doing this nightly, but need to be careful not to accidentally undo any multi-day projects we are trying in staging env