7 ms·

I think the general idea of running a vm with all your dev setup in is great, but I've often found the small niggles (such as speed of switching quickly between

I think the general idea of running a vm with all your dev setup in is great, but I've often found the small niggles (such as speed of switching quickly between browser and vm terminal, the fact you need a fairly good computer to run even quite a modest server with a gui and if you don't use a gui, you're limited to 256 colours) all a bit more trouble than the benefits. My solution is to set up my perfect dev environment in linux (I use Fedora) on a partitioned usb pen drive. Then either boot from it (if i'm on a crappy computer) or boot a vm direct from the usb if the computer is more competent. It's also quite nice if there's an emergency and you're away from your computer -- you can just rush into an internet cafe, plead/bribe them to let you boot from your usb then have everything, ssh keys inlcuded ready for urgent repairs!

scaryclam 13y ago
I think the point here is that it took you time to set up that dev environment. It shouldn't matter where your environment is (a VM, a laptop, etc), you should be able to recreate it easily and reliably. This is what the automation tools are for. I prefer salt stack and have a salt config for my work laptop. If something happens to the laptop or I get a new one I just need to run salt, wonder off for an hour and when I get back my entire environment is set up. I also use it with vagrant so that when a new dev joins the team they can run one command and have a copy of the project setup in a vagrant box, databases and all, ready to go. You could set up a similar thing so that if you lose that USB key you can have your prefect setup reinstalled with minimal fuss.
- pestaa 13y ago
  Would you be able to share at least some of your current salt config? This is one idea I've been thinking a lot about lately, but never managed to get beyond the obvious package names, which is trivially installable with one command on a good Linux distro.
- campbellmorgan 13y ago
  very good suggestion. At the moment I keep an LVM snapshot, but that is a bit cumbersome. I hadn't heard of salt - thanks! Will look into it.
jstanley 13y ago
"such as speed of switching quickly between browser and vm terminal, the fact you need a fairly good computer to run even quite a modest server with a gui and if you don't use a gui, you're limited to 256 colours" This implies you are running a terminal emulator in X on the VM and doing your coding there? I use VMs for development all the time, and a headless VM with SSH access is perfect. It's almost identical to doing development locally.
- campbellmorgan 13y ago
  the options as I see it are either do everything over ssh to a headless vm as you suggest which definitely has its advantages or working inside a full-screened vm/ booted environment. Perhaps not the best justification, but I prefer the latter because I can include my gvim setup and use the mouse for resizing columns, browsing code and using NERDTree. I miss that when running vim over ssh.
  - SpenserJ 13y ago
    Bring your configs with you - http://dotfiles.github.io/ http://dotfiles.github.io/ Vim should be able to do everything that GVim can do, if you add a few lines to your configs. I'm not sure what specifically though. I bring my entire development setup with me when using a server, and preparing it is as simple as cloning Homeshick (or Homesick if you have Ruby), cloning your dotfiles repository, and installing any applications that you want to use.
  - gtaylor 13y ago
    You can edit and browse on your host VM. Just adjust the VM's network settings and use a shared host-guest folder for the code (what exactly this ends up being varies based on the virtualization). You really can make it a near exact match for a local development environment. Bridge your ports to your expected ones on the host machine, share the code folders, and SSH in if you need to punt a dev server when you make changes (or set your Editor/IDE up to do that for you). Browser can still point at local:8000 or whatever you expect.
eli 13y ago
Why are you switching between a browser and your VM terminal? I run my VM headless -- all the files I need to edit are in shared directory.
- jabbernotty 13y ago
  You don't run any commands on your VM? Such as compiling/restarting an application?
  - gtaylor 13y ago
    You can run those through your console on the host machine like normal, with the added SSH piece. Or you could set your editor/IDE up to do that after changes (if required).
  - eli 13y ago
    Well, I suspect SSH is going to be faster than using the VM terminal in any case. But I'd set it up to watch the directory and compile/restart automatically, if you can.
