Error 404: page not found

Key Principles of Team Work

published by yegor256 on Jan 3, 2010

Your work in FaZend.com projects may be very effective if you adhere to the principles listed here.

Two Sources of Information. There are only two sources of information in the project — wiki specification and source code. If and when you don't understand one of them — it's a fault of the artifact's author. You should ask for an explanation. Otherwise you will be responsible for the defects in deliverables, if you create them relying on your incorrect or incomplete understanding.

/trunk is a King. You should develop the product in your own branch, named like /branches/ticket123. It is your responsibility to merge your branch with /trunk as often as necessary. If you miss some change of the /trunk and later it will lead to a disability to merge your branch with trunk — you will be responsible.

/trunk is Always Workable. Any commit we make to /trunk should never break the product — phing build cycle has no errors.

100%. No matter what stage of development lifecycle you're in, the source code you create should always be: 100% covered by unit tests (validated by PHPUnit and xdebug); 100% compliant to Zend Coding Standards (validated by PHPCS); 100%-free of mess detector errors (validated by PHPMD).

KISS. The less you code — the better. Try to write as less as you can. Try to keep your code simple and easy to understand. If you have to create something complex — you definitely have a problem with an understanding of some architecture concepts. Zend simplifies PHP programming, but FaZend makes it extremely simple and straight–forward.

Traceability of Changes. Every time you commit changes to SVN the comment provided should contain a link to the Trac ticket, e.g. "refs #123 - layout change". Immediately after SVN commit the Trac ticket will be updated, automatically.

Tickets/Changes Workflow

This is an example of a properly organized change management workflow:

Step 1. The Scope. Angela, the tester, reports a problem or a change that needs to be done in the project, creating a ticket #123. Robert, the architect, decides that this change has to be done by James, the PHP developer, and re-assigns the ticket to him. James, discusses the task in the ticket, making sure he understands what exactly he should do and how to do it.

Step 2. The Branch. James creates a new branch for the implementation of ticket #123, on his local computer (Subversion 1.6 is used, pay attention to the formatting of SVN comments):

~$ svn co svn://svn.fazend.com/test/trunk test
~$ cd test
~/test$ svn cp ^/trunk ^/branches/ticket123 -m "refs #123 - new branch created"

Committed revision 593.
~/test$ svn sw ^/branches/ticket123

Step 3. Programming. James makes changes to the code in the branch, discussing the scope of the change in #123. James commits changes to SVN as often as possible.

Step 4. Code Review. When the implementation is finished James re-assigns #123 to Robert, asking him to review the result and confirm that the implementation is correct and doesn't contradict with the entire project architecture. Robert raises his concerns and comments in #123, returning it back to James. James makes corrections, commits them to SVN, and re-assigns the ticket back to Robert, and so forth.

Step 5. Reintegration. When the review is done and Robert confirms that the implementation is correct and acceptable for the project architecture and coding rules, James resolves all possible conflicts with SVN reintegration, locally:

~$ cd test
~/test$ svn sw ^/trunk
~/test$ svn merge ^/branches/ticket123
--- Merging r594 through r602 into 'php':
U    php/src/application/Model/Auth.php
~/test$ cd php
~/test/php$ phing -Dto.lint=true
Buildfile: ~/test/php/build.xml
 [property] Loading ~/test/php/./build.properties

test > main:
.... skipped ....
BUILD FINISHED

Total time: 13.7454 seconds

Neither svn merge nor phing should generate any conflicts. If there are any problems or defects, it is James's responsibility to fix them. It is also his responsibility to update the branch with latest changes from trunk, if they happen during that two days while he is working with this branch.

When James is confident that the code he created in the branch can be merged with trunk without conflicts and won't break the code, he re-assigns #123 to Robert, asking him to merge the branch with trunk. The architect does this locally (with --reintegrate option), and deletes the branch:

~$ cd /test
~/test$ svn sw ^/trunk
~/test$ svn merge --reintegrate ^/branches/ticket123
--- Merging r594 through r602 into 'php':
U    php/src/application/Model/Auth.php
~/test$ cd php;
~/test/php$ phing -Dto.lint=true
Buildfile: ~/test/php/build.xml
 [property] Loading ~/test/php/./build.properties

test > main:
.... skipped ....
BUILD FINISHED

Total time: 13.7454 seconds
~/test/php$ cd ..
~/test$ svn ci -m "refs #123 - merged branches/ticket123 with trunk"
Sending        .
Sending        php
Sending        php/src/application/Model/Auth.php
Transmitting file data .
Committed revision 603.
~$ svn del ^/branches/ticket123 -m "closes #123 - branch closed"

Committed revision 605.

Robert assigns #123 to Angela and asks her to validate the result of the ticket — whether it was implemented as planned, and whether this implementation satisfies her needs. If there are problems, Angela explains them and returns #123 back to Robert. We go back to Step 2 (James creates a new branch, again!).

Step 6. Closing. Angela is happy with the changes made and closes #123. Robert and James get bonuses :)

That's it.

To make this scenario workable every programmer in the project should install these tools on his/her personal computer: phing, phpUnit, and phpcs

More to read on the subject...

We encourage you to read these articles about source control branching:

Copyright Notice: The article is published by FaZend.com and is protected by US and International copyright laws. You may not republish, copy, reproduce or distribute this article or its paragraphs or elements. You may reference the article in your documentation with a mandatory notice about the authorship of the material. If you have any other privacy concerns about the materials published on FaZend.com website you shall email to privacy@fazend.com.

read all articles...