Suppose you have a web application that is installed on many hosts. Each installation may have a custom configuration, and the application is still in active development. You need an easy way to deploy new features and bug fixes to all of hosts. [...] In this article I show you how to use this knowledge [from this previous article] to write a boilerplate build file, one that can be customized and reused in your real-world applications. We'll use Phing's Subversion tasks to manage the repository and the FileSync extension to synchronize your local installation with a remote server.

He helps you to get the environment set up correctly (installing the needed PEAR packages), create a basic build file with the FTP settings in it and creating a "deploy" target to do the work. He also shows the settings/configuration involved in a "prepare" target that does the SVN work to do some of the pre-push work. Finally, he shows a "release" target that bundles up the files into a package and pushes it up to the server (via FTP).

Roughly a month ago I posted the first in, what should become, a series of development updates concerning Phing. This second blog post details the most important updates during the past four weeks as Phing is moving steadily towards another release (2.4.10 is due out next week).

Updates mentioned in this post are:

• User Guide starts move to DocBook format
• Liquibase docs
• PhpDocumentor
• PHP 5.4 compatibility
• PHAR package
• Various (bug)fixes, the 2.4.10 release (listed)

Check out the full post for more details on each of these topics.

In the first part of this article I presented the case for Continuous Integration. Now we'll install and set Jenkins up to monitor the automatic building of a simple demonstration PHP application. We'll begin with the demo project, then address Jenkins' installation, and finally set it up and watch it running.

He includes a sample project structure, complete with a PHP class and its tests. He shows how to manually run things first (so you'll know what the commands do), the contents of the class/tests and the example Ant configuration file. He's also included screenshots of the Jenkins interface, showing how to create a build, add a new step and let the build run to evaluate the results.

Here is a quick step by step guide on how to get mongodb and PHP5.2 mongo pecl extension going on your MacOSX in 32bit mode! NOTE: 32 bit mongodb binaries have 2GB address space limit so you wont be able to process too much on your laptop. You will still be able to code and connect to remote instances just fine.

His process includes five steps - well, eight if you count the optional "install MongoDB" ones too - complete with the commands you'll need to get things compiled, ready for copy and paste. You can find the MongoDB PECL package here.

Phing is a PHP project build tool based on Apache Ant. A build system helps you to perform a group of actions using a single command. [...] Phing helps overcome [human error] issues by automating tasks like running unit tests, applying database changes, deploying application code, etc. In this article I'll show you some of the basics of working with Phing.

He includes the commands you'll need to install Phing (if it's not already) via the PEAR installer and a basic "build.xml" file. He explains the parts of the file - tags for "project", "target" "echo" and "property - and includes a more complex build example with multiple targets (and how to call one specifically from the command line).

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.

I have been tinkering with CLANG's static analyzer lately. This post summarizes how I installed LLVM and CLANG and performed the analysis of a build of the PHP interpreter.

He includes all the commands (unix-based) to get the clang tools/libraries installed in the correct places as well as what to add to your $PATH to get the "scan-build" command to work with the make and make install parts of the PHP compile process.

To integrate your project with travis the only thing necesarry is to have a .travis.yml file and a working PHPUnit test setup like http://github.com/simplethings/SimpleThingsFormExtraBundle. Where the Tests/vendors.php script is executed before the tests are perfomed. But it would be way cooler to just have Composer handle the autoloading and dependencies.

A sample .travis.yml file is included in the post (also here) as well as instructions for grabbing dependencies and including the autoload process in your application's bootstrap.

Vagrant ia a tool for building virtual machines (in VirtualBox's format) that conforms to a specification. It's written in Ruby, but it makes really no assumptions over the environments that you're gonna build; in this article, we will setup a virtual server for PHP applications running inside Apache.

The end result is a virtual machine based on VirtualBox images and can be built in a few easy steps:

• install the vagrant gems on the build system
• add a new virtual box instance pointed to a .box file
• create the Vagrant config (including the commands to run post-create)
• set up a little port forawrding
• creating a phpinfo file and starting up Apache

One suggested place for grabbing images (some with pre-defined software) is Bitnami's "Stacks" repository.

Continuous integration is one of these topics that had a slow start, but in recent years has really taken off. The slow start is likely to be attributed to the fact that it was perceived as hard to setup and maintain. But solutions around Jenkins and Sismo are making it easier and easier. But thanks to the new Travis CI service, its now essentially so easy that there is no excuse not to use CI for PHP projects, at least if you are hosting your OSS code on github.com. What makes this service so crazy cool is that you can run your tests against multiple PHP versions, multiples databases (heck even RabbitMQ) and against multiple versions of various libraries.

Thanks to the "first class" PHP support they offer, setting up a PHP project is as simple as creating a ".travis.yml" file in your github-based project (including PHP versions to test against, dependency management and "before script" tasks to execute). If you're looking for a CI platform without a lot of the hassle involved in the usual setup, you'd do well to check out Travis CI.

You can also see another example of a project setup in this post from Travis Swicegood.