3

I normally work by myself as a freelancer, and the setup I use has worked pretty well for me so far. I'm not sure if it's the optimal setup for a team though.

I develop on Windows, and I setup a Linux VM on my local machine, running the same OS/stack as our production machines (CentOS, Nginx, PHP-FPM). I setup Samba, and map my webroot to a drive in Windows. Locally, I setup host shortcuts such as http://someproject.local/. To share with the team, I use my IP address or an internal DNS name such as http://brandon/someproject.

I was thinking a possible change to this workflow would be to move the VMs onto one of our internal virtualization servers. One of the sysadmins could spin up a new one based on a VM image and that way all devs are using the same setup. Also means everything is backed up properly.

Another one I've read about would be a single dev VM, where each dev gets a folder full of projects they map to their local drive, and any other dev could see the project by going to http://thedevbox/developer_name/project_name. I dislike this approach though, as I would not be able to play around with the server stack if I wanted/needed too.

What setups to you use at your job?

Improve this question
1
  • 1
    This is a poll question. Change it to be more specific. Commented Mar 25, 2013 at 9:47

3 Answers 3

Reset to default
3

This is what Vagrant was designed to manage for you. You set up a base box, all the developers can install the same virtual image by running a single command. You can configure it to expose a port on the virtual image on the host machine so other machines can see it with a single line of code.

Improve this answer
1
  • Beat me to it. This is the right answer. Commented Mar 25, 2013 at 3:09
1

For me, the reason for developing against a linux VM is that it will be exactly the same as your production environment. This is definitely what you want. Giving all developers full access to their dev VM to be able to mess with the server stack isn't probably what you want. You don't want someone to change something that you later depend on - then you have to worry about keeping in sync all the server changes across all of the dev VM's. It also means that all of your developers will need to learn the idiosyncrasies of your virtual machine software. This can actually chew up a lot of time. I used Sun's virtualbox and there were quite a few little gotchas that made setup take quite a few days. We started giving everyone their own virtualbox VM's and it was a pain making sure that everybody understood how it worked, how to set it up etc. At another place where I worked we all used the same dev linux box and it worked great :)

One downside that I can see in having one large VM is that is needs to be much larger than individual VM's running locally, and it needs to be maintained by someone, and it needs to be running on a server that is up most of the time. But this is probably a good thing - it should save everyone time in the long term, if you appoint your best sysadmin as the sysadmin of that box.

Improve this answer
1

A single big VM would differ from the production server in that that it will have many instances of your application running in it; Production has only one. As you've mentioned, it also prevents you from playing with the server stack, and if something does break, it's broken for everybody.

With individual VMs that are cheap (=easy) to create, you can try things, break things, and restart easily. You can start a new VM for each change you're working on. You can have test the same code with n different configurations at the same time.

Anyway, if your VMs are on a server somewhere, you might want to use a NAS for all /home/ folders, to save some effort with back-ups and syncs.

Facebook uses the same approach, except they use physical machines instead of VMs; Provisioning and re-imaging a machine is easy to do and self-serve, which is the important part.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.