Kunoichi Marketドキュメント

開発者向け

GitlabでWordPressをCIする手順

GitlabはGithubと同じくソフトウェア開発プラットフォームであり、Gitなどのソースコード管理ツールをはじめとして、様々な共同開発・コラボレーションのための機能を提供しています。Githubに比べて後発のサービスですが、下記の点で異なります。

  • プライベートグループおよびプライベートプロジェクトが無料（3人まで）。Githubのオーガニゼーションはプライベートリポジトリを利用するためには有料プランへの加入が必須です。
  • CI/CD、つまり継続的インテグレーションツールがはじめから統合されている。一方、GithubではTravis CIやCircle CIなどの外部サービスと連携します。また、Travis CIはプライベートリポジトリで利用する場合、有料プランに申し込む必要があります。

日本語での情報が少ないことを除けば、Gitlabは商用プロダクトの開発において大変コストパフォーマンスに優れていると言うことができるでしょう。とりわけ、小規模な事業者がプレミアムテーマを開発する場合などで効果的です。

GitlabのCIツール

Gitlabではプロジェクトに .gitlab-cli.yml ファイルを含めることで、CIツールが動作します。今回は架空のテーマ Kunoichi Theme を例に説明しましょう。Kunoichi Themeでは、 wp-cli が提供するテーマテスト機能を元にし、PHPUnitによるユニットテストを導入しています。

wp scaffold theme-tests kunoichi-theme

これにより、テストに必要なファイルが生成されます。テストの内容は別の機会に説明するとして、次のようなコマンドを叩くことでユニットテストが走ると仮定しておきましょう。

// テスト用のWordPressをインストール
bash bin/install-wp-tests.sh wordpress_tests root password
// 必要なライブラリをインストール
composer install
// テストを実行（実際は phpunit を実行）
composer test

それでは、これを複数の環境で実行するにはどうしたらよいでしょうか？ .gitlab-cli.yml に次のように書き込みます。

variables:
   # MySQLサービスの設定 (https://hub.docker.com/_/mysql/)
   MYSQL_DATABASE: wordpress_tests
   MYSQL_ROOT_PASSWORD: mysql
before_script:
   # Dockerをアップデート
   - apt-get clean
   - apt-get update -yqq
   # CIテストの実行に必要なツールをインストール
   - apt-get install -yf subversion mysql-client libmysqlclient-dev --fix-missing
   # PHP拡張のインストール
   - docker-php-ext-enable mbstring mcrypt mysqli pdo_mysql intl gd zip bz2
   # WordPressをインストール
   - bash bin/install-wp-tests.sh wordpress_tests root mysql mysql latest true
   # Composerをインストール
   - composer install 
 
PHPunit:PHP5.6:MySQL:
   image: tetraweb/php:5.6
   services:
     - mysql:5.6
   script:
     - composer test
 PHPunit:PHP7.0:MySQL:
   image: tetraweb/php:7.0
   services:
     - mysql:5.6
   script:
     - composer test
 PHPunit:PHP7.1:MySQL:
   image: tetraweb/php:7.1
   services:
     - mysql:5.6
   script:
     - composer test

上記のファイルをリポジトリにプッシュすると、CI/CDの項目に Pipeline というものが追加され、テストが実行されます。

ステージの指定

さて、継続的インテグレーションに続いて重要なのが継続的デリバリー（CD）です。Gitlabではこのための機能も初めから用意されています。Kunoichi Themeでは次のようにしましょう。

  • 複数の環境でテストを行なう
  • エラーがおきなければデモサーバーにデプロイする

Gitlabでは stage という概念があり、CIツールを複数のステップにわけて実行できます。今回は次の2つのステージを用意しましょう。testステージがオールグリーンだったらdeployステージに移動する、というわけです。ステージを明示するには、.gitlab-cli.yml に次のような追記を行います。

stages:
  # ステージの定義
  test
  deploy

それぞれの実行環境（上記でいえば PHPunit:PHP7.1:MySQL: ）にstageを指定することで、そのプロセスがどこで行われるのかを指定できます。

PHPunit:PHP7.1:MySQL:
  # testステージでだけ実行
  stage: test
  image: tetraweb/php:7.1
  services:
    - mysql:5.6
  script:
    - composer test

