Site icon WP-E (仮)

フォローアップ – WordPress テーマの継続的インテグレーション #wck2016

Megumi Hano

どうも、featherplain こと Hinotan です。WordPress のカンファレンス WordCamp Kansai 2016 で 「WordPress テーマの継続的インテグレーション(CI)」 という、割りとニッチな話をしてきました。

以下の内容はセッション中やスライドで触れなかったことだけをかいつまんで書く形になるため、スライドを見た前提で進んでいきます。スライドとあわせて読んでいただいて、少しでも参考になれば幸いです。

テストツールの導入について

スライドの中盤あたりで紹介をしている PHP CodeSniffer (PHPCS) や WordPress Coding Standards, PHP Mess Ditector (PHPMD) は Composer 経由でインストールできます。もちろん単体でインストールもできますが、Composer の方が管理が楽なのでオススメです。

Composer

Composer は PHP の依存関係解決ツールで、Node.js に対する npm のようなイメージです。詳しくはこちらのスライドを参考にするといいでしょう。

インストールはグローバルインストールと、特定のプロジェクトのみのローカルインストールの両方できます。公式のドキュメントにインストール方法が載っているので読めばすぐにできるかと思います。

使い方

npm の package.json にあたる composer.json に下記のような記述をしていきます。少しずつ抜き出して見てみましょう。

{
    "name": "featherplain/amethyst",
    "authors": [
        {
            "name": "Megumi Hano"
        }
    ],
    "require-dev": {
        "squizlabs/php_codesniffer": "2.*",
        "wp-coding-standards/wpcs": "2014-12-11",
        "phpmd/phpmd": "@stable"
    },
    "scripts" :{
        "post-install-cmd": [
            "php vendor/bin/phpcs --config-set installed_paths vendor/wp-coding-standards/wpcs/"
        ],
        "post-update-cmd": [
            "php vendor/bin/phpcs --config-set installed_paths vendor/wp-coding-standards/wpcs/"
        ],
        "test": [
            "php vendor/bin/phpcs -p -s -v -n . --standard=./codesniffer.ruleset.xml --extensions=php",
            "phpmd template-parts,inc,404.php,archive.php,comments.php,footer.php,functions.php,header.php,index.php,page.php,search.php,sidebar.php,single.php text phpmd.ruleset.xml"
        ]
    }
}

require-dev にインストールしたいパッケージを指定して、

$ composer install

すれば、Composer がよしなにやってくれます。

さらに、 scripts に実行させたいスクリプトを記述します。ここでは test に PHPCS と PHPMD の実行スクリプトをまとめて記述して、

$ composer test

でテストを実行します。

Lint 系ツール

私の場合、sass-lint と jshint は gulp で実行しました。それぞれ gulp-sass-lint と gulp-jshint があります。もちろん scss-lint に対する gulp-scss-lint もあります。

var gulp = require('gulp'),
    $    = require('gulp-load-plugins')({ pattern: ['gulp-*', 'gulp.*'], replaceString: /\bgulp[\-.]/})
;

gulp.task('test:sass', function () {
  return gulp.src('src/scss/**/*.scss')
    .pipe($.sassLint())
    .pipe($.sassLint.format())
    .pipe($.sassLint.failOnError())
});

gulp.task('test:jshint', function () {
  return gulp.src(['src/js/**/*.js'])
    .pipe($.jshint())
    .pipe($.jshint.reporter('jshint-stylish'));
});

gulpfile.js に上記のように記述します。sass-lint も jshint もそれぞれ設定ファイルにもとづいて解析が実行されるので、sass-lint も jshint もそれぞれ設定ファイルにもとづいて解析が実行されます。

テストの実行、セットアップ

{
  "name": "Amethyst",
  "main": "gulpfile.js",
  "scripts": {
    "setup": "npm install && composer install",
    "test": "composer test && gulp test:sass && gulp test:jshint"
  },
  "author": "Megumi Hano",
  "license": "GPLv2",
  "devDependencies": {
    // dependencies here
  }
}

