As runnable application component, I should verify and access to environment variables in a safe way to collaborate with other resources/infrastructure systems

[olivierlemee]

• implementation of reusable generic class (WriteModelConfigurationVariable, ReadModelConfigurationVariable) by application context (e.g redis adapter) which manage the find/access of properties specific to the current runtime
  • Avoid usage of Maven profile in application (e.g put documentation to doc about usage of environment variable and context utility class)
  • generic HealthyOperableComponentChecker and ExecutableComponentChecker about environment variables management
• add unit test per application component (ExecutableAdapterCheckerUseCaseTest for UIS adapter impl) about all defined value of all resources to avoid missing by java developers between a value called dynamically by a java code via the Checker class
• all the settings that are variable for a java component should be managed/defined/changeable only at the infrastructure layer and accessible dynamically without any change/rebuild of java component that is stateless > over Environment Variables
• check class verifying (by default constructor) that all variables required by the component are defined (Context.get(IReadableConfiguration config) method ) currently in the system instance (e.g if Infrastructure-as-Code missed to defined value in Docker/Helm/Terraform codes) which can be call anytime by a bounded context adapter to manage a waiting time for operator to define/change the environment variable in the current instance through his administration tool. Example of auto verification by adapter (UISAdapterImpl).
• Implementation of automatic variable types and valued existing (ExecutableAdapterChecker for UIS adapter, ExecutableBackendChecker for reactive-messaging-gateway) in the current started java app (ExecutableBackendChecker of Reactive messaging gateway)
• environment variables (e.g url to middleware) managed via helm/terraform (see Helm variable environment setting on https://phoenixnap.com/kb/helm-environment-variables) relative to running environment allowing dynamic change (e.g via JMX or via OS/docker instance access via secure/dedicated configuration/administration system)
  • setting via Helm when building the containerized backend + test of redeployment into Kubernetes

[olivierlemee]

coding of unit test regarding starting (with ExecutableBackendChecker) of Reactive messaging gateway allowing the read of 8080 http port from env variable

[olivierlemee]

definition of environment variable into the Values.yaml Helm file allowing auto-start of docker image with initialized variable reused by the java application auto-check process > test ok as operational started java application