Live data from Hacker News

Why You Should Be Using Virtualisation In Your Development Environment

morethanseven.net

31–40 of 44 posts

Re: Why You Should Be Using Virtualisation In Your Development Environment

#31

Earlier quoted context omitted.

PS, if anyone knows a solution to the file access speed issue (not just the filesystem of the guest, but also what ever you share with it from the host) please tell me. Parallels, VMWare Fusion and VirtualBox all have this issue and it drives me mad sometimes!

I'm not sure if this helps in your situation, but when I'm running VMware I don't share any local directories. I use rsync to manage the virtual server directories since it's similar to how I deploy to my remote servers. Having to manually "deploy" code to a local virtual server can be tedious, so running a background process that watches your local directories for changes helps a lot.

I understand you use the rsync approach since its similar to how you actually deploy, which is completely understandable, but I just wanted to note that John and I struggled with the shared folder performance issue + Vagrant for months, and we did a LOT (months) of real world tests with various solutions (John at one point even integrated background automated rsync directly into Vagrant), we found that NFS is really the only satisfying solution (for us, at least).

NFS allows us to edit code locally on our host, and have it "instantly" be ready on the guest. After just half an hour of working, the various inodes are cached on the guest and file system access over NFS is mostly native-speed since it only needs to grab changed pieces.

The end result: We completely ripped out background rsync despite John working weeks on it, and we put in built-in support for NFS, which has been going strong since around July now and is happily at work at many places that use Vagrant :)

Re: Why You Should Be Using Virtualisation In Your Development Environment

#32

Perhaps a middle ground could be using a virtual machine as a staging environment?

This is what we do. The biggest benefit here, for us, is that if a release goes horribly wrong, or our testers find a disastrous bug, we can easily roll back to a clean state and only lose the time it takes to load the VM.

I've tried using a VM for doing development, but I've run into the issues mentioned in the parent article: Visual Studio 2010 is memory and CPU hog. I've maxed out the RAM in my laptop, and it still ran too slowly to be really useful.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#33

I'm assuming Mitchell hasn't seen this yet, but I'm sure I speak for both of us when I say thank you for including Vagrant in your post. I would like to point out a few things. 1. Another thing to set up. Streamlining project setup is one of Vagrant's primary goals. Instead of putting someone, who potentially has no background with the app, through a 20 step process installing all the application dependencies you can…

I'll change the Ruby tool bit. I mentioned elsewhere in the post that it's a great tool whichever language you're using.

Regarding tools other than Chef for provisioning, while there is a Python clone somewhere Chef will very likely have the ability to use other languages for recipes very soon. I've seen at least Java and Python mentioned.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#34

Earlier quoted context omitted.

PS, if anyone knows a solution to the file access speed issue (not just the filesystem of the guest, but also what ever you share with it from the host) please tell me. Parallels, VMWare Fusion and VirtualBox all have this issue and it drives me mad sometimes!

I'm not sure if this helps in your situation, but when I'm running VMware I don't share any local directories. I use rsync to manage the virtual server directories since it's similar to how I deploy to my remote servers. Having to manually "deploy" code to a local virtual server can be tedious, so running a background process that watches your local directories for changes helps a lot.

People might be interested in DoubleDown (http://blog.devstructure.com/introducing-doubledown) from the DevStructure guys. It uses rsync in a similar background manner and it's designed with this exact problem in mind.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#35

How do you handle version control in this environment? Locally on the mac or in the virtual server?

Personally I edit the code on my mac using gvim and run and use git on the VM. I've used ExpanDrive to mount the directory from the VM for editing previously but I've been moving towards using vagrant with it's NFS shares.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#37
post #22

I really wish you could virtualize OS X. I would love to build a beefy Linux box as a base machine and virtualize OS X and Windows. It's my understanding you can do it, but it's a bit hacky, right?

I ran a VMWare image of OS X a few years ago. I don't know what it's like now, but back then the lack of an OpenGL driver was the deal breaker. OS X's graphic shell uses Quartz Extreme on top of OpenGL, without GPU acceleration it was virtually unusable.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#38
post #22

I really wish you could virtualize OS X. I would love to build a beefy Linux box as a base machine and virtualize OS X and Windows. It's my understanding you can do it, but it's a bit hacky, right?

I ran a VMWare image of OS X a few years ago. I don't know what it's like now, but back then the lack of an OpenGL driver was the deal breaker. OS X's graphic shell uses Quartz Extreme on top of OpenGL, without GPU acceleration it was virtually unusable.

I'm running a VMWare image of 10.6 (Snow Leopard) right now. I didn't set it up, but it does indeed run. It's not perfect. It had problems running Safari 4, but now runs Safari 5 fine. I use it for browser testing. That being said Flash video crashes it hard, HTML5 video crashes it gently (like caressing a child's face with a butcher knife).

I have a pretty capable machine (Core i7 920, 6GB, GTX260 video card), but speed wise it is quite usable and I run all sorts of osx-only apps on it (like the omni suite) every day.

So.. i guess like 7.5 out of 10? Buggy, but really getting close.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#39

Earlier quoted context omitted.

Can you elaborate on that background process? Is that something built into rsync?

It's actually something I've been working on that I want to put up on github. I hacked up a Python version of it as a proof-of-concept but rewrote it in C as an installable executable using autotools. Basically I tell it which directory I want it to watch for changes and it does automatic syncing by piping rsync. I keep a local and remote signature of the files and their timestamps. When it first starts up, it pulls…

Sounds like some pretty cool stuff! I hope you post about it when you do decide to release it. :)

Re: Why You Should Be Using Virtualisation In Your Development Environment

#40

I just touched Test and test on mac and I see both of them just fine.

On what filesystem? Certainly not the default HFS+, which is is case-insensitive but case-preserving.

It works as you described on my macbook. I was on my Mac at work before.
Post reply on HN