Teamwork questions!

[Webxplosion]

Hi there,

 

I have some questions regarding (team)workflow for PHP developers.

As we currently code in a team consisting of 2 developers, but on short notice we'll be expanding to 4 or 5 developers, any experiences that you guys have had in similar team sizes would be greatly appreciated!

 

My main concerns:

 

- How to work with multiple developers on 1 project

- How to implement a succesful workflow (using subversion)

- How to setup and maintain a single programming style and structure used by all the developers

 

Also, any suggestions for books to point in the right directions (being how to start using UML, subversion etc) would be greatly appreciated.

 

Thanks in advance for your comments / suggestions!

[448191]

- How to work with multiple developers on 1 project

 

One has to take/have the lead, if possible try to delegate different parts of the app that are phsicically in different places to different people, for clear responsibility but also to avoid svn conflicts.

 

- How to implement a succesful workflow (using subversion)

 

Needs clarification.

 

- How to setup and maintain a single programming style and structure used by all the developers

 

Method 1) discipline and oversight. Method 2) Automation, for example with PHP CodeSniffer. If you want to be brutal about it you can even reject commits that violate the coding standard by running phpcs in the svn pre-commit hook.

[Webxplosion]

Thanks 448191 for your contribution!

 

What I meant with the 2nd "How to" was really the hands on workflow, like:

 

1. A developer gets assigned a specific todo for a project.

2. He opens the project in his coding program (being Zend Studio or Komodo).

3. ?? He starts working in a "branch" or version of the project and makes his code changes / additions ?

4. ?? He tests the code how / where ??

5. ?? Afer testing he commits the code ??

6. ?? A lead developer checks the committed code and publishes this somehow to the live webserver ??

 

As you can see from step 3 on it's not very clear to me as to what should be a simple yet convenient workflow.

Could you elaborate some situations on these steps?

[448191]

There are several approaches to this, my ideal scenario is this:

 

1) User checks out trunk (branches are generally only used for huge changes that would interfere with the progress of trunk)

2) User develops his whatever, with TDD, of course -- remember, ideal.

Any functional testing, if only to get expected output for Unit Tests -- you can't tdd everything --, he does on his local testing server).

He's confident it works as advertised, and commits.

 

meanwhile, in gotham city, eauh on the server..

3) (optional) The pre-commit hook checks the coding standard in the pre-commit hook and rejects if the commit violates it.

4) The server notices the repository has changed (either signalled by post-commit or by scheduled svn updates)

5) The server runs Unit Tests, if passed deploys to testing server and runs automated functional tests (Selenium)

6) If both test groups passed, server deploys to staging server where the client can observe the new awesome features in awe. Or if your client is the *omg it doesn't work like I asked, the world will end*-type, a project manager periodically inspects this server and pushes to a different server, which is public to the client.

7) If either test groups fail, the developer and his supervisor are notified by email

 

Any of this can be done with manual supervision, but why would you?

 

Then at some point the client gives the green light of satisfaction, pays up. The team leader/project manager then creates a new svn "tag", a point of reference if you will. Of course alter they change their mind or want new awesome features, at which point the team starts working on the trunk, but whatever happens, they'll have the tag, a snapshot in time of when the client was actually satisfied.

 

The end.