How do YOU guys/gals do this?

Rodney_H_

I work for a small firm.

We design new sites, we manage current sites.

There are about 300 sites in our data-server.

We constantly have a problem of someone working on a site the same time someone ELSE is working on it.

We also have the problem of people NOT returning finished work into data-server when they are finished so someone will makes some changes to an OLD version...

It is silly, but there must be a way to deal with this and eliminate these headaches.

Do you all use work logs or software to checkin/checkout files?

Just wondering so I can go back to my group and say THIS is what we should do...

Any thoughts would be much appreciated....

Jason_Batten

Seperate content from presentation, as best you can.

Be sure to have PHP processing files which do most of the work, the rest display data.

Don't think of it as a project whole think of it as seperate pages. Only allow certain people to work with certain files.

You can checkin/checkout files using a database.

Rodney_H_

I think either you misunderstood me, or I misunderstood you, Jason.

You see, not all sites that we build are dynamic. I would say only 20-25% of them are developed in PHP. The rest of the sites are pure HTML.

When we pull an existing client's site (folder of files) out from our server, we pull a copy of everything out to our desktops to work with, but we leave a copy in there JUST IN CASE. We are on a MAC server, which allows us to change the COLOR of the folder from green to red, but people forget, causing the problems.

I was just wondering if any of you use some sort of log system so you know who checked the files/site out last, and when they returned it with a brief description of work performed, etc.... ??

