| I was hoping the article was about using a Docker container *as* your development environment. Talk about easily compartmentalizing and standardizing your projects across machines. Imagine if you got to a new job and your setup instructions were literally `docker pull mycorp:development.mobile && docker run mycorp:development.mobile`. - Oh, your machine was lost? Take your new machine and docker pull docker run. - Someone migrated project A to python 3.8 but project B still requires python 3.6? docker pull docker run. - You have to work on some backend code? docker pull docker run. - But the backend code uses an IDE that I don't have installed. Docker Pull! Docker Run! Every job I've ever started has come with a sheet explaining how to set your machine up to work on the codebase. Install this, upgrade that, change this environment variable, and for the love of god don't install a newer version than this. I mean, I know I've been lucky to get a sheet, but this is usually the first full day of work. I've never really tried to get this going. I assume that it'd be possible to get an OS instance up in docker that you just VNC into. Load up that image with the tools you need (IDE, git, etc.), wire up some stuff for security (GitHub keys, probably other stuff), and clone the initial commit of your repo so that people can just `git pull` the rest. Maybe this is a thing. I haven't looked in a few years. |