OperationCode / operationcode_backend

This is the backend repo for the Operation Code website
https://operationcode.org
MIT License
62 stars 110 forks source link

Require evaluation of environment variable values #381

Closed ohaiwalt closed 5 years ago

ohaiwalt commented 6 years ago

Problem

The backend is running in production with a set of environment variables that represent access keys and API tokens for various services we use. Historically there were only local development and production environments supported, but as we're trying to have a staging environment in https://github.com/OperationCode/operationcode_infra/issues/40 an evaluation of each of these variables and whether there will be unintended consequences for including them in a non-production environment is necessary.

The list of environment variables present in production can be found here: https://github.com/OperationCode/operationcode_infra/blob/master/kubernetes/operationcode_backend/deployment.yml#L19-L85

Due to the sensitive nature of some of the values, I won't list them here, but they can be found running live in production for those with access.

Definition of done

Set of environment variables to include in staging, as whether the production value is acceptable. If not, what is an acceptable value?

apex-omontgomery commented 6 years ago

I submitted a list to Matthew of the variables I think are important, his response was Matthew: what will the application do without an appropriate variable in place?

This is on my list to do this weekend, so we can unblock staging.

apex-omontgomery commented 6 years ago

At first we don't want to worry about:

  1. Emails (so just not send them)
  2. The various rake tasks that aren't running (github, meetup)
  3. Slack connections that are disconnected
  4. Performance monitoring but that would be nice to have in the future for staging

Per @kylemh these items are important: I need an environment with an API so that I can simply point to staging when in local development and not affect prod api

  1. We need a database with fake data that won't pollute our real database
  2. Redis keys for the background queue - Most of the jobs that would be added to a queue we don't want to perform in staging (for now), but the errors from having a missing queue are frustrating to slog through
  3. For the mentor request form we write to airtable, this is optional but something that will be tested in FE in the near future. I can get a test api key for this from the test airtable.

As far as what to include for the values that aren't real I'm not sure if we should just fail to include them, or if we should include a fake value.

apex-omontgomery commented 5 years ago

Closing this as the values have been given to @nellshamrell and the work is in place to modify infra repo.