4 ms·
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.
by 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 agoSecrets 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?