Hoa Apex'14, how do we ensure code quality?

Logo of Hoa


Who am I?

Ivan Enderlin:

ivan.enderlin or hywan ••@ { hoa-project.net•,•• atoum.org inria.fr php.net••

Code matters

Anything we do inside Hoa is coding

We have to ensure code quality because:

How to ensure Quality Automation (QA)?

The (In)glourious Basterds

  1. Git and Bhoat maintain the source code
  2. Marvirc helps us to be notified
  3. atoum and Praspel for the tests
  4. the mystery guest for the obvious next step


  1. Repositories
  2. Bhoat
  3. Marvirc
  4. Praspel and atoum
  5. mystery guest
  6. Rolling-Release


Version control

Git is a Distributed Version Control System

List of repositories at git.hoa-project.net, based on cgit:

So far, we mainly care about Library/*


General rules:

Election of commiters is based on their importance in a project



Bhoat is the bot that maintains all the repositories:

All in realtime!

Inside Bhoat

Bhoat is a set of commands integrated in Gitolite:

$ cat Gitolite/local/hooks/repo-specific/post-receive-library
gitolite bhoat/library-into-central "$libraryName"
gitolite bhoat/mirror "$GL_REPO"
gitolite bhoat/archive "$GL_REPO" "$GL_REPO/$libraryName" "/Hoa/$libraryName/"
gitolite bhoat/irc "Library Hoa\\$libraryName has been updated"'!'

No more hands

Repositories are no longer managed by-hands, everything is done by Bhoat


The depressive bot

Marvirc is a dead simple, extremely modular and blazing fast IRC bot (yup, that's it)

$ marvirc join --socket    chat.freenode.org:6667 \
               --username  FakeMarvirc            \
               --channel   '#hoaproject'          \
               --websocket &
$ echo 'You are awesome :-).' | hoa websocket:client --server

100% Hoa

Praspel and atoum

Cartography of test

Size of the system unit component integration system Conception support black box white box Type of test functional robustness performance usability

Where are they?

In a library:

Praspel + atoum = ♥︎

atoum is a simple, modern and intuitive unit testing framework for PHP!

Praspel is a specification language based on contracts

The atoum/praspel-extension introduces Praspel inside atoum:

Like a phoenix


$ hoa test:generate --classes Hoa.Math.Util
$ hoa test:run --namespaces Hoa.Math

State of test migration

Concretely started few weeks ago

We must focus on the most popular libraries at first

Existing tests are mostly integration ones, easy to migrate

Writing contracts are more difficult and automatic generation needs maturation, so it implies patching Hoa\Praspel often (which is good)

Before going further in the migration, we need another tool…

Le Comte Intatto

Hello Gentlemen

C.I. stands for Continuous Integration and Comte Intatto:

Le Comte Intatto ensures the integrity of the source code:

Under the hood

100% Hoa, highly based on FPM (Fast Process Manager, a FastCGI frontend of PHP)

Le Comte Intatto is composed of 2 parts:

  1. a primary, the front-end, responsible to receive jobs and dispatch them
  2. standbys, responsible to execute jobs appropriately

The primary is located on ci.hoa-project.net

The standbys are located anywhere, for example inside virtual machines

Testing environments

Here is the matrix OS × PHP virtual machines (interpreters):

Add all version numbers (possibly exhaustively, e.g. PHP5.5.4, PHP5.5.5, PHP5.5.6, PHP5.5.7 etc.) to specific configurations and it becomes crazy!

How to automate the building of all these environments?

Building virtual machines

Le Comte Intatto provides scripts to automatically…

build virtual machines, based on Packer:

provision virtual machines; basically:

The big schema

                          primary-side . standbys-side
        payload                        .
           +                           .
           |                           .   +-----------------+    +-----------+
           v                           .+->|  standby (VM1)  |+-->|  workers  |
     +-----------+      +------------+ .|  +-----------------+    +-----------+
     |   hook    |+-+-->|  worker 1  |+-+
     +-----------+  |   +------------+ .|  +-----------------+    +-----------+
read |           |  |                  .+->|  standby (VM2)  |+-->|  workers  |
+--->|  primary  |  |   +------------+ .|  +-----------------+    +-----------+
     |           |  +-->|  worker 2  +--+
     +-----------+      +------------+ .|  +-----------------+    +-----------+
                                       .+->|  standby (VM3)  |+-->|  workers  |
                                       .   +-----------------+    +-----------+

A payload is posted on the hook API

The hook registers a new job and a primary worker is created

The fresh primary worker dispatches the job to all standbys

A standby prepares a workspace to execute the job

The job is finally executed inside dedicated workers per PHP virtual machines

Some details

All details on the wiki

Workers are created by Hoa\Fastcgi and Hoa\Zombie to turn them into daemons

Communication between all workers and the primary is ensured by Hoa\Websocket (realtime outputs on the primary)

Support payloads from and report statuses to Github (excellent for Pull Request):



Life cycle of a library

  1. first of all, it is in the beta state
  2. after some works, it is growing into the RC (stands for release candidate)
  3. after some intensive feedbacks, intensive tests and many incubation months, it is growing into the finalized state

Once it has reached the finalized state, its release cycle starts

Why rolling release?




Each library has 4 branches:

  1. development, receives all the new patches
  2. incoming, when all tests passed and every reviewers agreed, development is merged into this branch
  3. staging, manual merge from incoming, will be tested and reviewed by external users (complementary to our test suites)
  4. master, when staging is considered as safe and valid, it is merged into this branch

Central only receives patches from masters

To sum up:

  • development is like the “trunk”, private branch
  • incoming is like the “alpha channel”, private branch
  • staging is like the “beta and RC channels”, protected branch
  • master is the public branch

Part- & true-rolling release



However, some softwares (like Composer) need a version; what solution?

Scheduled-based release

Mixing part- and true-rolling release with scheduled-based release

Semi-automatically versionned release:

Version format Y{2,4}.mm.dd (starting from 2000, “RR Epoch”):

Backward compatibility

We are not infallible

Sometimes, we can break backward compatibility (never happened but we have to face it)

master must have a compatibility number x, starting from 1 with step of 1

New version format x.Y{2,4}.mm.dd:


Are you ready?

Thanks! ☺︎