Manage version control with a central development server (LAMP)

Question

I'm working in a small team with up to 5 (web)developers. Because our team is growing frequently and we ran into problems with multiple people working on the same code we decided to set up a VCS.

Current Situation

Currently we are working with a central development server (LAMP). So every developer works on the same code base and if the code is tested and ready for our live server we just copy it via ftp. I know this is some sort of an anno 1600 workflow but yeah - it is what it is and also the reason for this question.

On the development server our directory structure looks like this:

/var/www 
      /Project1 
      /Project2 
      /Project3 
      ...

Additionally there are some small non-webapplications - Android/iPhone/Windows 8 etc. apps and some C# tools which also should be included in the VCS.

Goal and problems

Our goal is to get a clean setup for a VCS, which works together with an issue tracking software, enables us to work togheter on the same project at the same time without overwriting our codes and simply gives us the advantage of version-control.

I think the first question for us is, which technology should we use. Some of us have allready experienced subversion. But because git is some sort of becoming the "standard" and there are a lot of "pro git" arguments among the web users we tend to using git.

There starts our uncertainty. For using git - a decentralised VCS - it looks like we have to start using seperate development servers on each developer's computer. The problems with that are:

• Some times we work on different computers, so when we forget to push our code we have a problem.
• We would have to work with virtual machines because the dev servers should be the same as our live server (This would simply not be enforceable in our environment, believe me it's not possible).
• The development server usually also served as a "tryout" or "presentation" server where non-developers had a look at what's going on.

Is there another possible setup with git so that we are able to benefit from the system while still using a single(!) development server? Maybe with different directories for each developer. Or can we still work on the same code base with maybe locking the files we are working on and then commit them to a repository. It's maybe important to say that while it became a factor for us it is still uncommon that multiple developers work on the same part of an application at the same time.

Answer 1

You're on the right track, here.

Maybe with different directories for each developer.

Yes, definitely different directories for each developer.

The machine you're on is is pretty uninteresting. Just ensure that each developer logs in as himself, and checks out a copy of the git repo under his own home directory. You'll wind up with several copies of the code living in your filesystem, but hey, disk is free.

It's true that git supports decentralized operation. But you won't be using it that way in your typical workflow. Just make sure that a bare repo is available on some convenient server, and have everyone pull from that. Access it via http, ssh, or even via the filesystem if you like.

You mentioned a "tryout" area as part of your workflow. Do yourself a favor. Hire another developer, named Jenkins, who also checks out your code using git. He's implemented here: http://jenkins-ci.org/ (and runs under http://tomcat.apache.org/download-70.cgi). That way every push to the central repo will immediately make an updated version of your website available under Jenkins' home directory, where you can quickly try it out and run sanity checks. We call this Continuous Integration, and it will definitely improve your workflow.

Answer 2

 It's maybe important to say that while it became a factor for us it is still uncommon that multiple developers work on the same part of an application at the same time.

If few people work on same machine and same codebase things have to go wrong. Because of overwriting and because if one breaks something others have to wait untill fix to test their stuff.

You need to distinguish few environments. Looks like you need three (very common):

• Production - where the project is actually used by end users.
• Staging - place where developer merges his work with other developers, tests it and sometimes clients can peek into this area.
• Development - where each developer works alone, before merging with others.

Usualy development environment means machine developer works on. If you want to keep it on shared machine you can do that too. Environments and machines is something decoupled. You just need to have a different codebase for each project, each developer and each environment.

So in case of Git and 5 developers in company there would be 5 repositories for development environment. For staging environment (merging code) because it's not a good idea to push to non-bare repositories you would need one repo for merging and another for testing code there and showing client current state. If production server has Git another one there. If not you would just transfer files to production via FTP from staging environment. So few repositories for each project.

And the workflow is like so: You work on your development environment, when you added a feature or fixed a bug you push your changes to staging environment bare repo and pull this out on the non bare (a Git hook could do that at once), and when the project is ready to release a new version you push (or transfer via FTP) it to the production.

Some times we work on different computers, so when we forget to push our code we have a problem.

Well if you have to do development environment on the very same shared server you can synchronize your files from local machine to the server via something like rsync, or map a network drive or whatever but this always will be a little slower then working on local machine. Working localy however has the problem you mention. Even without VCS. Like when using FTP - if you change something on your machine and forget to transfer it - same thing happens. But you wouldn't want to merge your dissasembled code to the staging environment for sure. It has to stay in development until it reaches a resonable state.

We would have to work with virtual machines because the dev servers should be the same as our live server (This would simply not be enforceable in our environment, believe me it's not possible).

GUI-less wev servers don't use much resources. I think you guys could work on the code and test it everyone on his own machine. So development environment localy, and only staging on the shared server. You could check out something like Vagrant to help managing virtual machine images. So you would make sure that every project gets right settings. This would ensure that you guys test in same way, be safer (now if shared server would break nobody can continue work, and you need to have a good backup there) and faster (no transfer needed until merging). Git is better ten SVN in this matter because it keeps full repo on each machine with history and everything so if one pc breaks there are still good copies somewhere else.

Also things like Gitosis can help you manage the staging environment repo settings, and Redmine or other project managing software often has ways to integrate with VCS.

Answer 3

because git is some sort of becoming the "standard" and there are a lot of "pro git" people among the web users we tend to using git.

This is poor foundation for making choice in SCM-world. Git is not "standard", but rather "fashion" with a lot of noise around it. "Pro Git" is more fanboyism, than than sensible and reasoned decision in a lot of cases

work togheter on the same project at the same time without overwriting our codes and simply gives us the advantage of version-control

Branches in any SCM will allow you to get it, even with Git (keyword: "Git-flow")