Skip to main content
removed development-environment tag per https://devops.meta.stackexchange.com/questions/315/burninate-development-environment/316
Link
jayhendren
  • 3k
  • 8
  • 15
Bumped by Community user
Bumped by Community user
Bumped by Community user
Bumped by Community user
spelling; edited tags
Source Link
Jiri Klouda
  • 5.8k
  • 1
  • 21
  • 54

Environment variable names, when my development environmentalenvironment has multiple projects.

The context is that I'm looking at doing staging/testing and production on a kubernetes cluster.

Where I might have some code that looks like this:

doSomething({
  username: process.env.DB_USERNAME,
  password: process.env.DB_PASSWORD
})

For my various kubernetes environments, this isn't going to be a problem, as I those environment variables can be set specifically for the environment.

However, for my development environment, there's a good chance that I'm going to have multiple projects, (or even different images for the same project) that all have a environment variable named DB_URL.

One solution would be to just prefix all environment variables with MY_APPLICATION_NAME_.

Another would be not permanently set environment environment variables, but instead to just call a script that sets them when needed. But that sounds a little messy.

I'm wondering if there's a well established way that deals with this problem.

Environment variable names, when my development environmental has multiple projects.

The context is that I'm looking at doing staging/testing and production on a kubernetes cluster.

Where I might have some code that looks like this:

doSomething({
  username: process.env.DB_USERNAME,
  password: process.env.DB_PASSWORD
})

For my various kubernetes environments, this isn't going to be a problem, as I those environment variables can be set specifically for the environment.

However, for my development environment, there's a good chance that I'm going to have multiple projects, (or even different images for the same project) that all have a environment variable named DB_URL.

One solution would be to just prefix all environment variables with MY_APPLICATION_NAME_.

Another would be not permanently set environment environment variables, but instead to just call a script that sets them when needed. But that sounds a little messy.

I'm wondering if there's a well established way that deals with this problem.

Environment variable names, when my development environment has multiple projects

The context is that I'm looking at doing staging/testing and production on a kubernetes cluster.

Where I might have some code that looks like this:

doSomething({
  username: process.env.DB_USERNAME,
  password: process.env.DB_PASSWORD
})

For my various kubernetes environments, this isn't going to be a problem, as those environment variables can be set specifically for the environment.

However, for my development environment, there's a good chance that I'm going to have multiple projects, (or even different images for the same project) that all have a environment variable named DB_URL.

One solution would be to just prefix all environment variables with MY_APPLICATION_NAME_.

Another would be not permanently set environment variables, but instead to just call a script that sets them when needed. But that sounds a little messy.

I'm wondering if there's a well established way that deals with this problem.

Source Link
dwjohnston
  • 221
  • 3
  • 11

Environment variable names, when my development environmental has multiple projects.

The context is that I'm looking at doing staging/testing and production on a kubernetes cluster.

Where I might have some code that looks like this:

doSomething({
  username: process.env.DB_USERNAME,
  password: process.env.DB_PASSWORD
})

For my various kubernetes environments, this isn't going to be a problem, as I those environment variables can be set specifically for the environment.

However, for my development environment, there's a good chance that I'm going to have multiple projects, (or even different images for the same project) that all have a environment variable named DB_URL.

One solution would be to just prefix all environment variables with MY_APPLICATION_NAME_.

Another would be not permanently set environment environment variables, but instead to just call a script that sets them when needed. But that sounds a little messy.

I'm wondering if there's a well established way that deals with this problem.