it pains me to see this divide between operations and development perpetuate. the developers (whether internal or external) ship some nonsense. it needs excessive configuration. of course it needs to be keyed. it doesn't manage its own resource usage properly. it needs to be protected from malicious agents. it has a ton of ever-shifting external dependencies.<p>so the ops (or devops) people, not being developers, and more importantly not having a mandate to spend months or years trying to address the fundamental issues try to wrap the fragile broken thing in a blanket. they deploy it, and build up an equally messy infrastructure around it.<p>this goes on to such a degree that the developer, probably suffering from his/her own limits on time, and scope limitations, finds themselves unable to deploy or even test the system in question without becoming a full time ops person.<p>so the process gets worse, and we have 'canaries', which is basically an admission that developers cant even test simple changes to make sure they work before they are deployed.<p>ops has to deal with poorer and poorer software<p>developers have the scope of change cranked down so low that basically nothing can be done<p>we hire more and more people to try to get things to happen, and none of them can get anything done because its all so gridlocked.<p>the answer is clearly repeatably and trivially deployable builds, without any secret commands and passwords that only billy really knows. including all the configuration and state required to being up an instance of the service from both a development and operational context. this, apparently, is akin to asking for an honest politician, or a perpetual motion machine.