undefined | Better HN

0 pointskoolba9y ago0 comments

> If you want to run local environment you can simply create your own configuration.

Externalizing config forces you to cleanly handle local environments as well. There's nothing special about them.

I generally recommend having an env.example file listing out required environment variables with sensible local defaults. This eases onboarding a new developer or even an existing developer on a new machine.

> I don't really see what you gain by moving configuration files into a separate repository.

Because config and code should be kept separate. Updating the database that your production app is using is not a code change. It's a config change.

Setting up a new CI environment should not require pushing new code.

If you have a production issue in version X, separating code and config allows you to reproduce it using an isolated database/mq/foobar service. It's exactly the same code.

0 comments

hamax9y 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.

jimktrains29y 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.

hamax9y ago

I 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.

j / k navigate · click thread line to collapse

0 pointskoolba9y ago0 comments

> If you want to run local environment you can simply create your own configuration.

Externalizing config forces you to cleanly handle local environments as well. There's nothing special about them.

> I don't really see what you gain by moving configuration files into a separate repository.

Because config and code should be kept separate. Updating the database that your production app is using is not a code change. It's a config change.

Setting up a new CI environment should not require pushing new code.

If you have a production issue in version X, separating code and config allows you to reproduce it using an isolated database/mq/foobar service. It's exactly the same code.

0 comments

hamax9y 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.

jimktrains29y 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.

hamax9y ago

I 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.

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.

j / k navigate · click thread line to collapse