Question

We’ve decided on a version control system – using Mercurial clients and Bitbucket for repositories. But it’s just occurred to me we have a problem I didn’t consider.

We have an internal development LAMP server (Ubuntu) and all the developers work on websites stored on it, which means all developers share a single file source and we are all working from it. It’s rare that two different developers will work on the same site at the some time, but it does happen occasionally. This means that two developers can easily overwrite each others work if they are working on the same file at the same time.

So my questions is: what is the best solution to this problem? Bearing in mind we like the convenience of a single internal server so that we can demo sites internally, and it also has a cron job running for backing up the files and databases.

I am guessing each developer would have to run their own LAMP (or WAMP) servers on their individual workstations, commit, and push to bitbucket repository. And of course whenever working on a different site, do a pull and resolve any differences as per usual. This of course takes away the convenience of other team members (non developers) being able to browse to 192.168.0.100 (the LAMP server IP address) and looking at the progress of websites, not to mention that some clients can also access the same server externally (I’ve set up a port forward and limited to their IP addresses) to see the progress of their websites too.

Any advice will be greatly appreciated.

Thanks in advance.

Answer 1

Yes, the better solution is probably to set each developer up with a local server. It may seem inconvenient to you because you’re apparently used to sharing a server, but consider:

1. If you’re really interested in using a single server as a demo server, it’s probably better that people aren’t actively working developing on it at the time. They could break stuff that way! And developers shouldn’t have to worry about breaking stuff when they’re developing. Developing often means experimenting.
2. Having each developer running their own server will give them flexibility to, say, work disconnected. You’ve got a decentralized version control system (mercurial), but your development process is highly centralized. Even if you don’t want people to work remotely, realize that when your single server goes down now, everybody goes down.
3. Any time a developer commits and pushes those commits, you can automate deployment directly to your demo site. That way, you still have a quite up-to-date source on your demo server.

TL;DR: Keep the demo server, but let your devs work on their own servers.