3 ms·

The intent of this part of 12 Factor comes from the Bad Old Days when devs didn't run their own stuff in production. There was a dev team who could push code an

The intent of this part of 12 Factor comes from the Bad Old Days when devs didn't run their own stuff in production. There was a dev team who could push code and cut releases, and an ops team who would then deploy the releases, and who was paged when things blew up. If you store the database hostname/credentials, as an example, in the "code" (either literally in the app code, or in a config.ini that lives in the repo and gets baked into a release), then the ops people can't quickly repoint the app at a hot-spare database during an incident: they'll need to edit the repo, push it, cut a new release, etc. If there is a long build step (as for a C++ app, for example), then this isn't really tenable during an outage. If this is in an environment variable, their normal deployment scripts can make the change for them. I agree that this is probably not necessary anymore if your team is all wearing both hats (dev and ops), and its just as quick to make an edit to the repo and cut/deploy a new release as it would have been for the Ops team to run their deployment script in the old days.

hirako2000 3y ago
Great you pointing out the presence vs absence of dedicated operation enginners. Also that things have evolved more than a bit in team structures and tooling. Even when ops are perfectly comfortable with git, they are rarely keen on touching dev repos even if deployment times were tenable. If code changes need peer reviewed, how so configuration values don't get treated at least the same way? Secrets in clear are obviously a no go, I feel though that encrypted secrets in repos has become reasonably simple with mature tooling in this area. Ansible's fast growth got cut short once people started to hear k8s at every meet ups perhaps.
- ElevenLathe 3y ago
  Secrets in the repo is actually something I've seen for a long time, and there's not much tooling necessary for it beyond just shelling out (yes, I know) to gpg in your deploy scripts. I saw this on CVS-based projects very early in my career, which then fizzled out as the "12 factor style" (secrets in ENV vars) took over. Can I ask what the modern solution for this is? Also: > If code changes need peer reviewed, how so configuration values don't get treated at least the same way? The easy answer to this is a CODEOWNERS file, with the app code being owned by the devs, and the config being owned by ops. But again, not sure how to do this for secrets without their being plaintext in the repo. Do any code review tools support encrypted content?

hirako2000 3y ago

Great you pointing out the presence vs absence of dedicated operation enginners. Also that things have evolved more than a bit in team structures and tooling. Even when ops are perfectly comfortable with git, they are rarely keen on touching dev repos even if deployment times were tenable. If code changes need peer reviewed, how so configuration values don't get treated at least the same way? Secrets in clear are obviously a no go, I feel though that encrypted secrets in repos has become reasonably simple with mature tooling in this area. Ansible's fast growth got cut short once people started to hear k8s at every meet ups perhaps.

ElevenLathe 3y ago
Secrets in the repo is actually something I've seen for a long time, and there's not much tooling necessary for it beyond just shelling out (yes, I know) to gpg in your deploy scripts. I saw this on CVS-based projects very early in my career, which then fizzled out as the "12 factor style" (secrets in ENV vars) took over. Can I ask what the modern solution for this is? Also: > If code changes need peer reviewed, how so configuration values don't get treated at least the same way? The easy answer to this is a CODEOWNERS file, with the app code being owned by the devs, and the config being owned by ops. But again, not sure how to do this for secrets without their being plaintext in the repo. Do any code review tools support encrypted content?