Travis CI で WordPress テーマの CI。テスト、リリースの自動化

mimizuku

Mimizuku Advent Calendar 25日目の記事です。なんと Mimizuku Advent Calendar、予定していた前記事無事完走できました。僕以外誰の参加もなかったことが悔やまれますが、無理やりネタをひねりだしたわりにちゃんとできて良かったです。最後は WordPress テーマと Travi CI について書きます。

Travis CI とは

CI(継続的インテグレーション)とは

主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。

ー Wikipedia より引用

というもので、僕もそんなに良くわかってはいませんが「品質改善や効率化のために自動化できることは自動化して継続的に実行できるようにしようぜ」的なことだと理解しています。Travis CI はそんな CI(継続的インテグレーション)をオンラインで行うことができる Web サービスです。オープンソースプロジェクトであれば無料で利用できます。すばらしい!Travis CI では GitHub と連携してプッシュと同時にさまざまな処理を自動化することができるようになっています。Mimizuku では Travis CI を利用させてもらって、ユニットテストやコーディングスタンダード・静的コード解析などのテスト、そしてリリースの自動化を行っています。

.travis.yml

Travis CI と GitHub の連携は Travis CI にアカウント登録して画面を見ていけばそう難しくないので、ここでは Mimizuku の .travis.yml について説明したいと思います。.travis.yml は Travis CI でどのような処理をさせるかを記述する設定ファイルになります。

全部説明してもやぐらしいので、ポイントをかいつまんで書いてみたいと思います。

php

Travis CI ではいろいろな処理を実行させるためのベースとなる環境を指定できます。Mimizuku は PHP で書かれているので、PHP 環境を構築して実行が必要です。そのため php セクションでどのバージョンの PHP 環境を用意するかを指定します。

php:
- 5.6
- 7

バージョンは複数指定でき、Mimizuku では上記のように PHP 5.6 と PHP 7、2つの環境でテストを実行するようにしています。自分のパソコンの中やサーバーの中だけだと普通は1つの環境でしかテストなど行うことができないので、こうやって複数の環境を立ち上げてテストができるというのはとても便利ですね。

install

install セクションではいろいろな処理を実行させる前に、それらの処理に必要なもろもろを指定します。下記は Mimizuku の install セクションです。

install:
- composer install
- nvm install 6
- npm install

Mimizuku ではテストやオートロードなどに必要なパッケージをインストールするためのcomposer install、Gulp でビルドを実行するための Node 環境を構築するnvm install、そして Mimizuku をビルドするために必要な npm モジュールをインストールするためのnpm installを行っています。

before_script

before_script セクションではテストなどの処理を実行する前段階の処理を記述します。Mimizuku ではテスト用の WordPress 環境を構築させています。

before_script:
- bash app/bin/install-wp-tests.sh wordpress_test root '' localhost $WP_VERSION

script

script セクションに実際に行いたい処理を記述します。Mimizuku では Mimizuku の CSS や JS のビルドを行うnpm run gulp build、必須ファイルの存在チェックを行うls、そしてユニットテスト・コーディングスタンダードチェック・静的コード解析を行うcomposer testを実行しています。もしここで何らかのエラーが発生した場合はそこで処理が終了します。

script:
- npm run gulp build
- ls -la style.css index.php vendor/autoload.php
- composer test

after_success

after_success セクションは script セクションでの処理が成功した後に行う後処理を記述できます。Mimizuku は GitHub に master ブランチ、develop ブランチを持っていますが、この after_success セクションで WordPress テーマディレクトリ用のファイルを用意するための wprepository ブランチを作成するようにしていますWordPress テーマディレクトリには掲載していないので不要といえば不要なのですが、今後どうするかはわからないので念のためということで。

after_success:
- bash ./app/bin/wprepository.sh

ちなみに、ブランチの作成・プッシュの処理はちょっと長くなるのでシェルスクリプトを記述したファイルを作ってそれを実行するようにしています。もちろんファイルを作らずに普通に実行するコードを順番に羅列しても大丈夫です。

他にテーマとかプラグインで自動ブランチを切っている方の記述を見てみると、ローカル(Travis CI)の Git リポジトリを一度破壊して、新規の Git リポジトリとしてリリース用のブランチを作成してプッシュする、というのが多いようです。それだとリリース用のブランチには常に最新の1コミットだけが存在する形になります。それでも問題は無いと思うのですが、僕は前のコミットも残しておきたかったので、リリース用のブランチをプルしてきてそこに変更を上書きしてプッシュして履歴が全部残るようにしています

before_deploy

before_deploy セクションにはデプロイの前処理を記述できます。Mimizuku は deploy セクションで GitHub Releases への自動リリースを行っているので、そこにリリースするための zip ファイルの作成処理をここで行っています。

before_deploy:
- bash ./app/bin/zip.sh

deploy

deploy セクションではデプロイに関する処理を記述できます。ここは他のセクションみたいに自由自在には記述できなくて、ある程度ルールがあります。詳しくはドキュメントで確認してみてください。Miimzuku の場合は GitHub Release へのリリースを行わせていて、次のような記述をしています。

deploy:
  provider: releases
  api_key:
    secure: 暗号化されたキー
  file: mimizuku.zip
  on:
    tags: true
    repo: inc2734/mimizuku

上記の記述を自分で書いても動くとは思いますが、暗号された api_key の生成とか面倒なので、コマンドでやってしまうのがおすすめです。次のコマンドを実行すると質問に答えていくだけで上記のようなコードが自動的に記述されて便利です。

// travis コマンドのインストール(既にインストールされている場合は不要)
$ gem install travis

// GitHub Release 用の記述を生成して .travis.yml を上書き
$ travis setup releases

まとめ

ということで WordPress テーマと Travis CI でした。最終日なので1人 Advent Calendar をやってみてどうだったとかそういうことを書けば良かったなーということを今思いました。でもそんなのは誰も興味がないと思うので今回の形で良かったのかもしれませんw

Mimizuku Advent Calendar は Mimizuku の紹介的なことをしたいというのももちろなりましたが、単に WordPress テーマを作るといっても色々と考えたり工夫したりできることがあるよ、ということもまとめたいなという思いもありました。それがうまくできたかはわかりませんが、ただ作るだけではなくて一歩進んで何かしたいという方のために、いつか今回書いてきた記事が役に立つようなことがあれば良いなと思います。

それでは良いクリスマスを!

  • ブックマーク
  • Feedly

この記事を書いた人

キタジマタカシ

長崎在住、フリーランスのWordPress テーマ / プラグインデベロッパー。 多数のプロダクトをオープンソースで開発・公開しています。現在は WordPress 有料テーマ Snow Monkey を開発・販売しています。