> If i develop on Ruby locally against version X.Y.Z, but only X.Y.W is available on the server due to Debian packaging older versions
Either you use RVM locally to develop with Ruby X.Y.W or you install RVM on the server to use Ruby X.Y.Z there. Of course if the OS on the server is too old or too new there could be some versions of Ruby that won't work. It happened to me because of versions of openssl.
Docker is amazing for deploying things on servers and i use it extensively - nowadays almost everything on my homelab is containerized since i no longer need to have that many separate VMs anymore...
That said, Docker is also oftentimes a poor option for local development, unless you're talking about external dependencies the app needs (e.g. MariaDB/PostgreSQL, RabbitMQ, Redis etc.), or maybe very specific setups that just won't be achievable otherwise (specific userland needed).
For example, when trying to run Ruby/PHP/Node/Python/Java apps in Docker containers, i've run into the following:
- problems with file permissions
- problems with file line endings
- problems with Docker Desktop bind mounts (e.g. directory won't be mounted, path parsed incorrectly etc.)
- problems with Docker Desktop bind mount performance
- problems with networking (e.g. host.docker.internal sometimes refusing to route to non-containerized stuff on the host)
- problems with run profiles (e.g. your IDE + Rails integration just won't work, at best you can just launch a different container/Compose stack with some other parameters)
- problems with test runs and coverage (if you use the IDE integration, though that depends on the stack and how deeply your IDE is integrated, e.g. Java with IntelliJ IDEA)
- problems with remote debugging, breakpoints, flame graphs etc. (most of those either don't work when the code is inside of a container, or need additional setup, e.g. remote debugging, where supported)
In my eyes, whenever possible, develop locally with the native runtimes for the IDE integration etc., use Docker for deployment or maybe QA/test environments as well - anything that will go on a server somewhere.
I find RVM much easier to manage than docker, for local development. To deploy on servers, it depends. Deploying with Capistrano to one server is easier than building a docker container and push / pull it. For cloud / serverless environments... the number of companies that really need that is surprisingly low. Most businesses are small and are well served by a single VPS.
Either you use RVM locally to develop with Ruby X.Y.W or you install RVM on the server to use Ruby X.Y.Z there. Of course if the OS on the server is too old or too new there could be some versions of Ruby that won't work. It happened to me because of versions of openssl.