Where do you keep your web development environment, in your workstation or on a server?

Question

In several years I am using my workstation as development environment. I think that most of web developers use their workstation for running their servers, Apache, Tomcat, Mongrel etc. I have been working in a company that have a Unix development server in another city, with the document root folder share with samba. I am still developing on my Windows PC because to use IDE like Eclipse PDT and RubyMine requires a fast access to the file system and because I want to try things on my own without bothering with helpdesk tickets and stuff like that. I prefer to run my tools, install/uninstall software easily.

The main problem is that I am forced to use Windows and I cannot develop on a simialr environment to Unix. For instance on production we have Passenger, in Windows Passenger cannot be used and since I have a shared environment, PHP/Rails, in development I have Rails URLs with http://localhost:3000/ and for PHP just http://localhost, on the production I just have http://domain.com/apps for Rails and http://domain.com/

So do you run your developemnt server in your workstation or on a remote server?

I would like to have a confirmation that my practice is the most adopted. Thanks.

Answer 1

A VM on my workstation (which has the advantage that it goes anywhere my workstation goes and I don't need to worry about bandwidth when I'm at a remote site)

Answer 2

I do the same, I have a development server locally to have immediate access to any changes made. Whenever I can, I build a staging process on the production web server as well for the thorough testing.

If you are interested in running a Linux webserver locally (either in a box or a VM), check out this question: Pre-installed Linux for Web Developers?

Answer 3

I develop on my workstation, then generally publish to a staging server that mimics the live server for testing prior to publishing on the live site. When there is no staging server, that step is omitted.

I work on Linux, so don't have the problem as my servers are a mixture of RedHat, Centos and Ubuntu.

You could create a virtual machine on your machine, e.g. with VMWare of VirtualBox, that mimics your remote server. That way you'd have a non-Windows environment locally to develop on.

Answer 4

I develop on a Windows machine, with Apache. When I'm happy with my changes, I push them to a test server (FreeBSD, Apache) for the client's feedback, and then when they're happy, push the changes to the production server (Debian, Apache).

Other than funny stuff like case sensitivity differences between the OSes (table names in MySQL, in particular), I haven't had any platform-based troubles.

Pretty much the only trouble I had was the initial setup, figuring out which PHP modules I needed to install on my test server. My production server's setup's out of my control.

Answer 5

The answer depends a lot if you're working alone or on team, and the method used to share and transfer files (Subversion, Git, SMB, FTP, ...)

In the past we used to have a shared local developement server (Debian/apache), access files via windows shares (samba), and publication to remote (pre)production servers with FTP. But, that was dreamweaver time and we had a lot of issues working together on same project. The worst case was sharing work with remote teams, painfull version management accross FTP clients.

Now, we tend to use apache on windows (wampserver) ans SVN to share and publish files. It appear to complexify the thing when working alone, but for teamwork it has no comparison with the old way of working.

The issues with php/mysql on windows are known : - less stability and responsiveness - Paths must be written unix-way to avoid troubles switching to linux servers (C:/dir/file.php instead of C:\dir\file.php) - You must pay attention to mysql table names and filenames case, because if an error in case happens it won't throw an error on windows. You get the slap when you switch to production server - Command line tools / Apache or PHP extensions that are inexistant in windows world

We work sometimes with people using Macs ou linux workstation to get rid of theses problems.

If your developement process requires Passenger on the developement station, I think you'd better use a linux workstation or run a lightweight apache server inside a VM.

Answer 6

My rule is: work locally and integrate continuously.

But TBH It really depends on the project I'm working on and on the dev environment.

In general I'd rather having the whole environment on my box for many reasons:

• I'm able to reproduce integration
• I'm able to reproduce issues
• I can work from home or without network

BTW There were projects in which I couldn't have it on my box just because the database was so huge, or the authentication system was built by another department and I could build / deploy it on my own...

Answer 7

For us its all SVN. A branch for developer version, where all the developers are supposed to check in the files before they leave for the day. A branch for build version, the final running or buildable or deployable one will be located here. Then there is the stage system that is used for testing and demo. The copy on the stage will always be from the build branch.

Answer 8

I like coding on my laptop. Since I am only web developing I like being able to be portable and code from lots of different locations because I am travelling.

Being able to then do git push or svn checkouts means that I can sync any changes with my main repository and then ensure that my main development platform on a server in the datacenter is pretty quickly up to date.

If I wasn't moving around all the time, I would use my workstation for sure.

Answer 9

Locally. Fortunately Visual Studio makes this pretty simple.

When I get to a state I am comfortable with, I publish to a beta server, then if we like it there in testing it pushes live.

Ken