package.json に上記のように設定をして、

$ npm run setup

で npm install と composer install が実行されます。

$ npm test

をすることで、もろもろのテストをコマンド一発でまとめて実行するようにしています。

Travis CI

今まで紹介したテストの実行やセットアップをすべて Travis CI にやってもらっています。設定ファイルはこちら。

1. before_script

before_script:
  - nvm install 6
  - npm run setup

先ほど紹介した package.json に設定した $ npm run setup を、before_script に記述すると、Travis が package.json を読みに行ってスクリプトを実行してくれます。

Travis の実際のログはこちら。

2. script

script:
  - ls -al style.css
  - npm test

WordPress テーマは style.css が存在することが必要最低限の条件のうちのひとつで、style.css がないとテーマとして認識されません。$ ls -al style.css によって、style.css があるかどうかをチェックしています。
$ npm test は先ほどと同様に、Travis が package.json を読みに行って実行してくれます。

3. after_success

after_success: bash ./.bin/deploy.sh

master ブランチへの変更があった(= develop ブランチの内容が master にマージされた)場合に、master から release ブランチにビルドするようにシェルスクリプトを書いて実行しています。

なお、ビルドは構文エラーなど何らかの理由でテストが通らなかった場合は実行されません。

自動デプロイ

こちらは本題ではないので、セッション中やスライド(89枚目)ではさらーっと流しただけでしたがこんな声があったのでちょっと説明しておこうと思います。

自動デプロイにはいくつか方法がありますが、私は Deploybot.com というデプロイ専用の Web サービスを利用して、release ブランチの内容をテーマのデモサイトにデプロイしています。Deploybot は以前まではリポジトリひとつまでなら無料だったのですが、今は完全有料になっているみたいです。

何をやっているのかちゃんと書くと、それだけで記事になってしまうので自分の忘備録用に書いた Gist とあわせて、参考記事をいくつか書いておきました。

Setup auto-deployment using dploy.io
https://gist.github.com/featherplain/8e9fc1d3141e1a7ce92f
Deploybot.com を利用した自動デプロイ方法 ※ 以前 Deploybot.com は dploy.io というドメインでした
Git – git clone
https://git-scm.com/docs/git-clone
ページ中盤に --bare と --mirror の記述あり
Automated git deployments from Bitbucket
http://jonathannicol.com/blog/2013/11/19/automated-git-deployments-from-bitbucket/
Bitbucket での自動デプロイ
Stop using git pull for deployment!
http://grimoire.ca/git/stop-using-git-pull-to-deploy
デプロイの時は git pull ではなく git checkout を使うよう書かれている記事

ポイントだけ触れておくと、サーバー上に公開ディレクトリとは別にミラーリポジトリ example.com/mirror_repos/{repo}/ (ベアリポジトリではない)を作成して Git の情報だけを置いておき、release ブランチに変更があった場合にファイルの実体を公開ディレクトリ example.com/public_html/{dir}/ に展開するという方法をとっています。

2年前なので古いのですが、WordCamp Kansai 2014で WordPress サイトにおけるデプロイについてのセッションがあったようなのでこのスライドも参考にするといいかもしれません。

WordPress サイト制作におけるデプロイメントを考える ~Git とデプロイメントサービスの活用~ from Toru Miki

おわりに

スライドでも紹介していますが、今回事例にあげた WordPress テーマのリポジトリはこちらです。

Amethyst
https://github.com/featherplain/amethyst

登壇をきっかけにリポジトリのスター数(GitHub の「いいね!」やお気に入り的なもの)が本当に少しずつですが伸び始めていて結構嬉しかったりします。スターをつけてくれるだけでも励みになったりするので皆様ぜひスターをポチッと! プルリクエストも大歓迎なので何か気になることがあれば気軽に送ってくださいね。プルリクという形でバグが勝手に直ったりコードが段々と洗練されていくのはとてもありがたいです。こういうのはオープンソースプロジェクトならではですね。

では皆様よい WordPress ライフを!

Exit mobile version