GitLab CIでPerlアプリケーションのテスト/デプロイを自動化する

こんにちは、whywriteit インフラ班のwhywaitaです。

今回とある案件でGitLab CIを用いたCIを行ったので、その手順について記録したいと思います。

概要

  • GitLab CI
    • 途中でバージョンアップが何回か入ったのでバージョンは不定ですが、8.4 〜 8.6系
  • Perl 5.20.3
    • Coro導入の関係でこのバージョンです(詳細は後述)

今回はアプリケーションは他の人が書いており、それのCI部分を担当しておりました。自分はPerlを殆ど触った事が無かったので、その辺も込みでハマった所を書いておきます。

実装した動作

  • 実行用のUNIXユーザをサーバ上に用意し、ホームディレクトリにデプロイ
  • 本番用/検証用で別ドメインを用意する、サーバは同じ
  • developブランチにpushがあると本番用に、それ以外のブランチへのpushやMerge Requestがあると検証用にデプロイを行う

.gitlab-ci.yml

一昔前はGitLab CIはあくまでGitLabとの連携が強い単独のアプリケーションだったのですが、最近のバージョンではGitLabの1つの機能としてGitLab CIが導入されています。
ではそのビルドをどのように有効化するかと言えば、gitリポジトリ内に .gitlab-ci.yml という名前でファイルを追加するだけです。簡単ですね。

一部マスクしていますが、実際に利用している .gitlab-ci.yml がこちらです。

config/deploy.pl に関しては、naoya_ito氏の以下のエントリを参考にして制作しました。

開発メモ#1 : Cinnamon によるデプロイ – naoyaのはてなダイアリー

ハマった/工夫した点

Coroが動かない

デプロイツールとして前記した通りCinnamonを選択したのですが、Cinnamonが依存しているCoroは最新版のPerlでは動かないことを知りました。
moznion氏の以下のエントリを見て頂ければ大体終わりです。これを受けて我々はstandard perl 5.20.3を利用しましたが、各自の環境に合わせた選択を推奨します。

plenv で stableperl を利用するの術 & stableperl の話 – その手の平は尻もつかめるさ

CIでのみTerm::ReadKeyのインストールが失敗する

Dockerコンテナでは実際のシェルではないため、インストールは成功してもPerlモジュールインストールテストで落ちるため、結果的にexit codeが1となり落ちます。
我々は検証環境を用意し、動いている事の確認をした上で cpanm --installdeps . --force する事でCIテストを通しました。
テストの実装は以下にある通りですので、皆様はしっかりと検証した上でご利用ください。

  • https://github.com/jonathanstowe/TermReadKey/tree/master/t

検証環境の作成

Viewを書いていたデザイナーの方がサーバを持っていなかったため、別に検証環境を用意しました。
検証環境といいつつ、あるのはMicroServer1台だけだったので、ディレクトリ分けと内部で使用するポートを切り替えるだけの実装でしたが、綺麗な環境でテスト出来るという事で割と評判は良かったです。

最後に

ビルドの成否やGitLabのpush通知などを全てslackに通知していたのですが、マージ出来るかどうかを機械的に判断し、自動的にデプロイする事でかなり開発は高速化出来たかなと感じています。

結果としてコードを書いていた人達の待ち時間がほぼ0の状態までもっていけた(≒インフラ担当として手でのオペレーションをほぼ行う必要がなくなった)ので、仕事は果たせたかなと。

また、少しCIが楽しくなってきたので、他の第3世代CIと呼ばれるSaaSも試してみました。

リポジトリ

エヴァのMAGIシステムを思い出しました。ちょっと面白かったです。

コメントを残す