Personally I prefer repeatable deploys and knowing that the right dependencies are installed, however we've all found ourselves in OP's situation from time to t

Personally I prefer repeatable deploys and knowing that the right dependencies are installed, however we've all found ourselves in OP's situation from time to time. We still have a few ancient pets around that may get in situ hotfixing when circumstances warrant, but most of our workloads are containerized and deployed to kubernetes via gitlab pipes. There are a couple of things you can do to speed docker builds up, such as using build targets and structuring targets so that the layers of code that might need to change are added to the image last, allowing the earlier layers to be served from cache unless base dependencies change. For most of our services a commit-build-push-run cycle is probably on the order of 1-3 minutes. That might be slower than a nimble-fingered guru logging in to edit a line and restart a service, but its close enough that the advantages of the system far outweigh its costs, for us anyway.