From 8edfe383e3e6d9b4eefa2a12ebbf02cce51098d9 Mon Sep 17 00:00:00 2001 From: steffeydev Date: Fri, 10 Jan 2025 22:10:15 +0000 Subject: [PATCH] Add [RFC] Development & Deployment Process for Brotherton --- ...D-Development-%26-Deployment-Process-for-Brotherton.md | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 %5BRFC%5D-Development-%26-Deployment-Process-for-Brotherton.md diff --git a/%5BRFC%5D-Development-%26-Deployment-Process-for-Brotherton.md b/%5BRFC%5D-Development-%26-Deployment-Process-for-Brotherton.md new file mode 100644 index 0000000..a67a658 --- /dev/null +++ b/%5BRFC%5D-Development-%26-Deployment-Process-for-Brotherton.md @@ -0,0 +1,8 @@ +Here is what I think is the best approach, given the current timeline: +- 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