🚥 どのようにワークフローのコード品質チェックを自動化するには?⚙

Using the CLI to manually check your code is cool (really? 🤔), but not very productive. Let's automatize ⚙ that a bit!

Check the code in the editor is good, but do it before pushing to git is better!

Git comes with a set of hooks that you can use at many steps of the workflow (pre-commit, pre-push, post-update...). A git hook is just a script that will be executed before or after a particular event. It can be a shell script, a PHP script, a perl script, a python script or whatever scripting language. It can even be a binary. It just needs to be an executable.

Here is the list of all available hooks:

In , I introduced three tools and how to automatize their installation within Composer. This way, each developer can install them just by running composer install at the project's root.

But how to ensure that each of them will use them each time they modify a single line of code? Fortunately, Composer comes also with a set of hooks allowing you to automatize some of your tasks.

Thus, instead of manually creating a pre-commit script for every developers, the idea is to put the script somewhere in your codebase (e.g. in /contrib ), and to ask Composer to install it automatically when installing or updating your project.

Just add a new section in your composer.json :

{
    "scripts": {
        "post-update-cmd": [
            "mv .git/hooks/pre-commit .git/hooks/pre-commit.bak",
            "cp contrib/pre-commit .git/hooks/pre-commit",
            "chmod a+x .git/hooks/pre-commit"
        ],
        "post-install-cmd": [
            "mv .git/hooks/pre-commit .git/hooks/pre-commit.bak",
            "cp contrib/pre-commit .git/hooks/pre-commit",
            "chmod a+x .git/hooks/pre-commit"
        ]
    }
}

That way, anytime a dev will be running composer install or composer update , the script will be installed.

The goal of the quality control in the CI/CD pipeline is twofold:

• first check the whole codebase against your project's quality rules, and break the build in case of any error (like a unit test would do)
• (optionnally) perform a deeper analysis and publish a detailed build report that can be consulted by the devs at any time

Of course, it doesn't make sense to use a fixer ( phpcbf , php-cs-fixer ) in the pipeline as it would modify the code after it has been pulled from the repo, and we don't want the code to be modified without any control of the devs.

⚠ Checking your whole codebase will have a significant impact on the build time. It can vary from few seconds to few minutes, depending on your code size.
For your information, on a 40 000 LoC project, it takes approximately 5 seconds for phpcs and 40 seconds for phpmd , with a relatively «light» analysis.

Regarding the deeper analysis, we'll use phpcs and phpmd to raise errors/warnings and to publish the results, either in «human-readable» reports for devs (e.g. on a static website) with a notification in Slack, or in a standard format ( junit , checkstyle , other...) to be integrated in a statistics tool like Sonar or PhpMetrics .

Here is a simple example of a gitlab-ci's pipeline allowing to build, test & check a PHP app and to publish the reports to gitlab pages:

image: composer

stages:
  - test
  - deploy

test:app:
  stage: test
  script:
    - apk add --no-cache $PHPIZE_DEPS
    - pecl install xdebug-2.6.0
    - docker-php-ext-enable xdebug
    - composer install
    - ./vendor/bin/phpunit --testsuite=unit --coverage-text --colors=never --log-junit reports/phpunit-junit.log --testdox-html reports/phpunit-report.html
    - ./vendor/bin/phpcs -sw --standard=phpcs_squiz.xml.dist src --basepath=. --report=full --report-file=reports/phpcs-report.log || echo "ok"
    - ./vendor/bin/phpmd src html phpmd.xml.dist --reportfile reports/phpmd-report.html --ignore-violations-on-exit
  artifacts:
    paths:
      - reports
    expire_in: 30m

pages:
  stage: deploy
  dependencies:
    - test:app
  script:
    - mkdir public
    - cp ci/pages/index.html public/
    - cp reports/* public/
  artifacts:
    paths:
      - public
  only:
    - master

There are many frameworks to manage the git hooks. Some of them are language specific (Node.js, PHP, Go, ...), and some others are language agnostic. They support many types of stacks. Just pick yours!