tga 13y ago
My primary development environment is a VMware virtual machine with Ubuntu LTS getting 2GB out of my MacBook Air's 4GB of RAM. I usually run a database, a web server, a couple of browsers and PyCharm (Java) in the virtual machine and another browser with many tabs in the host OS. What I wanted to point out is that everything works perfectly and I can instantly switch between applications and in/out of the VM just fine. Backing up the VM is of course as simple as copying ~40GB to an external drive or the desktop at home (gigabit ethernet ftw) and the nice thing is that I can have multiple versions of it on various machines.

scaryclam 13y ago

I think the point here is that it took you time to set up that dev environment. It shouldn't matter where your environment is (a VM, a laptop, etc), you should be able to recreate it easily and reliably. This is what the automation tools are for. I prefer salt stack and have a salt config for my work laptop. If something happens to the laptop or I get a new one I just need to run salt, wonder off for an hour and when I get back my entire environment is set up. I also use it with vagrant so that when a new dev joins the team they can run one command and have a copy of the project setup in a vagrant box, databases and all, ready to go. You could set up a similar thing so that if you lose that USB key you can have your prefect setup reinstalled with minimal fuss.

pestaa 13y ago
Would you be able to share at least some of your current salt config? This is one idea I've been thinking a lot about lately, but never managed to get beyond the obvious package names, which is trivially installable with one command on a good Linux distro.
campbellmorgan 13y ago
very good suggestion. At the moment I keep an LVM snapshot, but that is a bit cumbersome. I hadn't heard of salt - thanks! Will look into it.

jstanley 13y ago

"such as speed of switching quickly between browser and vm terminal, the fact you need a fairly good computer to run even quite a modest server with a gui and if you don't use a gui, you're limited to 256 colours" This implies you are running a terminal emulator in X on the VM and doing your coding there? I use VMs for development all the time, and a headless VM with SSH access is perfect. It's almost identical to doing development locally.

campbellmorgan 13y ago
the options as I see it are either do everything over ssh to a headless vm as you suggest which definitely has its advantages or working inside a full-screened vm/ booted environment. Perhaps not the best justification, but I prefer the latter because I can include my gvim setup and use the mouse for resizing columns, browsing code and using NERDTree. I miss that when running vim over ssh.
- SpenserJ 13y ago
  Bring your configs with you - http://dotfiles.github.io/ http://dotfiles.github.io/ Vim should be able to do everything that GVim can do, if you add a few lines to your configs. I'm not sure what specifically though. I bring my entire development setup with me when using a server, and preparing it is as simple as cloning Homeshick (or Homesick if you have Ruby), cloning your dotfiles repository, and installing any applications that you want to use.
- gtaylor 13y ago
  You can edit and browse on your host VM. Just adjust the VM's network settings and use a shared host-guest folder for the code (what exactly this ends up being varies based on the virtualization). You really can make it a near exact match for a local development environment. Bridge your ports to your expected ones on the host machine, share the code folders, and SSH in if you need to punt a dev server when you make changes (or set your Editor/IDE up to do that for you). Browser can still point at local:8000 or whatever you expect.

eli 13y ago

Why are you switching between a browser and your VM terminal? I run my VM headless -- all the files I need to edit are in shared directory.

jabbernotty 13y ago
You don't run any commands on your VM? Such as compiling/restarting an application?
- gtaylor 13y ago
  You can run those through your console on the host machine like normal, with the added SSH piece. Or you could set your editor/IDE up to do that after changes (if required).
- eli 13y ago
  Well, I suspect SSH is going to be faster than using the VM terminal in any case. But I'd set it up to watch the directory and compile/restart automatically, if you can.

tga 13y ago

My primary development environment is a VMware virtual machine with Ubuntu LTS getting 2GB out of my MacBook Air's 4GB of RAM. I usually run a database, a web server, a couple of browsers and PyCharm (Java) in the virtual machine and another browser with many tabs in the host OS. What I wanted to point out is that everything works perfectly and I can instantly switch between applications and in/out of the VM just fine. Backing up the VM is of course as simple as copying ~40GB to an external drive or the desktop at home (gigabit ethernet ftw) and the nice thing is that I can have multiple versions of it on various machines.