Leon
Leon

Reputation: 881

SCM workflow with remote development server

I'm having some troubles organising a new workflow for our small dev team. Our team consists of five developers and two designers on different locations. At the moment we're using Zend Studio 5.5 because it runs on Mac, Linux & Windows and lets us directly work on a remote box via FTP/SFTP. Usually a dev server but sometimes on a live server. I think everybody is working on 2-5 different projects a day. Sometimes a couple of weeks primarily on one project but that doesn't happen often. In a year that comes down to +/- 30 projects I think.

I would like to have everybody use (some form of) SCM. I was researching IDEs and workflows that could fit our team. In my research I noted that a lot of both the IDEs and scm workflow assume that you develop locally (local Apache, Mysql, PHP and other components). My colleagues would rather not have to install a stack locally but rather edit on the remote and see the changes immediately when they hit F5 in their browsers.

Does anyone have experience with this kind of setup? What would be a good workflow and cross-platform editor that has good remote editing support? An editor that supports "download on open" and "upload on save" would also be sufficient. I thought about creating some sort service that would trigger rsync when a file is changed but I think that would be to much of hassle for them.

Or is this not going to work and is the only solution to develop locally and to check in the changes when you are done?

Upvotes: 0

Views: 336

Answers (1)

Gustav Bertram
Gustav Bertram

Reputation: 14907

Perhaps you should not make the IDE go to the code, but instead bring the code to the IDE, grasshopper.

In Windows, it's possible to work directly on a remote network folder. In Linux, you can use something like sshfs to make a remote directory look like a local one.

You should still have separate working copies for each of your developers, or you would lose many of the benefits of using version control software in the first place.

In our work environment, we all agreed to use Subversion, but we did not specify whether the individual developer would work locally or remotely, and we do not specify which editor, or even which operating system they use.

It's been working great so far.

Upvotes: 1

Related Questions