Brian Swan has posted another tutorial in a series looking at testing applications on the Azure platform. In this latest post he talks about how to automate your PHPUnit tests as a part of the start up of the instance.

In this post, I'll show you how to deploy your PHPUnit tests with your application, have the tests run as a start up task, and have the results written to your storage account for analysis. Attached to this post is a .zip file that contains a skeleton project that you can use to automatically run PHPUnit tests when you deploy a PHP application to Azure. I'll walk you though how to use the skeleton project, then provide a bit more detail as to how it all works (so you can make modifications where necessary).

He has it broken up into a few easy-to-follow steps:

• Download the AzurePHPWebRole zip archive and unpack it
• Copy your application, tests and PHP installation into the resulting file structure
• Create a skeleton "ServiceConfiguration.cscfg" file with the "cspack" command and edit it to change the "osfamily" and "osversion" settings
• Use "cspack" to package up the application and deploy the application

He walks you through the "how it works" steps too - the things that happen for you automatically on the server side to do things like set up the file to log to, configure the PHP environment and execute the "runtests" Powershell file as included in the AzurePHPWebRole download.

Mike Willbanks has a new post to his blog about a different sort of technique for deploying PHP - building your own RPMs instead of just using the pre-packaged ones. This opens up a whole world of customization options.

In the PHP world, one might ask why not just build it from source? Well, an RPM IS built from source and then distributed to many servers - we can ensure that we have the same packages on each, we can maintain the same versions and if you've read my previous post on Pirum you will know that I also like mirroring PEAR packages.

He walks you through the structure of an RPM package (the spec file, with examples, and the source), the "%prep", "%build" and "%install" containers as well as where the source needs to live for things to work correctly.

DevShed concludes their three-part series about building an ORM in PHP with this latest article. It introduces the idea of dependency injection into the mix, showing how it can be used in the relationships between entities.

if you've already read the two installments that precede this one, it's probable that you're familiar with the inner workings of this sample ORM. In those chapters I implemented the ORM's data access and mapping layers, along with a simple domain model. To be frank, the development of this last tier is entirely optional; however, it's useful for demonstrating the ORM's actual functionality in the deployment of a blog program, which naturally will handle some "typical" domain objects, namely blog entries, comments and authors.

They share the code for creating proxy objects and, using a "poor man's dependency injection container" made from a factory method, interfaces and service classes to handle the results.

PHPFog, the PHP-centric platform as a service has made a new post to this blog about two new "gifts" they're providing to developers:

I want to thank you for your interest in PHP Fog. Thanks to you and tens of thousands of developers like you, we have grown massively in the last year and a half. As a sign of my gratitude, I'd like to give you two free gifts.

Their gifts to the community are a conversion of the 6 month applications over to a free-for-life product and you can now deploy three of these "free forever" applications instead of just the one. You can signup here for the service with offerings of installed software like PyroCMS, Drupal 7, MediaWiki and Slim. For more information, you can attend this webinar.

If you're a Zend Studio user and have been wondering how to hook it directly into the phpcloud service from Zend, Kevin Schroeder has posted complete instructions in a new post today (complete with screenshots).

PHPCloud.com is the landing page for our new cloud offering. Using the Zend Application Fabric you can build your applications in the same environment as you will be deploying your apps to. The application is built on my.phpcloud.com and you can then deploy it onto any platform where the Fabric is supported. But how do you get started? Phpcloud.com has been built in a way where you can connect with any IDE. With Zend Studio 9 that connectivity has been built directly in to the IDE.

It's a simple six (well, technically seven) step process that involves setting up a new project, configuring some deployment options and hitting "deploy". Zend Studio makes it super simple to launch your application as many times as you need - a one-click deploy once things are all set up.

On PHPBuilder.com today there's a new tutorial from Jason Gilmore helping you get started with Jenkins for building and deploying your PHP applications. Jenkins (formerly Hudson) can make things "one click simple" for you to correctly push your applications live every time.

