4 ms·
Dear Everyone Doing Devops: do not build gems on your production servers. Build a tarball, test the tarball through dev/staging, deploy the tarball to productio
by krakensden 11y ago
Dear Everyone Doing Devops: do not build gems on your production servers. Build a tarball, test the tarball through dev/staging, deploy the tarball to production.
For any value of tarball- literal tarball, deb/rpm (actually CPIO under the hood, but who cares), prebaked AMI (not tar at all), docker image (tarball of JSON + nested tarballs. Seriously, it's tar all the way down).
Everything will be better. Roll forwards. Roll backs. Speed. Attack surface. Reliance on 3rd party services that will rate limit you hard.
- softawre 11y agohttp://martinfowler.com/bliki/ImmutableServer.html http://martinfowler.com/bliki/ImmutableServer.html
- nirvdrum 11y agoYour point is well-taken. Broken deploys are just the extreme case. You'd run into the same problem if two devs on the team just happened to install libraries at different times. One would get it, one would not. And you don't get a remotely helpful error message in that case. So, you're back to mirroring or vendoring everything you need anyway. Arguably that's better, but why even bother with a centralized package management system at all then?