Skip to content

Commit

Permalink
Added first part of best practices
Browse files Browse the repository at this point in the history
  • Loading branch information
vongohren committed Jun 9, 2021
1 parent f49ff9d commit bdabd7e
Show file tree
Hide file tree
Showing 2 changed files with 14 additions and 0 deletions.
2 changes: 2 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -105,6 +105,8 @@ Port: 5050
```

Behind the scenes: `teller` fetched the correct variables, placed those (and _just_ those) in `ENV` for the `node` process to use.
# Best practices
Go and have a look at a collection of our [best practices](./best-practices.md)

# Features

Expand Down
12 changes: 12 additions & 0 deletions best-practices.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
# Intro
This is a list of some of the best practices using this tool. Please contribute if you have any additions or changes to current or non existing best practices

* [`Different envs`](#different-envs).

# Different envs
We primarily use 2 methods:

* A single file, where each environment is a parameter, see prompts and options, where you can populate one with an environment variable env:STAGE and STAGE=dev teller ...
* Keep a config file per environment, similar to what you would do with .env file (.env.example, .env.production, etc.) -- but with teller none of configuration files contain any sensitive information (as opposed to .env) so you're safe.

The best practice really depends on the size of your team and how you prefer to work. We imagine if the team is small, and the use cases are not many, a single file would be great. If the team is large, or maybe you're enabling other teams -- keeping a file per environment would be better, and this way you can "distribute" your teller files per use case in a central way.

0 comments on commit bdabd7e

Please sign in to comment.