How to work collaboratively on a website

views:

answers:

+1 Q:

How to work collaboratively on a website

Hello,

I'm working on a website with some other people. Usually when we want to modify something, we do the change on our machine and just upload the new version with ftp, hope it'll works (or that nobody will notice it doesn't the time we correct it) and that's it.

It's already not the best way to work alone but even less to work collaboratively so I'm asking advices.

I think that a solution like svn/git/mercurial could help me. I found bitbucket which allows free private repository with mercurial. But still after, how can I upload the changes I did to the ftp and make sure the version I've on my computer is the same than the one on the server.

We are all doing it during our free time (not paid) and some people comes and leave every year so I'm looking for something free, easy to use (explain to everyone why we should use a DVCS is already hard) and which doesn't rely on a specific person.
The server we are using to host the website is a cheap one and doesn't allow the use of ssh, svn,...

Thank you

+1 A:

Version control will not help with the issue you are describing - namely, uploading untested changes to a production site.

What you (and your team) need, is better quality control procedures - you need a test website and a tester (QA) person. The process would be:

Make a change
Update the test website
Have the update and the whole website signed off by QA
Update the production/live site

What you will gain by using version control (CVS, SVN, Git or anything else) is recoverability - you will be able to go back to a version before any breaking change. It will still not solve the issue of "the new code broke the site".

Oded 2010-07-04 15:26:52

maybe that (with a tester person) can work for a big website but here I'm talking about a website for an asbl of less than 100 person and where the development team is usually not bigger than 3 (but change often). Most of the time, the changes are updating some pages or creating a form to subscribe to an event. Anyway having a test website is certainly a first step.

Martin Trigaux 2010-07-04 16:20:40

@Martin Trigaux - indeed, the first step would be to have a test/staging server. Your QA person can be one of the non programmers around, someone who can try and break the site.

Oded 2010-07-04 16:24:58

You want scheduled releases.

Commit and update code regularly
Code freeze or develop in a branch and merge to the trunk
test on a staging environment
Find a bug goto step 1
Release

Duncan 2010-07-04 15:28:26

thanks so that's for the part with the version control but after for the release how can I do that ? If during this commit I updated 10 pages, I've to remember which one was it. If I deleted one, I've also to remember it

Martin Trigaux 2010-07-04 16:16:27

You need to understand that what represents your latest correct working build is not what's on the server but in your source repository whether that be SVN or just the file system. Anything as long as it isn't the live server! Make sure everything works locally as expected then unless the site is huge (I guess not given your situation) deploy it in its entirety as a single version.

Daz Lewis 2010-07-04 15:29:04

The site isn't huge but still too big to upload again everything each time. The whole website is about 60mb because of pictures, documents,... And as I said to Duncan there is also the problem if I delete something. It'll be left even if I do a full upload of the last working build.

Martin Trigaux 2010-07-04 16:25:27

ansaurus

tags:

views:

answers:

How to work collaboratively on a website

related questions