In a new post to his site Martin Hujer shows you that, with the help of the "script" ability in Composer, you may not need a build tool like Phing. The scripts functionality allows you to execute custom scripts as a part of the Composer workflow, enhancing the management functionality it already provides.

Phing is a great tool (I'm using it as well), but in this article, I want to show you that some projects may not need it. Composer contains a powerful feature called "Scripts", which can be used to create a simple build script.

In his example, he shows how to integrate a run of the PHP_CodeSniffer quality assurance tool as a part of your Composer configuration. This makes it possible to run a command like composer run-script phpcs and automatically run the checks. He then builds on this simple example and creates a more complex build script that still runs PHP_CodeSniffer but also executes PHPUnit tests. He post also shows how to run Composer in a command and how to document each command. There are also a few handy tips included around running Composer on Windows, listing the current scripts and executing custom callbacks to code.

The Master Zend Framework site continues their series covering the creation of a Docker-based testing environment in this second part highlighting the addition of testing support.

In the first part in this series on developing web applications using Docker, we saw how to create a local development environment using Docker; one ideally suited to creating Zend Expressive (or any other kind of PHP-based web application). But, what we didn’t cover was how to handle testing in a Docker-based environment.

[...] How do you run tests when working with Docker containers? After a bit of searching, I found that it’s not that difficult. But you have to use the right combination of commands.

Since unit tests can be run locally if need be (they shouldn't need any resources from the service if they're true unit tests) he focuses on acceptance testing. For his examples he uses the Codeception testing tool. He walks you through the setup of some simple tests based on the "home" page functionality of the Zend Expressive skeleton application. With that in place, he shows the updates that will need to be made to execute the tests from outside the instance via a "docker exec" call. The post finishes with a look at adding two other tools to the mix as well: Make and Phing.

Rob Allen has posted a guide showing you how to make your code PSR-2 compliant with the help of some handy tools, both in and out of your editor/IDE.

Most of the projects that I work on follow the PSR-2 coding style guidelines. I prefer to ensure that my PRs pass before Travis or Jenkins tells me, so let's look at how to run PSR-2 checks locally.

He looks at three different methods - not the only ones out there but three quick to implement ones:

• Using the PSR-2 sniffs for PHP_CodeSniffer
• Automating the checks with Phing
• Editor integration (he shows VIM and Sublime Text)

There's links to the tools mentioned here and screenshots/configuration information showing how to get it set up too.

Stephan Hochdörfer has a quick post showing how he has PHPunit up and working on an HHVM instance. His problem was that the tests were actually executing using the "php" binary, not the HHVM one.

For quite some time we run the unit tests for our libs and tools against PHP and HHVM, at least that is what I thought up to now. As it turns out I missed a minor detail. [...] What happens now is that Phing is executed via HHVM but PHPUnit will still be executed via the PHP binary because the PHPUnit shell script will look for the php binary in the PATH configuration. Since we run HHVM side-by-side with PHP on our Jenkins build nodes I was not able to point /usr/bin/php to /usr/bin/hhvm - which would be the easiest and cleanest solution. I

He shares the workaround he created, creating a symbolic link between the hhvm and php binaries and then executing the Phing task to run the tests. This is being run via Jenkins and uses it's "WORKSPACE" as a container so the main "php" binary isn't overwritten.

In his latest post Stephan Hochdörfer shows you how to define Phing tasks according to the PSR-0 autoloading format. Phing is a PHP-based automation tool that uses an XML configuration to execute a series of tasks.

Before anybody complains: I know that "as of 2014-10-21 PSR-0 has been marked as deprecated. PSR-4 is now recommended as an alternative." - Anyway I still think this little gem makes sense to be shared because a lot of people are probably not aware of it. I recently found out by accident that it is possible pass a task name in PSR-0 style to the "taskdef" task. In the old days you had to use the Java-like dot-style notation like this and also define the classpath to make sure the class could be loaded correct! This is ok if the task resides in the same project. If the task is located in a dependent package loaded via Composer this can get ugly.

The post is quick but provides two very handy code examples, one showing the old "dot notation" version and the other showing how to make use of the autoloader. The trick is in the classname value and using the full namespace/class name rather than the dot notation.

Vic Cherubini has a recent post on his site sharing for free the contents of a book he'd written previously about "Expert PHP Deployments":

In 2013 I wrote and self-published a book titled “Expert PHP Deployments”. While it was not a smashing success, it sold enough copies to pay for itself, and I was happy to have a published book to my name. Unfortunately, I have not had time to market it, update it, or further improve it, so I am giving it away for free. You can read the book in its entirety below or download it as a PDF.

The book covers a wide range of topics related to deploying PHP applications including:

• Environment configuration (setting up Vagrant for the developers)
• Working with the Phing automation tool
• Building deployments with Capistrano
• Creating and configuring a production server
• Ensuring the security of the server
• Making the actual deployment

The post has the full text of the book in one page but you can grab the PDF if you prefer that format.

Rob Allen has shared a few Phing tips in the latest post to his site today. Phing is a PHP-based automation tools most popularly used for the deployment and configuration of PHP applications.

Following on from my last post, here's a few other Phing things that I've found helps me.

He shares three short but useful tips:

• Hiding targets from Phing -l
• Main target vs subtarget
• List available targets by default

Each tip includes the XML markup you'll need to make it functional. You can find out more about Phing and what it's capable of on its website.

In a quick new post to his site Rob Allen shows you how to have Phing SSH into a Vagrant box as a part of the VM creation process. In his case, he uses it to run database migrations.

Now that I've started using migrations, I've discovered a minor irritant. I run this project on a Vagrant VM and have discovered that I keep forgetting to ssh into the vagrant box before running the migrations script. The obvious solution is to automate this and I decided to use Phing to do so.

He walks through the installation of the libssh2 software (if you don't already have it) and the ssh2 PHP extensionSshTask to make the connection as the "vagrant" user and execute the given PHP command.

Lorna Mitchell has a quick post to her site today showing you how to link up Travis-CI and phing to execute the phing build on the Travis-CI service.

We've started using Travis CI on one of my projects to run some build processes to check that everything looks good before we merge/deploy code. One thing I ran into quite quickly was that I wanted to install phing in order to use the build scripts we already have and use elsewhere, but that it isn't provided by default by Travis CI.

To get it all cooperating, she uses the "before_install" settings/functionality Travis provides to use PEAR to discover and install phing. Then in the "script" section, the build can call the phing executable without problems. She does point out one "magic" kind of thing that rehashes the Travis environment and lets to know phing exists: the...well..."rehash" configuration setting.

Lukasz Kujawa has a new post to his site introducing you to deployment of your web-based PHP applications using the Phing build tool.

How many steps are required to deploy your software? Some people say it shouldn’t be more than one. I’m little bit more relaxed about it so I would say two steps are still fine. If it takes more than two then most likely you need a build script. [...] Phing is a PHP project build system or build tool based on ​Apache Ant. You can do anything with it that you could do with a traditional build system like GNU make. It use simple XML build files and extensible PHP “task” classes.

He shows how to get it installed via Composer and how to create a simple "build.xml" file with a few targets inside. He shows how to use the "build.properties" configuration file and how to set them from the command line if needed. He also includes details on doing database migrations using the "dbdeploy" tasks.