Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
You missed "dependency hell". Nothing quite like doing a re-deploy to get the code you were updating into production only to find that one of your project's upstream dependencies changed ...in a way that breaks everything.
Yeah, ideally, you catch that by having a pre-deployment testing task, but depending on how much time elapses between your testing-deployment and your "real" deployment, one of your upstream, internet-hosted projects may have changed. Only real way to guard against it is to create local, semi-static mirrors of all your upstreams.
I agree that this can happen, but it can happen in almost every setup. But as you said you could solve it, it is not an unsolvable problem. Thanks for mentioning that! ☺
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
You missed "dependency hell". Nothing quite like doing a re-deploy to get the code you were updating into production only to find that one of your project's upstream dependencies changed ...in a way that breaks everything.
Yeah, ideally, you catch that by having a pre-deployment testing task, but depending on how much time elapses between your testing-deployment and your "real" deployment, one of your upstream, internet-hosted projects may have changed. Only real way to guard against it is to create local, semi-static mirrors of all your upstreams.
I agree that this can happen, but it can happen in almost every setup. But as you said you could solve it, it is not an unsolvable problem. Thanks for mentioning that! ☺
Like many things, the most well-learned lessons come as a side-effect of a bloodied nose. =)