2 ms·

I don't understand how secrets being committed to the same repository implies anything you've written. They don't have to be compiled in. For parallel environm

by hamax 10y ago

I don't understand how secrets being committed to the same repository implies anything you've written. They don't have to be compiled in. For parallel environments we simply have multiple configs in repository. One per env (env.toml.prod, env.toml.jenkins, env.toml.dev-docker, ...). If you want to test a specific env you can copy and modify it. Just like you'd do it if they were on s3. I'd even argue that it's easier to debug issues if you know what code ran with what env. Yes, you have to create a new build for each config change, but in reality code changes are much more frequent than env changes so we didn't find this being an issue at all.

koolba 10y ago
> I don't understand how secrets being committed to the same repository implies anything you've written. They don't have to be compiled in. If they're part of your repo and built with the app, presumably they're baked into the final tarball or whatever artifact you're composing. Modifying them would require expanding out the package, replacing or adding a file, and packaging it up again. Compare that to having an entirely externalized setup where the application knows nothing about where it's config comes from. Switching things out is purely externally. This means that setting up a new environment can be done using the exact build aritfact that was deployed to production. > Yes, you have to create a new build for each config change, but in reality code changes are much more frequent than env changes so we didn't find this being an issue at all. All the more reason to keep them entirely separate. Changing code shouldn't involve changing configs and the people who have access to them aren't necessarily the same set either. One more point on this, is if you happen to support an enterprise / on-premises use case. It'd be pretty silly to have env.tom.on-premises-customer-A, env.tom.on-premises-customer-C, env.tom.on-premises-customer-C, ... checked into source control. Yes you can have a separate package step for on-premises that cleans it up but if it's not there in the first place, you don't have to.

by hamax 10y ago

koolba 10y ago

> I don't understand how secrets being committed to the same repository implies anything you've written. They don't have to be compiled in. If they're part of your repo and built with the app, presumably they're baked into the final tarball or whatever artifact you're composing. Modifying them would require expanding out the package, replacing or adding a file, and packaging it up again. Compare that to having an entirely externalized setup where the application knows nothing about where it's config comes from. Switching things out is purely externally. This means that setting up a new environment can be done using the exact build aritfact that was deployed to production. > Yes, you have to create a new build for each config change, but in reality code changes are much more frequent than env changes so we didn't find this being an issue at all. All the more reason to keep them entirely separate. Changing code shouldn't involve changing configs and the people who have access to them aren't necessarily the same set either. One more point on this, is if you happen to support an enterprise / on-premises use case. It'd be pretty silly to have env.tom.on-premises-customer-A, env.tom.on-premises-customer-C, env.tom.on-premises-customer-C, ... checked into source control. Yes you can have a separate package step for on-premises that cleans it up but if it's not there in the first place, you don't have to.