デプロイ用情報の指定

サーバーにデプロイするには、必ず認証情報が必要になります。しかしながら、リポジトリに秘密鍵などをコミットしてしまうことは大変危険なので、必ず Variable 機能を使いましょう。これは各プロジェクトの Settings > CI / CD > Variables で設定できます。

複数行のテキストも保存できます。

こちらで保存した値は .gitlab-cli.yml 内で変数として渡されるため、安全に利用することができます。今回はここの SSH_PRIVATE_KEY として秘密鍵を保存しておきましょう。

一点だけ、注意点があります。このテキストフィールドは改行コードが CRLF で保存されてしまうため、秘密鍵が壊れてしまいます！　実際に利用するときは tr コマンドなどを利用して改行コード \r を削除しましょう。筆者はこのことに気づくまで1日を要しました。

# 改行コードを削除します。
echo "$SSH_PRIVATE_KEY" | tr -d '\r' | cat > ~/.ssh/id_rsa

さて、これで準備はできました。テストが通ったらデモサーバーにrsyncでアップロードしましょう。

stages:
  # ステージの定義
  - test
  - deploy

variables:
  # MySQLサービスの設定 (https://hub.docker.com/_/mysql/)
  MYSQL_DATABASE: wordpress_tests
  MYSQL_ROOT_PASSWORD: mysql

before_script:
  # Dockerをアップデート
  - apt-get clean
  - apt-get update -yqq
  # CIテストの実行に必要なツールをインストール
  - apt-get install -yf subversion mysql-client libmysqlclient-dev --fix-missing
  # PHP拡張のインストール
  - docker-php-ext-enable mbstring mcrypt mysqli pdo_mysql intl gd zip bz2
  # WordPressをインストール
  - bash bin/install-wp-tests.sh wordpress_tests root mysql mysql latest true
  # Composerをインストール
  - composer install

PHPunit:PHP5.6:MySQL:
  # testステージでだけ実行
  stage: test
  image: tetraweb/php:5.6
  services:
    - mysql:5.6
  script:
    - composer test

PHPunit:PHP7.0:MySQL:
  # testステージでだけ実行
  stage: test
  image: tetraweb/php:7.0
  services:
    - mysql:5.6
  script:
    - composer test

PHPunit:PHP7.1:MySQL:
  # testステージでだけ実行
  stage: test
  image: tetraweb/php:7.1
  services:
    - mysql:5.6
  script:
    - composer test

deploy_demo:
  # deployステージでだけ実行
  stage: deploy
  image: tetraweb/php:7.0
  script:
    # いらないファイルを削除して配布用ビルドを作成するスクリプトを実行。
    - bash ./bin/build.sh
    # SSH用のディレクトリを作成
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    # Variablesに保存した変数をファイルに書き出し
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | cat > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    # rsyncをインストール
    - apt-get install -y rsync
    # リモートサーバーにアップロード
    - rsync --recursive --verbose --perms --times --checksum --delete -e "ssh -i /root/.ssh/id_rsa -o 'StrictHostKeyChecking=no'" ./ kunoichi-theme@kunoichi-theme-demo.example.com:/var/www/wordpress/wp-content/themes/kunoichi-theme/
  only:
    - master

まとめ

無事に動作すると、次のようにオールグリーンの表示になります。気持ちいいですね！

Pipelineのステージはもっと増やすこともできます。

継続的インテグレーションおよび継続的デリバリーは色々な用途に使うことができます。今回はmasterブランチへのpushをすべてデモサーバーにアップロードしましたが、たとえばこんな利用方法が考えられるでしょう。

  • developブランチへのpushが通ったらステージングサーバー、masterブランチへのpushが通ったら本番サーバーへそれぞれアップロード。
  • タグを打ってバージョンをつけたらリリースビルドを作成して、Kunoichiへアップロード

もちろん、Kunoichiではテーマ・プラグインの継続的デリバリーを追加するための準備を行なっています。いまはまだ新しいバージョンが出るたびに手動アップロードをしなければならず、そのイケてなさも理解していますので、新機能の登場をお待ちください！

関連ドキュメント

開発者向けのドキュメントを見る