11 ms·
For years, I advocated for developing inside of VMs or containers. Even wrote a very handy shell tool for managing the process. But a few years ago, I stopped,
by donw 10y ago
For years, I advocated for developing inside of VMs or containers. Even wrote a very handy shell tool for managing the process. But a few years ago, I stopped, and just switched to developing on my local machine.
Working in VMs or containers adds a ton of complexity, for very little benefit.
Installing databases is trivial, with any of `brew`, `yum`, or `apt-get`.
Your `bin/setup` script can take care of automating that for onboarding new developers. The same script gets used in your Dockerfile.
And your CI system is there to as-perfectly-as-possible replicate production, to run your comprehensive test suite (you do practice TDD, right?) and catch things like "forgot to add a library dependency to the setup script" and "app broke because of a library version difference".
Since switching to local-only development, plus containers and CI/CD, my life has gotten a lot nicer.
- Daviey 10y agoIf you are developing within a docker container, how do you get as far as CI before you have tested it working locally?? The whole point of using docker containers is to have the same development experience locally, in CI and in prod.. not have some unknown system libraries on your box which don't match other environments. Want a database? docker run mysql/mysql-server Your argument for switching away from containers, seems to actually be arguing for using containers.
- crdoconnor 10y agoYou'll never get the same environment locally as you do in prod. That's why you have staging (you do have staging, right?). It's better to make the environment as close as possible to prod without adding massive inconvenience but docker both adds inconvenience and forces you to use it in production (which entails a whole other set of headaches) if you want close environmental parity, and even then, since it's lightweight virtualization there are hundreds of things which can behave differently between dev and prod. IMHO you either want very close environmental parity (in which case full virtualization is the way to go) or you don't, in which case running locally is fine.
- amouat 10y ago> That's why you have staging (you do have staging, right?). Plenty of people don't. The main reason being that staging is never quite the same as production...
- sz4kerto 10y agoWe are working in a remote team, so replicating shared envs locally is important. Our system contains multiple databases, application servers, SMTP, etc etc. -- you can use all of them in your local dev env. It's not the same as prod because of different latencies, etc., but all containers are present locally. It is _very_ useful.
- crdoconnor 10y ago>We are working in a remote team, so replicating shared envs locally is important. It is, but I'm not particularly keen on docker as a solution to this problem. It provides a low level of isolation/realism for these services and the tooling surrounding it is relatively poor.
- bradmwalker 10y agoWhat about LXC system containers? Differences between hardware and OS virtualization still exist, e.g. immutable system clock, but it's otherwise like running a regular Linux box. An init process that can simulate rebooting, mature system package management, no process isolation that's often gratuitous, etc.
- bradmwalker 10y agoWhat about LXC system containers? Differences between hardware and OS virtualization still exist, e.g. immutable system clock, but it's otherwise like running a regular Linux box. An init process that can simulate rebooting, mature system package management, no process isolation that's often gratuitous, etc.
- deleted 10y ago[deleted]
- haylem 10y ago> Installing databases is trivial, with any of `brew`, `yum`, or `apt-get`. yes. For once database version and one single data set. If you handle multiple customers, multiple versions of a software suite to support which target specific versions of a DB, containers or VMs are handy. I don't do my dev in a container. That always seemed stupid for me. But my dependencies are in containers.
- sytse 10y agoAt GitLab all team members develop without virtualization. Disk IO is just much faster that way. We recommend the approach in our development kit https://gitlab.com/gitlab-org/gitlab-development-kit https://gitlab.com/gitlab-org/gitlab-development-kit We would love to see better virtualization disk performance so it is easier for non-team members to contribute. We're happy that despite that people are still able to contribute https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&state=opened&utf8=%E2%9C%93&label_name%5B%5D=Community+Contribution https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope...
- emilburzo 10y agoThat's interesting, but shouldn't containers (e.g.: docker/lxc) be almost as fast as native at disk I/O? I mean that's basically why I moved my self hosted virtual servers from KVM, which was abysmal on regular desktop spinning disks, to LXC/Docker which is comparably fast to native -- plus I can fit a lot more containers than full VMs.