3 ms·

> CI/CD system can put things like secrets into files This sounds horrible. Why does specifically your CI/CD need to know those things? This also sounds like

> CI/CD system can put things like secrets into files This sounds horrible. Why does specifically your CI/CD need to know those things? This also sounds like your CI/CD system is "too smart" and your build process is "dumb pipes", what I believe to be a unsupportable, unmaintainable anti-pattern - if people can't build/test things on their own machine, things are likely not repeatable/reproducible at all and you're one CI/CD issue away from losing your project. > Something I dislike about spring boot is how spring-y everything has to be. I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done?

shortrounddev2 3y ago
> This sounds horrible. Why does specifically your CI/CD need to know those things? You set it up so that production secrets are kept in that store and are only accessible by a 1 or 2 high level people. Developers don't have access to production secrets, only dev or staging, which live on their own machines and are lower security risk > if people can't build/test things on their own machine I don't see why they wouldn't be able to build/test on their own machine. You just have a different secrets store and keys than the CI/CD does > I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done? Yes I hate this. I want to be able to decide how properties are loaded, not rely on some ethereal state managed behind the scenes and not be able to see if it's loading properly. If I want to use their terrible resources/config file, I'll specify that in middleware/startup