3 ms·
> But I think OPs point was that programming in a container encourages a more fragile setup. I don't see how that point can be argued at all, particularly if t
by rumanator 6y ago
> But I think OPs point was that programming in a container encourages a more fragile setup.
I don't see how that point can be argued at all, particularly if the project is expected to be deployed with Docker.
- dahfizz 6y agoI just argued that point. When developing inside docker, you are fooled into thinking that various things about your environment are constants. When it comes time to update your base image, all these constants change, and your application breaks.
- jfim 6y agoIs that a problem in practice though? Updating libraries or the base image that one's code depends on always has the risk of breaking from API changes or regressions, and in a container, at least it's easy to reproduce the issue.
- rumanator 6y ago> When developing inside docker, you are fooled into thinking that various things about your environment are constants. No, you really aren't. You're just using a self-contained environment. That's it. If somehow you fool yourself into assuming your ad-hoc changes you made to your dev environment will be present in your prod environment although you did zero to ensure they exist then the problem lies with you and your broken deployment process, not the tools you chose to adopt. A bad workman blames his tools. Always.