こんにちは。4月からMisocaにjoinしました、tkykです。京都市内からリモートで働いています。盆地特有のねっとりとした暑さをやり過ごしつつコードを書いている今日この頃です。
さて、今回はMisocaのCI（Continuous Integration）環境がどうなっているか、その全体像を紹介したいと思います。
そもそもCIの目的とは？
ソースコードの一部に対する変更が、アプリケーション全体の動作を壊してしまっていないか、常時チェックするのが目的です。
そのために何をしているか
CI専用のサーバに、変更点を含むソースコード全体をチェックアウトして、依存ライブラリのインストールと必要な前処理を行い、すべてのテストを実行します。
すべてのテストがエラーなくpassしたことをもって、CIが通ったとしています。
Gitを使った開発フローとの統合
MisocaはGitHub上で開発を行なっているため、CIのプロセスもGitHubと密に連携しています。
リポジトリに新たなブランチをpushするたび、ブランチごとにCIが自動で実行されます。ブランチがPullRequestに紐づいている場合には、CIの結果がそのPullRequestに通知されます。
MisocaのCIを支えるツールたち
GitHubにpushしてから、CI結果が届くまでの流れはこのようになっています。
今のところMisocaではSaaS系のCIサービスは使用せず、EC2上に直接システムを構築しています。理由は、必要な性能（特にDBのI/O性能）を得るためのコストがかかりすぎるためです。
Jenkins
CIシステム全体を統括するのが、Jenkinsの役割です。
- CIの実行方法を決定する
- CIの実行結果を開発者に提供する
- CIに関わる様々なタスクを実行する（例: テスト用DBのクリーンナップ）
など、多くの役目を担っています。ジョブの内容はGroovyコードで記述し、リポジトリの中で一体管理しています。
Jenkins の master/slave構成
多数のビルドを並列して実行できるようにするため、Jenkinsは1台のmasterと複数台（現時点では2台）のslaveで構成されています。またslaveそれぞれが同時に複数（現時点では2）のビルドを実行するよう設定されています。
現在のMisocaでは、masterはいくつかの重要なジョブのために予約されており、各CIジョブはslaveでのみ実行されます。
GitHubとの連携を担う GitHub Branch Sourceプラグイン
GitHub上での開発フローと、JenkinsによるCI実行とを統合するのが、GitHub Branch Sourceプラグインです。
このプラグインがリポジトリに対するpushを検知し、ブランチごとにジョブを作成して、CIを実行します。PullRequestに対して結果を通知するのもこのプラグインの役割です。
rrrspec
rrrspecは、rspecを分散実行するためのソフトウェアです。
Misocaでのrrrspecの運用方法については、@kokuyouwindが書いた記事を参照してください。
rrrspec運用のためのInfrastructure as Code
上の紹介記事にある通り、rrrspec workerインスタンスはAuto Scalingによって増減します。すなわちいつでも起動・停止される可能性があるということです。よってworkerインスタンスは、起動してすぐにrrrspecクラスターに参加できるだけの、準備万端の状態で起動しなければいけません。
そのため、あらかじめ必要な設定・データをすべて盛り込んだAMIをつくっておき、Auto Scalingの起動設定でそのAMIを指定しています。
AMIは、VagrantとChefを使って構成し、packerを用いて作成します。Auto Scalingやスポットインスタンスの設定はterraformによって管理しており、これらを一式まとめた構築レシピをGitで管理しています。
まとめ
こうしてCI環境が整備され、常時整合性に目を光らせているおかげで、我々エンジニアは安心してコードに手を入れられるようになっています。
採用
Misocaでは安心安全なCIのもとでコードを書きたいエンジニアや、CIシステムそのものを改善したいエンジニアを募集中です。
