### Problem Given we use a combination of Rails credentials and Environment variables to store configs, we can potentially retire `secrets.yml.example` and replace it's content with `secrets.yml` and check the file in the repository. In general, `secrets.yml` could follow the pattern to first check if an environment variable exists, and default to Rails credentials if not present (which is already done today to a large extent in [`secrets.yml.example`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/7128c17a1416f7b4cb48a2508258345d6e4a2ba6/config/secrets.yml.example#L16)). Every instance sets any overrides in `.env` file. Here are some analysis on the approach: | Current problem | New approach | |-----------------|--------------| | Some developer instances may have overrides set in `secrets.yml` and may not use default Rails credentials. This is a common problem when a config does not seem to become effective | Ensures all instances (developer, staging, production) have consistent settings. All overrides for an instance exist in one place (`.env` file) | | When new secret variables are introduced, developers have to manually add this to `secrets.yml` (see [related issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/7113)) | New variables are automatically included in an instance without manual intervention | :warning: To evaluate if this could have an impact on how ansible sets secret configs. Slightly related: we can also encourage use of `.env` instead of setting application-related config overrides in `.zshrc` ### Proposal ### Result Organized secrets management.