We currently manage app-specific settings, such as RELEASE_ROLLOUT_PERCENTAGE, BETA_APPLICATION_ID, and RELEASE_APPLICATION_ID, directly within the init_worker.sh file. As we introduce new applications, we continue adding more entries, deviating from the purpose of this file.
We should consider a different approach for handling these settings. Potential solutions include:
-
From Task Payload:
Pass application-specific configurations through the task payload, keeping the logic inside pushmsix simpler, and making the requesting app more explicit on what's being pushed.
-
Constants/Configuration File:
Store all app-specific constants in a dedicated configuration file (similar to existing patterns in beetmover, iscript, etc). This file would serve as a centralized reference point, making updates and additions easier.
Open Questions:
- Which approach integrates best with our existing deployment and operational workflows?
- Are there additional options/strategies for handling these settings?
We currently manage app-specific settings, such as
RELEASE_ROLLOUT_PERCENTAGE,BETA_APPLICATION_ID, andRELEASE_APPLICATION_ID, directly within theinit_worker.shfile. As we introduce new applications, we continue adding more entries, deviating from the purpose of this file.We should consider a different approach for handling these settings. Potential solutions include:
From Task Payload:
Pass application-specific configurations through the task payload, keeping the logic inside pushmsix simpler, and making the requesting app more explicit on what's being pushed.
Constants/Configuration File:
Store all app-specific constants in a dedicated configuration file (similar to existing patterns in beetmover, iscript, etc). This file would serve as a centralized reference point, making updates and additions easier.
Open Questions: