Using annotations in Prooph

One of the things I love about Java is its native, compiler-level support for annotations, a form of syntactic metadata which can be applied to source code but also retain at run-time to influence application behavior. I use them almost daily in my projects.

I do a fair amount of consulting and development on event sourced applications and these usually use Axon, a popular CQRS & event sourcing framework. Recently, Axon version 3 was released, supporting a number of annotations that can turn any POJO (Plain Old Java Object) into an event-sourced aggregate.

The annotations in Axon inspired me to experiment with adding support for similar annotations to prooph, a PHP framework which I occasionally reference in my PHP conference talks and consulting. This experiment is now available online as a PHP package, on GitHub: https://github.com/prooph/annotations. It works with the last versions of the core prooph components.

The package, like Axon, introduces a number of annotations which allow you to turn any regular PHP class into an event-sourced aggregate. Unfortunately, annotations are not natively supported in PHP. They are written inside documentation blocks and require an additional parser to get working (in the case of my package, Doctrine Annotations). The following example snippet shows how these annotations are applied:

@CommandHandler helps to get rid of some of the boilerplate code usually associated with command handlers in prooph (see this example). @EventHandler turns any annotated function into an event listener.

Let me know what you think!

The road to continuous deployment (PHPCon Poland 2016)

Below are the slides of my talk “The road to continuous deployment: a case study”, as presented at PHPCon Poland in October 2016.

It’s a situation many of us are familiar with: a large legacy application, limited or no tests, slow & manual release process, low velocity, no confidence…. Oh, and management wants new features, fast.

But how to proceed? Using examples and lessons learned from a real-world case, I’ll show you how to strangle the legacy application with a modern service architecture and build a continuous deployment pipeline to deliver value from the first sprint. On the way, we take a look at testing strategies and various (possibly controversial!) tips and best practices.

Docker & PHP: beyond virtual machines

(note: this post was first published on the blog of the Dutch Web Alliance)

Docker is currently one of the hottest technologies around, because it solves a very specific problem: the ability to easily package and deploy a (self contained) application, without the overhead of traditional virtualization solutions.

In this post you’ll learn how to build, run and host Docker containers, integrate with other containers, and see how Vagrant interacts with Docker.

Read more

Using conditional build steps to speed up your Jenkins PHP builds

At my client Spotney, we have a pretty solid (and common) build infrastructure for our PHP projects; SVN commits are checked out by Jenkins, tests are run by PHPUnit, Sonar runs static code analysis, and artifacts are built and deployed to a staging environment by Phing. However, some of the code relies pretty heavily on (complex) db queries, adding the need for DbUnit style tests. The nature and quantity of the tests, combined with a slow VM (possibly related to this Xdebug issue) meant that our buildtimes were becoming prohibitively long.

An interesting post by @pascaldevink triggered a conversation and sparked an idea. I started working on our build setup, eventually resulting in a 60-70% decrease of our build times!

Here’s how I did it.

Starting point

Let’s assume we have a fairly standard Jenkins job. The job checks out an SVN repository, and periodically scans that repository for changes, triggering a new build if any are detected.

Each build of the job performs three steps:

  • Run phpunit
  • Run phing (target “build”)
  • Invoke Sonar (using the Jenkins Sonar plugin – this plugin also allows invoking Sonar as a post-build action, but that option requires Maven)

After the build steps, the job publishes the test and code coverage reports, and archives the generated artifacts.

Disabling code coverage and Sonar for regular builds

Two of the most obvious optimizations (also suggested by Pascal) are disabling code coverage on all tests and disabling Sonar runs during regular Jenkins builds. We define regular as either manually started by a user, or by an SCM trigger.

Disabling code coverage generation in PHPUnit is easy, simply remove the “coverage-xxx” elements from the logging section of your phpunit.xml configuration file (see this section of the PHPUnit manual). Disabling Sonar is trivial too, just remove the last build step from the job.

