# Properties/configuration

properties is file containing a set of key value mappings (in different formats ie json/yaml/properties) that are constants used in the app for specific environments (ie same keys but different values for different environments)

## Types of properties

* deployment
  * These are necessary to start the application up
    * ie java options, which env to deploy to
  * They can also be used as a precondition before startup.
    * if not set or are wrong, then application cannot startup (obvisouly should be done before it gets to deployment)
* startup
  * These are needed for the app to run, after being deployed.
  * If they are not there then the application cannot do it's tasks
  * ie database properties
* In life properties
  * These properties can be changed throughout the lifecycle/running of the application
  * ie 3rd party url, toggles, certificates
* Secrets
  * These are generally things like passwords, usernames, tokens, private keys
  * They need to be encrypted when saved or stored anywhere (ie db/git), but upon deployment or usage needs to be decrypted
    * Either by the devs or someone with clearance
  * Generally decrypted on the environment/server, so the application can use them to function
    * This means they should never be shown in logs (or at least obfuscated), accessed by some user via the application (ie endpoint)
  * These secrets will generally have self life where they become out of date and need to be replaced (ie encrypted and stored)
* Local properties
  * these are a file which is a combination of all the above.
  * Where the property file is used by the app when done on a local environment ie dev computer, minikube etc
    * They can also be used when running the build ie all the tests, or running a test, or running the app via the main method, or docker container
  * Secrets would not be encrypted, unless decryption happens in the app (but this is not a good idea as the decryption key would need to be in the app)

## Property manager

* applications which manage the properties
* Use during the phases of the application (deployment, startup and inlife)
* Do not need to go through whole software process, ie change code
  * They are dynamic changes
  * The application will have system to call or listen for changes in the the PM and apply them ie for inlife properties
* Non developers can change it
  * Secruity reasons ie changing production passwords/certs, should be done by as few people as possible
* Can have properties passed in at time of deployment
  * the deployment system ie kubernetes, will pass in the properties at deployment and startup
* drawback
  * Not versioned control, lack of audits on who did what and hard to roll back
    * although this can be implemented
  * Properties changed while the application is running, may be reverted on the deployment of a new version of the application and thus lost
    * Need to remember to add these to the permenant property file for future versions
    * although the dynamic property might have been short lived, and not needed permenantly
  * Another DSL to learn

## Secret Management

* Vault

## Other

* Can separate CI and CD
  * When CI is complete a binary/jar/image is versioned and produced
  * The CD is configured with the version of the app which is ready to be deployed
  * The CD can now deploy to different environments (with different properties settings) independently instead of deploying in a set order (ie CI->test -> stage -> prod)
  * So we can do a release/deployment to prod with just changes to inlife properties to a version already in prod

## Separating properties from app in different projects

* stop deploying full app and only properties

## Other

* Use of environment variables in properties ie local database url

## Links

* <https://docs.oracle.com/javase/tutorial/essential/environment/properties.html>