Merits of having a shared development server [closed]

Question

The developers on my team want a shared development machine to use instead of running the software on their own computers. Their rationale seems to be that we are only targeting Fedora/CentOS/Red Hat for release and they use Macs. I tried to explain to them that for what we are doing, they will all need root on the server and one of them could quite easily do something like sudo rm -rf / (even if by accident), thus hosing everyone's work that's not checked into source control. I told them to download CentOS and use VirtualBox to run the code.

So I guess the question here is who's in the right? From my perspective the issues of sharing a dev server outweigh the minor if any inconveniences of running CentOS on their machines.

Answer 1

To expound on my comment above, there should be absolutely no need for your devs to need root access in your dev environment, shared or otherwise. With a combination of well-thought-out file permissions supplemented by a handful of sudo rules, they should be able to do whatever is it they need to do.

Regarding a shared dev environment versus each developer having their own environment: I'm with your developers here. With each developer managing their own dev environment, you're ending up with umpteen completely different configs, software revisions, file permission structures, daemon versions, kernel versions, etc. That is a nightmare for bug squashing.

They recognize that they need a stable, well-managed development environment. They're absolutely right, so give it to them!

Answer 2

Why not both - develop on their workstation AND test on the shared dev server?

If there is concerns about loss of data, you can always run a virtual machine on top of the dev server, do snapshots of the machine and have the developers update code on that VM. Worse case, you can always revert VM back to previous backup.

Answer 3

In a similar situation we took the route of local development but we have an independent stack of our application running just for devs and ops (we call it integration) to deploy and run test against. The devs have root access so if needed they can do investigation and troubleshooting but they know the system is transient so at anytime it can be blown away (and I do that as a method of testing my deployment scripts).

Answer 4

If I was in your shoes I'd look at building a VM that could be used on their dev systems that mirrors the staging server setup. It gives them what they need, without someone doing something silly. Plus if the staging server ever goes down for whatever reason, you don't' have all your developers twiddling their thumbs while your'e trying to get it back up....however rare that might be (not nearly as rare as you'd' think)

Answer 5

At my company we have both shared dev servers and personal local servers. The point is, you cannot have the best of both worlds, but you can have both worlds :) I'm on the side against shared dev servers but I'm going to mentions both below.

Running a local server is a real nightmare for those who are not that much into sysadmin. You did say your devs mostly use Macs and that just makes things worse. Using a virtual machine does solve the problem of the different OS, but still requires them to be able to manage a server, which is not their specialty. I have found the solution to be Vagrant. It lets me create provisioning code for a Virtualbox virtual machine, and my devs can be freed from maintenance tasks. While I have to spend days to get started and maybe hours on each new project, this has saved lots of time that I would otherwise have to help people with installing and configuring packages.

Some more advantages of Vagrant:

• The devs can use whatever tool they want, including Notepad on Windows.
• Dev environments can be destroyed and re-created at will.
• No need for a creepy shared account, which make every code commit traceable to the developer.

Using a shared server has its own disadvantages:

• It is easy for two devs to edit the same file (especially if they use different editors, because they can't detect if the file is already opened).
• Because 2 devs should not edit the same file, parallel execution of tasks is more tricky. Imagine you find yourself having to edit a file, but your friend is already doing some work on it, and he is not going to finish any time soon.
• It requires devs to be extra careful when doing a git commit, because you don't want to commit other people's changes.

That being said, there are cases where you do need a shared dev server. In my experience this include:

• Staging server, which is the place where the code stay before it is deployed to production server. Not all devs need access to this server.
• Developing/testing a feature that requires a callback from a third party. One example of this is payment with Paypal.

The easiest way to setup a shared dev server is to create an application user, maybe with the name of the project as the username. This user should own all the files related to the project. Then add the public keys of your devs to /home/<application>/.ssh/authorized_keys and your devs can simply login as that user to do things. It will be helpful to have a convention when committing code using the shared account, such as to include your initials in the commit message, so that you can know which commits belong to which devs.

Answer 6

Depending on your application consider continuous deployment. Developers should be checking all their changes into a version control system (CVS, SVN, GIT, or whatever). Setup a post commit trigger to deploy the committed changes.

In some environments you will need some sort of continuous build process. (An hourly build may be sufficient.) This provides the developers a place to verify how their changes work with other developer's changes.

If you do need your developers to run a local server, standardize the setup and configuration. It may be possible to provide a scripted setup, or even check the entire configuration into your revision control system. Don't expect your developers to manage servers on their own.

Answer 7

Use openindiana. Zones give you operating system level virtualisation. Give each dev a zone that they have root access to. way more efficient than a virtual machine.

Still not sure why you need root access, but I'd that's the requirement, zones will give you a solution.

Answer 8

ARE YOU ALL MISSING THE POINT????

FOR WEB DEVELOPMENT: The dev server should be a PERFECT REFLECTION of the live server the application will reside on in LIVE PRODUCTION. WHY? Because from a hardware perspective, you want to make sure that your live server is going to behave EXACTLY like the Dev server you just tested all your stuff on. If the hardware is dissimilar, results may (to read: WILL) vary.

If you use SVN or even Dreamweaver's SourceSafe (locking system), you're pretty safe from screwups as long as your web developers know what they're doing. The awesome progress and cooperation that is to be had when everyone can contribute to a project directly can really help developers to learn more about each other, making subsequent projects easier and easier.

FOR SOFTWARE DEVELOPMENT: The Teamwork ethic I just preached about is still applicable. If everyone is sharing a single development server, they are still getting the teamwork and comraderie benefit out of it, but of course with software you do have to consider what platform(s) you mean for it to work on. So, i'd say that is a project-by-project consideration. Your solution may be "Multiple Shared Dev Servers to meet the hardware specs of the platforms you're trying to be compatible with."

That being said - unless (to read: even if) you're Microsoft or Adobe, you will never test "enough" types of systems...