Dear PHP Community, we need to have a talk about the insufferable state of your software stacks. It was recently brought to my attention that there is software out there, software we use every day!, that is NOT written in PHP. This is completely unacceptable! We are PHPeople! We're not "Web" Developers, we are the web. And we sure as hell are not some fancy "Software Developer", you can ask anyone on the internet! Seriously: If it's not PHP how will we ever be able to extend and adapt it to our needs! We are slaves of our tools!

He mentions several tools that, yes, while not written in PHP are very useful to just about any developer out there (including git, Puppet and Apache). But, more seriously:

PHP is a language that enables absolute beginners to start creating on the web using FTP and notepad! It let's us realize and validate our ideas blazingly fast and allows us to adapt our successful ideas to beautifully scale with our requirements providing and relying on solid, battle-proof tools.

It seems that many people talk about setting up a continuous deployment system but few actually take the plunge and make it a reality. I've recently set up continuous deployment for an API project at work and thought I would blog about how I got it all to work.

He starts by laying out the plan for the system and what it's intended to do (an excellent first step). This is followed by details on Capifony and what kind of advantages it offers for deployment. He shares the full contents of his "deploy.rb" file that includes the actual steps for the deployment including a git checkout, a Composer install, warming up the Symfony cache and restarting Apache. He also includes how they have it set up with Jenkins, having the build triggered when the main project's build completes successfully.

I've been using Jenkins to manage builds of my projects for a while now. This was fine for a while, but now that my projects need to support multiple versions of PHP, it left something to be desired. I wanted a system that could build against multiple versions of PHP. And more so, I wanted to be able to build against multiple compiles of the same version (different options, etc). This is how I built just such a system...

He gives an overview of the Jenkins system, the hardware and operating system that runs the server as well as examples of his "php-build" command to generate the different environments. He uses a modified version of the PHP template for Jenkins as a base.

Though it's still early to guarantee that the PSRs will be widely adopted as the de facto standard for writing serious PHP applications, it is interesting to note that a code sniffer and fixer that looks for code deviations was developed by nobody less than Fabien Potencier, the creator of the Symfony framework. (Et bien, ils ne sont pas fous, ces français!) In the rest of the article we shall find out what his PHP-CS-Fixer does and how can it be integrated with a CI tool like Jenkins.

He shows how to install a tool that can help you keep your source in compliance - the "fixer" (created by Fabien Potencier) to help correct the problems found in your code. He includes the command line calls you'll need to run the tool on your code and how to add the step to your build.

This article is about how to use Phing in your projects, so a continuous integration server (in this case artifacts for your php application (deployment artifacts, documentation, code metrics, etc). I'll try to show why this will make your life easier when developing or auditing code, generating releases and deploying new versions, trace bugs, etc. All with just a handful of phing tasks.

He introduces the Phing tool and explains how it makes automating the steps of your process simpler, relating it to the Apache Ant tool for those familiar with it. He links to several of the resources used in the process including PHPLoc, DocBlox and the code for the article itself. He outlines the process and, complete with a screenshot of the final result, shows you how to get everything configured and running smoothly.

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.

What Jenkins does is not difficult to understand once you know why it does that. In this 2-part series I'll present a big-picture overview of the sort of programming problems CI can solve, show how it can be achieved with the help of specialized software and explain how Jenkins can be minimally used to periodically trigger testing and building of PHP (web)applications, keeping a record of where integration succeeded or failed and maintaining an "output" folder up-to-date with the latest files that the application requires, ready to be uploaded to the server.

He uses a story to illustrate the usefulness of a Jenkins CI server, telling about different people working on different parts of an application and the differing decisions they all make about the code. He talks about how, with the help of a CI server, they could have avoided "integration hell" when they tried to bring their work back together and how things like version control, unit testing and automated builds could help.

There's brief instructions at the end to be sure you have two things set up before continuing on with the rest of the series - git for version control and ant for the build process.

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.

I'm exploring an approach to automated code review: it's not as precise as the human-based one, but it scales better. [...] All in all, automated code reviews, performed with tools instead of with human intellect, can be a starting point to search for the problematic zones of a codebase. Then the human may come in, since they also have to clean up the code: their intervention was already scheduled.

The tools he mentions (and, in some cases, shows how to install/use) are:

• PHPUnit
• PHP_Depend
• PHP_CodeSniffer
• PHP Mess Detector (pmd)
• the Jenkins job template

People using PHP that want API documentation usually automatically think of phpDocumentor, which used to be the de facto standard for generating API documentation from your PHP projects. However, the project has been dormant for a long time now and definitely does not support new PHP features such as namespaces, so it was really time to look for an alternative. In this blogpost, I'll show you how I set up my Jenkins CI to use DocBlox, one of the new API documentation generators currently available.

The DocBlox project is in active development and supports additional things in top of the current feature set phpDocumentor includes. Stefan gives you the exact XML you'll need to include in your Jenkins build file (and the phpDocumentor line it will likely replace) that builds out the documentation to a given path. He's given an example of his full build file to give you some context too.