3 ms·
> Its uncovering something that was always there; incompetence is rampant in software engineering. That's what I took away from the article. Production was set
by 0xfeba 8y ago
> Its uncovering something that was always there; incompetence is rampant in software engineering.
That's what I took away from the article. Production was setup and they don't know what kernel version it has, or what JVM version it's using, or which C library, etc. Or, now we want feature X, so we need to upgrade dependancy Y. I already did it on my local machine, but Bob from DevOps doesn't like upgrading things on QA/integration/prod without a change control...
Granted, apps have thousands of dependencies now, so keeping track of it manually is impossible. Docker came along and promised that only whatever's in this one config file is what's installed. Easy!
So it eliminated lots of the server-specific configuration management but created other problems.
- lykr0n 8y agoI think it really comes down to developer tooling. Devs, in the absence of tooling will make their own and default to the latest stuff. If the company doesn't provide a fully mirrored developer environment, then everyone is asking for trouble. Where I work, we have a specific team dedicated to managing this tooling. We support Python Django, Java, and Go. You can clone the base repositories which include vagrant scripts to setup everything. You develop in that and it gets sucked up into the pipeline. You want something newer? If it works locally in our environment, the SLA says it will work in production. Doesn't work locally, then tough shit. In personal projects I do with others, I try and do the same thing. Python? 3.6 is our version target. Java is OpenJDK 1.8.0 latest. Rust & Go are compiled with the latest versions. It might not be incompetence in software engineering as a whole, but more of an issue in defining version and software targets.