Although a Java-based solution, an active plugin community has made it possible to use Jenkins for far more than Java-specific projects. More recently it has become much easier for Jenkins' novices to use the project in conjunction with PHP projects thanks to the work of Sebastian Bergmann. Known as Template for Jenkins Jobs for PHP Projects, the project provides a configuration file which you'll use to enable Jenkins/PHP integration, and supports several popular familiar PHP tools such as PHP_CodeSniffer and PHPUnit.

He walks you through a brief installation of Jenkins (packages on a Debian install) and shows you how to get your git repository, the source for it to pull from) configured and ready to pull. He also includes some other screenshots showing you where to look for the build status, results from past builds and how to get the system to build documentation as a part of the build.

On the "PHP and Me" blog there's a new entry from Pinpin Bysma showing how to use the PHP-based deployment tool Phing to update your production website via an FTP connection, automated by a Phing build.

If you're working on a PHP project, like with any other project, probably comes a time when you need to "build a new release," e.g. update the production web site with the latest version of the code. And doing the whole thing manually isn't the most efficient way to get things done, especially if you're lazy, or have to do that every once in a while, over a long period of time. [...] Obviously if updating the site itself could be done without FTP but through a simple svn switch, things would be easier. Still, Phing would allow to make things easier just as nicely. It could for example still be used to create the new tag, trigger the switch, etc

He introduces the process by showing a basic Phing build file that uses the PEAR VersionControl_SVN component to get the latest from the repository and push it to another directory. There was one thing that he wanted to do that the default SVN task couldn't - export the difference between two tags. To make this happen, he had to extend Phing and make a new task - SvnExportDiff. He includes the code for this new task and an updated build file to show it all in use - complete with the FtpDeploy to push the code live.

On NetTuts.com there's a new tutorial showing you how to deploy your WordPress blog to the cloud, more specifically to the cloud services Amazon offers.

For the last decade, hosting a large scale web application has been a daunting task, reserved only for experts. Not anymore; when Amazon opened its server architecture, everything changed. Computer hardware moved to the cloud, and became available to any and all developers. In this tutorial, we will install WordPress in the cloud.

They walk you through all the steps you'll need - from setting up an AWS account, starting up your first instance and installing the needed server software. It comes complete with screenshots. They also show you how to set up the database and how to pull down the latest WordPress and configure it for use.

On the Linode Library there's a recent tutorial posted about deploying Drupal sites (high performance ones) out to production server with the help of Project Mercury StackScript Linode offers.

This high performance Drupal system is based on the work of Project Mercury. Project Mercury aims to increase the performance and ability of Drupal powered websites to respond to increased load. This document leverages the same collection of popular open source tools including the Varnish Accelerating Proxy, the APC bytecode cache for PHP, Memcached for accelerating database operations, and the Solr search engine.

The tutorial shows you how to get the software you'll need installed, and includes details on how to configure each of them for maximum performance - Drush, Apache, Varnish, Solr, Pressflow and, of course, Drupal. All software is installed via packages to make things much simpler and snippets of configuration files and commands are included to make the setup relatively painless.

Dan Field has a new post to his blog today about deploying PHP applications "The Red Hat Way" - as a single RPM package that can be dropped into any RedHat system and installed easily.

Red Hat is one of the largest Linux distributions in the enterprise market and there are a multitude of other RPM based distributions such as CentOS, Fedora, Mandriva, SuSE. Many people are deploying their web projects into RPM based environments and it makes a lot of sense to try to do things the "Red Hat Way". This post deals with introducing the Red Hat filesystem layout and automatically deploying a web application into it with the RPM package management tool and a YUM repository.

He shows how to build the configuration files, making a build properties file, creating the Apache configuration, setting up a config for the VirtualHost to be added to the Apache install and finally, building the tarball package and making it into an RPM.