Skip to content

Commit bdabd7e

Browse files
committed
Added first part of best practices
1 parent f49ff9d commit bdabd7e

File tree

2 files changed

+14
-0
lines changed

2 files changed

+14
-0
lines changed

README.md

+2
Original file line numberDiff line numberDiff line change
@@ -105,6 +105,8 @@ Port: 5050
105105
```
106106
107107
Behind the scenes: `teller` fetched the correct variables, placed those (and _just_ those) in `ENV` for the `node` process to use.
108+
# Best practices
109+
Go and have a look at a collection of our [best practices](./best-practices.md)
108110

109111
# Features
110112

best-practices.md

+12
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
# Intro
2+
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
3+
4+
* [`Different envs`](#different-envs).
5+
6+
# Different envs
7+
We primarily use 2 methods:
8+
9+
* 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 ...
10+
* 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.
11+
12+
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 commit comments

Comments
 (0)