However, this is not an ideal solution: we do want to generate code coverage information and run Sonar at some point, such as during nightly builds, preferably without cloning our existing job. This means that we’ll need to skip code coverage and Sonar invocations on all but the scheduled (nightly) builds.

The Sonar plugin supports excluding SCM triggered builds (“Skip if triggered by SCM Changes”), but that only works if you use the post-build action. Additionally, we need to be able to change the PHPUnit configuration – one file to enable code coverage generation, one file to disable it.

Conditional build steps

The Conditional BuildStep plugin wraps one or more build steps in a conditional execution block. One of the possible conditions is the build cause, i.e. was the build triggered by a user, an upstream project, a timer, an SCM change, etc. etc.

First we define the steps that should be taken for each nightly build of our job. These steps should only be executed when the build is trigger by a timer.

We add a “Conditional steps (multiple)” build step, setting the condition to “Build Cause” and the Build Cause to “TimerTrigger”.

Conditional Sonar Build Config [Jenkins]2

Then we add our three (original) build steps:

Conditional Sonar Build Config [Jenkins]3

As stated before, regular builds are those that are triggered by a user or an SCM change.

We again add a “Conditional steps (multiple)” build step. The condition for this step is a little more interesting, as seen below. We combine two Build Cause conditions (one set to “UserCause”, the other to “SCMTrigger”) using the Or condition.

Conditional Sonar Build Config [Jenkins]4

We then add two build steps: the first will run PHPUnit without code coverage (note that we are specifying a different configuration file here), the second one will run Phing.

Conditional Sonar Build Config [Jenkins]5

Note that in the above build steps we’re invoking Phing from the shell instead of using the Phing plugin. Unfortunately this plugin is currently not supported as a conditional build step (probably because of this JIRA issue).

Build schedule

As a final step we need to update our build schedule.

Conditional Sonar Build Config [Jenkins]1

This will ensure our job runs somewhere after midnight (between 12:00 AM and 2:59 AM to be precise).

The end result:

  • A nightly scheduled build, with all the bells and whistles enabled
  • User and SCM triggered builds run (a lot) faster

Please let me know if you think this post is useful, or if you have any other Jenkins/PHP optimization tips!

Phing development update

It’s about time I wrote another Phing development update post, as the previous one  was written 6 months ago!

So, what have we been up to ?

Release 2.5.1

Unfortunately, because of other commitments, the 2.5.1 release has been delayed a little and should hopefully be pushed out later this month.

Here are some of the issues that have already been fixed for this release:

Ticket Summary
#920 Load phpdepend dependency only when they are used
#966 phing unit tests nice on all platforms
#970 FileSyncTask missing from docbook5 documentation
#981 FileUtil::copyFile(): $preserveLastModified causes empty symlink target file
#985 Git Commit Task missing from docs
#990 Prompting for a property value when it is not set results in a repeated input message
#993 ExecTask passthru will redirect stderr
#999 phing-2.5.0.phar Can’t load default task list
#1000 Make phing.phar work out of the box
#1003 2 php syntax bugs in GitCommitTask
#1004 <gitcommit …/> does not work because task definition is missing in defaults.properties + another bug
#1011 Problem with spaces in output redirection path
#1015 phing does not allow phpunit to echo
#1020 [PHP Error] Illegal string offset ‘filename’ [line 149 of /usr/share/pear/phing/tasks/ext/ExtractBaseTask.php]
#1023 Argument 1 passed to IniFileTokenReader::setFile() must be an instance of PhingFile
#1027 RegexpMapper uses deprecated PREG_REPLACE_EVAL
#1029 PhpDocumentor2 task broken with latest phpdoc version

 

DocBook manual

A number of awesome pulls by johan162 updated our docbook manual (which has been in the works for some time) to a viable alternative. Next on the list are a few infrastructure issues and styling changes, after that the current manual will be ready to be replaced by our shiny new docbook version 🙂

Details:

Other changes

For more in-depth information, see the list of recently closed pull requests and the list of commits.