1

So we've just received our new server which will be used solely for website development and version control.

I've set up Ubuntu (11.04 desktop edition, I like interfaces, sorry!) and installed Apache, PHP and MySQL - so far, so good.

We've decided that we want to use Git as our version managing system, since we've had good experiences with it. But... We're unsure of how to lay out, our structure. So I'm hoping you can help us.

Current setup

At the moment, we run one development server bbtsrv02 which is a Windows server, running XAMPP. We do all of our developments on this server and it leads to a lot of noise and mess when we're hacking things quickly.

Once the changes have been made locally, we upload these files to our external server (hosted by someone else) via FTP.

It's far from practical, there can be 3/5 developers at one time working on the site as a whole. It causes conflicts and... it's not nice.

The current idea

The idea is to use bbtsrv02 as a "mirror" server. It'll contain all of the most up to date and live code. bbtsrv03 (the new server) will be our development server. We'll have the master branch which will also contain the live code, and each developer will branch their own version for each change.

But... Further thinking has led me to come to the conclusion, that we'll need to setup some virtual hosts, for each developer so they can close the master repo and work from there?

I don't have much experience in this area, but my current plan is to partition the main HDD and give us each enough space to develop on.

We then push our changes from our branch to the master one and then "copy" it into bbtsrv02 and upload. I'm hoping of course, I can make some bash scripts to do that for me?

Improve this question

2 Answers 2

Reset to default
2

The way that we do it (YMMV) is as follows:

Each dev builds and does basic code tests on their desktop/laptop etc. They use git locally to commit changes, branch etc. When they are ready to push, they take what ever local actions the need to clean up their timeline and then they push.

The push goes to a staging server. Our staging server is a mirror of our production servers. We do load testing, code reviews, and final checks there.

Once we pass that level, we push to the production servers.

Improve this answer
2
  • Sweet! So where the correct term is "staging" server? I never really thought about developing locally, but that really makes sense. And there is less server clutter. We could clone from the development server, to local, and commit back right?
    – James
    Sep 19, 2011 at 21:02
  • 1
    Weeeell, that's what WE call it. I've heard staging, test, and several others. Also another benefit is that folks can dev on their laptops, where ever they are. Our workflow is one way from staging to prod. In other words, when we promote from staging to prod, there is no bringing code "back". It's just a point in time.
    – tsykoduk
    Sep 27, 2011 at 22:13
2

One option is to have all developers run their own LAMP server (XAMPP perhaps). That way devs aren't stepping on each other doing various things. Your dev server could have 2 virtual hosts - One for the most current "dev" website and one for the most "stable" website.

Both sites could be on git. Your dev site would the repo that all devs push to. Then you could set up a post-commit hook to push the stable branch to the stable repo. Your stable site runs from the stable repo.

Hopefully I've not confused you but this solution seems like the best

Improve this answer
1
  • The development server being the new one we received? Or the developers machine? (Wow, confusing.)
    – James
    Sep 19, 2011 at 21:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .