till's blog

English: Berlin's PHP usergroup is taking part in PHP's TestFest 2009, on the 9th and 10th May, 2009! The location will be Boxhagener Str. 119, Berlin (Friedrichshain), if you want to attend, please RSVP on our wiki!

Starting it off, I'll give an intro to PHPT-style testing at the monthly meeting of the usergroup in May!

Deutsch: Die PHP Usergroup Berlin nimmt am PHP TestFest 2009 teil. Wir treffen uns dazu am 9. und 10. Mai in Berlin Friedrichshain. Wenn Ihr kommen wollt, tragt Euch bitte in unserem Wiki ein! Wenn jmd. einen Schlafplatz braucht, bitte vorher melden. :-)

Eine Einführung zu PHPT werde ich beim monatlichen Treffen der Usergroup im Mai geben — mehr dazu später!

Disclaimer: I've been doing mostly PHP and Zend Framework based projects in the past two years, but the information from this article is general and should be applicable to most setups — even to non PHP-based projects (to a certain extent).

Inspired by Padraic's posting spree the other week, here's another attempt to provide you with some hands-on usefulness. I'm all open for all feedback, and sorry for the length!

What is deployment and how do you manage deployments?

Wikipedia says:

Software deployment is all of the activities that make a software system available for use.

... and goes on:

The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Because every software system is unique, the precise processes or procedures within each activity can hardly be defined.

In general, there are different approaches to software deployment. Most people are probably not aware of a deployment process at all. They edit files and push it live. In most cases, live (sometimes referred to as production environment) is the webhosting account — for consistency, the environments setup for larger projects also includes a development and staging environment.

Taking the facts into account, we can summarize those efforts into three cases:

1. Deploym..? I'm a skilled surgeon and shell ninja! I like to edit all my files online!
2. I have a local WAMP, MAMP or LAMP and then FTP the files online.
3. We have a defined process and use SVN, PEAR, phing or similar.

Why should I manage deployments?

There are a few reasons as to why it's good for you^TM to come up with a release schedule to manage your deployments.

1. Establishing a release schedule allows you to project the time necessary to implement and test new features and items.
2. Planning in advance also helps to meet the plan.
3. A schedule enables code testing (and other QA measures) before it's live. For example, assuming the schedule says to release a new version every two weeks, the net time (ten business days) could be divided up into eight business days for development, and two business days for testing. (Adjust as needed!) Take note — the schedule excludes weekends!
4. A release schedule helps the development team to avoid all those extra last-minute changes which break things and cause grey hair without feeling bad or guilty. The established practice and process has to be used by all people involved, and developers are not to blame if someone else forgets that.

While I personally agree with some of what Luke Welling wrote in his article "PHP is not Java" for PHP Advent 2008, I also disagree with the general tone of the article and the examples he provides. The example Luke provides might be true in some respects (that it looks like Java code), but the solution offered is the best example why PHP and PHP developers are looked down on most time.

PHP is the red-headed step child (no offense to redheads, I love you all) when it comes to programming, or wait, scripting languages. Because PHP is not even a programming language. ;-) For example, when I started at this co-working place most of the people did not talk to me at all. Besides Jan, who I share the room with most of the time, there are only Ruby (and Java) people on this floor. Horror, right? (Just kidding!)

And even though my crap PHP code handles much more traffic than their fancy rails, and even though I'm open to other languages as well, most people stop taking me serious when I admit to doing PHP.

The truth is out there, Mulder.

The notion of the last years has been that a lot of PHP-based open source projects worked hard to improve the quality of their code by defining coding standards, by improving the documentation and sometimes even by adding a dedicated QA team. Even though any PR is good PR, no one wants to make those headlines. The (by no means complete) list of examples include (of course) PEAR, Joomla (where this is an ongoing effort :-)), and also rather notorious projects such as phpBB and Wordpress.