Travis - Beginning

travis - it's a service for automated code testing. It's integrated with GitHub, supports many languages and libraries. This time, we're interested in PHP and the PHPUnit tests. It's very convenient to have such an instrument while developing an open source library, because other developers don't need to run tests locally, everything will be available on Travis. I'm going to show how we can add a library to travis-ci.org, and for this purpose I'm going to use 4devs/blog.

The most important thing is that your code must be covered with tests and those tests must be green. We need to register on travis-ci.org. You can do it only via GitHub. Travis is integrated with Github and you can't use it with other similar services.

Let's create the `.travis.yml` file in the root directory of our project (you can also check other examples of the travis.yml file):.

language: php

php:
  - 5.4
  - 5.5

matrix:
  allow_failures:
    - php: 5.5

env:
  global:
  matrix:
    - REQUIRE=no-dev
    - REQUIRE=dev

before_script:
  - mkdir app/cache
  - chmod 777 app/cache
  - cp app/config/parameters.yml.desc app/config/parameters.yml
  - echo "extension = mongo.so" >> ~/.phpenv/versions/$(phpenv version-name)/etc/php.ini
  - composer self-update
  - composer --${REQUIRE} --prefer-source install
  - app/console doctrine:mongodb:fixtures:load

services: mongodb

script: phpunit -c app/

The language directive tells Travis what language we use, in our case it's PHP.

php - supported versions. In the example above we support only 5.4 and higher, so tests will be run for each version separately. It's also possible to use another configuration:

php:
  - 5.3
  - 5.4
  - 5.5

(the tests will fail under the 5.3 version, because we have uncompatible changes in our project).

matrix - allows to run tests under different configurations. The allow_failures directive means that if the tests fail under php5.5, they won't affect the global test status.

env - our working environment. I use matrix here to run tests under different composer installations. I don't have any global variables, but you can add them (use space as a delimiter). For example: REQUIRE=no-dev USE_NETWORK=true You can read more about them on travis. The global parameter has almost the same meaning as matrix, the difference is that it will be used in all builds.

before_script - here we can add all actions we want to perform before tests (one on a line). For example, here you may add the project installation, cache cleaning if needed, installation of additional libraries. You can also use the variables defined before. We have echo "extension = mongo.so" >> ~/.phpenv/versions/$(phpenv version-name)/etc/php.ini - installation of the additional PHP library. We need this because not all of them are enabled by default. You can check the full list here.

script: phpunit -c app/ - this way we run our tests using Travis. PHPUnit is pre-installed. I have PHPUnit globally installed on my local machine, so I also run tests from the root directory of the project.

Conclusions

There will be 4 runs: php 5.4 in dev, php 5.4 in prod, php 5.5 in dev, php 5.5 in prod. They will be tested, and the tests under php 5.5 won't affect the result.

Travis is not only useful for you, but for people who use your libraries, too. You can test your code in different environments, you can also check if your code works well under newer versions of your language and only then migrate to them.

This example is real and you can check the result . This was short intro, if you want to learn more, please refer to the Travis official docs.

See also:

How to Use a Custom Storage Layer in FOSUserBundle

Almost each Symfony project uses FOSUserBundle because it speeds up the development and provides useful features to manage users. It has a few built in storage layer implementations: one for Propel and a few for Doctrine (both ORM and ODM). It's great, but there are some cases when you have to use another storage. Luckily, FOSUserBundle is flexible enough and provides a way to implement a custom storage layer.  You just need to implement your own user manager to use all features of FOSUserBundle.

Paysera Symfony2 Integration

It's a common need to integrate a payment gateway into a project. Even though there are many well known systems and aggregators like PayPal, RBKMoney, Paymentwall, Robokassa and so on, I want to talk about Paysera. It's another quite new payment system. They claim to have low commission fees for a convenient and wide range of services. Paysera allows your users to pay via cards and SMS. Integration is quite easy, but has some unclear moments during the process that I want to point out.