4 ms·
I'm sorry but I really don't understand how having env.production.toml commited in the same repository as code makes anything that you said impossible/more diff
by hamax 10y ago
I'm sorry but I really don't understand how having env.production.toml commited in the same repository as code makes anything that you said impossible/more difficult.
I can always grab the build from production and run it locally with the modified config.
- jimktrains2 10y ago> env.production.toml Which production env? Which datacenter? Which database cluster? &c The deployment should take care of generating configs, they shouldn't be hardcoded or stored anywhere imho.
- hamax 10y agoI mentioned earlier we have one config per environment. So for example env.use1.toml, env.use2.toml and env.usw1.toml. Then one more for ci and one example for local development. Sure deployment can generate configs but it has to take it from somwhere. So you need a database preferably with versioning and encryption. It's also nice if you know which settings are used in specific builds so you can go back and debug past production issues. Of course for larger teams and deployments it makes sense to develop and maintain this infrastructure. But since we already have git, why not just use it.