At 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

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...

That'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.

The problem is that on MacOS you have to run containers in a virtual machine since you're not running on Linux. Crossing the VM boundary with IO can be slow, especially on virtualbox.

Oh, I'm not using MacOS so I didn't know that.

It makes a lot more sense now, thanks!

If 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.

You'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.

> 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...

We 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.

>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.

What 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.

What 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.

> 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.