Or, if there is even software or some existing SYSTEM (??) out there to keep us from F*%$king up so often... (parden my special characters... 🙂

???

Jason_Batten

Pure HTML, with CSS or are you using <font> tags?

Seperate content from presentation, as best you can. Only allow certain people to work with certain files.

Meaning that there will simply not be conflicts if you avoid working on the same files. Is there a reason you HAVE TO?

You have a system at the moment where you have to change the folder colour in order to let other people know that you are working on the project. Nothing is really wrong with that system, the problem is that people are forgetting. So, is the problem the system or the people?

Sorry I do not know of any software. You could develop something yourself.

But I suggest more discipline. Lol, sorry if I sound harsh but someone in your team needs to put the foot down and keep your team in order otherwise "oh I forgot" will run wild, which by the sound of things has happened. If someone screws a project up by forgetting what will the clients think? Perhaps you can forget to pay that person if they forget 😉

khendar

With that many sites and multiple developers you should probably look into a version control system like CVS or Subversion.

dalecosp

Yup. PITA, but it's designed to solve exact what you're describing....

khendar

What do middle eastern bread products have to do with anything ?

Jason_Batten

Mmmm bread drools

piersk

If you use Dreamweaver it has a really simple version checking in that you can "check in" and "check out". It won't do any of the merging and difference checking that CVS or SVN would do, but it might be what you need.

Rodney_H_

@: Yes, the bbm (big boss man) has to lay the law down about this problem. good point. If he DID, then people would not be so careless or forgetful I think. Font tags? shudder Me hatem fontem tags.... 🙂 CSS all the way! (Sorry I misunderstood.

@: Yes. I guess it is time we do more than just the folder color trick. I will look into "CVS" or "Subversion". Do you prefer one over the other?

@: Either I am the slowest or I am just clueless in general, but I really don't know what PITA is. Can you explain :o

@: Some prefere dreamweaver, some prefer GoLive, Some prefer NOTEPAD or some other text editor.

Thanks everyone. If you have any experience with CVS or Subversion (or something else) please let me know which you prefer...

Thanks.

MarkR

To use Subversion or CVS, every developer must have their own development copy of the web site.

This is 100% vital, I really CANNOT stress it enough.

A single development site for multiple developers, is a DEFINITE NO-NO.

Obviously you will then need a process for deploying a given revision into your production server - this is not normally massively problematic with PHP - but make sure that you don't deploy from one of your developers' working directories - instead export a given revision to a temporary directory and deploy from there - ideally to a staging / testing server before you put that revision into production.

A developer cannot be expected to work without making any mistakes - in fact, he should even be allowed to make a critical error which breaks the entire site, then go on lunch (or on holiday) without fixing it.

As long as he fixes the bugs before committing, it's all ok.

Mark

Rodney_H_

MarkR:

Those are really good thoughts.

I understand what you mean.

Thanks for your input.

Sxooter

The tip to use CVS or Subversion is spot on. To add to that, make it so that you have a kind of virtual "peg board" to denote who has what sites checked out. You can use some kind of ticketing system for that job.

Then, for the piece de resistance, make it so that the ONLY way to deploy changes to the actual sites is by checking the changes into CVS from the user machine, and then having a semi-automated method that deploys them to the live side. I.e. No developers can actually deploy directly, only by using some simple app that pulls the site from CVS and deployes it for them.

Rodney_H_

Ah!

I see, I see, said the blind man...

Thanks bunches, Sxooter.

Happy Friday.

csn

Even if you're the sole developer, SVN makes life a lot better. SVN is a lot better than CVS. Anybody like any of the slew of other VCS better? Arch, git, Codeville, Bitkeeper, etc.?

khendar

I'd suggest SVN over CVS mainly because its a little less daunting to get started. There are windows clients which embed into explorer - so its basically right to access the checkin/out menus.

http://tortoisesvn.tigris.org/

bpat1434

How do YOU guys/gals do this?

On top, lights off, in the bedroom...
Her on the desk, desk-lamp on, computer tunes playin "Shaggy - It Wasn't Me"

wait.... that's not what you were askin was it....

I can't say I've worked with SVN or CVS extensively, but reading up on SVN I have to agree that SVN is a little less daunting as khendar put it. Either will work, it just depends upon your platform and how much time you're willing to spend on it.

One other option here is to have the SVN/CVS server, and when a user checks-out a project, it goes to a sub-folder named the project name, and the parent folder is their folder. And they edit it in their folder. Then they check it back in when they're done, and it's removed from their folder. But that's if you don't have the ability to have a server on everyones computer. It's a little more risky, but I'm sure something could be set up so this is possible 😉

I am interested, how would SVN/CVS be helpful to one person designing multiple sites? Would it really make that much of a difference or not? And would it take up a lot of space, or is that miniscule in comparison to the features you get?

MarkR

You can certainly use the same SVN repository for multiple sites - that works fine. I believe the Apache Software Foundation have many hundreds of projects in the same repository. They are now at revision 100,000 +

As far as setting up development environments on everyone's workstation is concerned - this is NOT necessary, as long as they have separate development environments, they can all be on the same server.

One way of doing this is using named virtual hosts like alice.project.company.internal and bob.project.company.internal.

Another possibility is to use different port numbers for different developers.

It can get potentially confusing once you have many projects and many developers, and one port per project / per developer. I used to work at a company where we had about 5 projects and half a dozen developers.

Mark

bubblenut

Version control is very definately still relevent for single developers. Largely because of rolling back changes but also for tracking and for the other cool little things you build in to your achitechture.

Rolling Back Changes
Everyone makes mistakes. Simple fact. There will come the point when you've put an erroneous piece of code live and you need to roll back a file, or the whole project to a known valid state. Something which both CVS and SVN provide for helping this is tagging. If you get to a point where your application is working you can "tag" it as a release. If after future changes something major goes wrong you can then easily roll the live site back to the working tag while you figure out what went wrong.

Tracking
If you're as forgetfull as I am you'll forget what you changed in a file 5 minutes after you commit it. Well, you can leave a message with a commit to remind you (an others) what changed on a particular revision. This feature is very usefull for looking at the evolution of a file over time. For example, in cvs you can do cvs log [filename] to see all the revisions and all the comments left with each of them.

Other Little Things
Both CVS and SVN have loads of little features which make development easier. You can attach scripts to commits so, for example, you can require that php files pass a syntax check or any unit tests they may have before they're allowed into the repository. You can set up nightly tasks to run all unit tests on the application and if they all pass then tag the repository as a release so that you can roll back to this point if anything goes wrong.

A cool thing which I like the idea of (but still haven't gotten around to implementing) is a two branch approach where you have a development branch and a live branch (much like MarkR said but with the multiple staging in the version control system itself). So, all your developers check out from the development branch, make their changes and commit back into the dev. branch. Then, when a developer has completed a task and needs to put the work live the changes are merged from the dev. branch into the live branch. At this point the checks I mentioned earlier (or at least those directly relevent to the code being merged) can be run to make sure that the code in the live repository is always clean. The live site is then updated to take the changes from the live repository. There are a number of advantages to this kind of setup.

Your live repository is always as clean as it can be while at the same time developers can commit early and commit often in the dev. branch which keeps everyone up to date.
Nightly unit and performance tests can be run on the live repository to automatically make sure that everything is working well.
If you have multiple live servers you can easily have all sites pull in the latest changes by simply running a cvs update. No more messing around with rsync and having to wait for secondary web servers to catch up.
And this is probably the most important. You have a clean version history for the live site. If something goes wrong you can easily roll back to a fully working system in moments because you have application wide tags which are fully working. In the single branch approach you rarely (if ever) come accross a situation where every single developer is in between projects and you therefore have a clean repository.

I come from the position of working on a single, large site. I'm sure there are very different problems and sollutions when working on a large number of smaller, faster turnover projects. I'm also sure that the points I've made here aren't always going to be applicable.