自動化を支えるCI/CDツールの私の選択

1. 自動化を支える
CI/CDツールの私の選択
〜 何をするためにCI/CDツールを選ぶか 〜
2017/03/07 リクルートライフスタイル
関根 康史

2. 自己紹介
● 関根 康史 （ @AHA_oretama ）
● リクルートライフスタイル
○ 2015/8 〜
● ブッキングテーブル → （SET 活動中）

3. What’s SET ?
The SET or Software Engineer in Test is also a developer role except their focus is on testability.
ミッション
プロダクト・サービスの品質向上⤴
エンジニアの開発生産性向上⤴
何をするか
サービスの品質を向上させる ために様々なボトルネックを解消していく
※ 社内にCET,SWATというチームがいるため、SET,SWET以外の名前を考えてます…

4. 自動化を支えるCI/CDツール
非常に多くのツールが存在
ただし…
● どれを選べばいいか分からない
● 運用をどうするか
● (どのツールを選んでも)
テストが増えればCIが遅くなる
という問題が発生する
https://stackshare.io/search/q=continuous-integration

5. 今日お話すること
● メインで解決したかったこと
● CI/CDツールの選定理由
● CI/CDツールの環境・構成
● CI/CDツール以外での対応
CI/CDツールは何が一番よいかというお話ではなく、
こういう理由でこうした、というお話です。

6. リクルートライフスタイルには多くのサービスがあるが、
（ServerSideを中心に）CI単体テストの実行に数時間かかるものも存在した
⇒ ✓ リリース効率・頻度のアップ
✓ 開発者への早期のフィードバックを行う
そのために、CI単体テストの実行時間を短時間にする！
メインで解決したかったこと

7. CI単体テストは速いほうがよい
⇒ 不具合は早く見つける方が対策費用を抑えられる
※一般にCIは１０分以内に終わるのが良い、と言われている。
遅くとも２０分以内に終わるのが望ましい。
逆に遅くなったときに起こりうることは？
● 別の人のコミットが混じりやすくなり、テストの失敗原因の特定に時間がかかる
● 作成者が作ったものを忘れる
● 作成者が自分の分のコミットでCIが回っているか忘れる
● エンジニアがテスト結果に興味がなくなる
● テストの失敗したまま放置されやすくなる
● テスト自体回さなくなってしまう
● リリース日にエラーしているとその日のリリースをとりやめなければならなくなる
● 緊急リリースを行う前にCIを回さず、デグレが本番で発生する
CI単体テストの速度の重要性

8. CI単体テストを速くするために
やったこと・やるつもりのこと
● CI/CDツールの選定
● 環境の移行・構成
● CI単体テストのよくある問題の解決
● プルリクエストのCI単体テスト時間の最適化（予定）
● 周辺ツールの整備（予定）
＝今日お話すること（残り）

9. CI単体テストを速くするために
やったこと・やるつもりのこと
● CI/CDツールの選定
● 環境の移行・構成
● CI単体テストのよくある問題の解決
● プルリクエストのCI単体テスト時間の最適化（予定）
● 周辺ツールの整備（予定）
＝今日お話すること（残り）

10. CI/CDツールにJenkinsを選んだ理由
候補として上がったのはJenkins,CircleCI
セキュリティ上の理由からオンプレ前提
Jennkins 2.X CircleCI
コスト 無料 $35 / User () per month with annual contract
運用 大変になりがち -
型 プラグイン型
ex.Jenkins内でカバレッジを可視化しつづける
特化型（CI/CDに特化）
ex. カバレッジを取りつづけるならCoveralls,Codecov
などと連携しなければならないが、オンプレで運用する
必要あり
環境 コンテナもサポートしているが、
各プロジェクトで環境を定義することが多い
コンテナ型
ビルド環境の独立性を確保
ジョブ定義 Pipelineの登場 yml

11. ● Jenkins 2.Xからデフォルトインストールされる機能
● Pipeline as Code
○ 変更履歴を管理、rollback、レビュの実施
● （再起動後の）永続性
● 手動オペレーションとの融合
Scripted Pipeline
✓ Jenkins 2.Xの初期のデフォルトPipeline
✓ 柔軟な記述が可能な反面、記述が煩雑になりやすい
Declarative Pipeline (since 2017/02/03, Declarative Pipeline Syntax 1.0 is now available)
✓ シンプルに宣言的に扱える
✓ Declarative Pipelineの処理中にScripted Pipelineの構文を使うこともできる
Declarative Pipelineを主に使い、柔軟な表現部分が必要な部分にはScripted Pipelineを使うの
がよいと思う。
Jenkins 2.X Pipeline

12. pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
post {
always {
echo 'I will always say Hello again!'
}
}
}
Jenkins 2.X Declarative Pipeline
Declarative Pipelineを
使うためpipelineで囲む
処理は
stages -> stage -> steps
で定義
pipelineの最後に行う処理。
条件は変更可能
(alwaysは必ず実行）

13. pipeline {
agent {
docker {
image 'maven:3-alpine'
label 'my-defined-label'
args '-v /tmp:/tmp' // dockerに渡る引数
}
}
stages {
stage('Example Build') {
steps {
echo 'Hello, Docker'
}
}
}
}
Jenkins 2.X Declarative Pipeline
agentにDockerも指定可能

14. pipeline {
agent any
tools {
maven ‘apache-maven-3.0.1’
}
trigges {
cron(‘H 4/* 0 0 1-5’)
}
stages {
stage('Example Build') {
steps {
sh 'mvn -B clean verify'
// toolsで指定したツールが PATHに登録され、ツールを実行できるようになる
}
}
}
}
Jenkins 2.X Declarative Pipeline
AutoInstallしたツールを使用できる
● maven
● jdk
● gradle のみ
ジョブの起動トリガー
● cron
● pollScm のみ

15. pipeline {
agent any
stages {
stage('Example Deploy') {
when {
branch 'production'
}
echo 'Deploying'
script {
def browsers = ['chrome', 'firefox']
for (int i = 0; i < browsers.size(); ++i) {
echo "Testing the ${browsers[i]} browser"
}
}
}
}
}
Jenkins 2.X Declarative Pipeline
ブランチがproduction以外は
このstageを実行しない
Scriptブロック内では
Scripted Pipelineを使用できる

16. CI単体テストを速くするために
やったこと・やるつもりのこと
● CI/CDツールの選定
● 環境の移行・構成
● CI単体テストのよくある問題の解決
● プルリクエストのCI単体テスト時間の最適化（予定）
● 周辺ツールの整備（予定）
＝今日お話すること（残り）

17. 環境の移行・Jenkinsの構成
Oracle
社内サーバ Slave
Slave
● 性能が良くない社内サーバから AWSへ（性能＆安定性UP）
● ジョブ数に応じて、AMIからSlaveを自動生成するようにして自動でスケール
● RDS内部でスキーマを切り、 Slaveごとに別の仮想DBを用意
● Slave構成にすることでテストの並列実行が可能に

18. Jenkins Slave EC2 vs ECS
EC2 Slave ECS(EC2 Container Service)
タイプ インスタンス Docker
ベース AMIからインスタンス起動 Docker Imageから起動
スレーブ管理者 主にインフラ 主に開発者
スケール ジョブが滞留したらスケールする ECS Auto Scaling に対応
メリット 同じ環境のプロジェクトで使いやすい
簡単に始められる
環境がクリーン
起動が早い
デメリット 起動に若干時間がかかる
環境がカオティックになりやすい
イメージ作成・管理が必要
現時点ではEC2 Slaveを採用。
● 既存プロジェクトがDocker未使用のところが多い
● Jenkinsはプロジェクト単位で立てているため、あまり環境がカオティックにならない

19. CI単体テストを速くするために
やったこと・やるつもりのこと
● CI/CDツールの選定
● 環境の移行・構成
● CI単体テストのよくある問題の解決
● プルリクエストのCI単体テスト時間の最適化（予定）
● 周辺ツールの整備（予定）
＝今日お話すること（残り）

20. CI単体テストのよくある問題の解決
問題 解決
10000件のデータ登録でエラーになるテストケースで、
10000件のデータを登録しようとしている。
上限をテスト内で変更し、
大量データをいれないようにする。
Debugレベルのログが大量に出力されてしまい、
ログファイルも開けない。CI単体テストも遅くなる。
適切なログレベル（Error またはWarn以上）に設定
する。
本番環境でしかつながらないサーバに対して、
通信を行って通信エラーになるまで数秒間待機してしまう。
テスト用の通信しないクラスを作成して、
上書きする
１クラスのテストに対してWEBアプリケーションを
起動してしまう。（主にSpring-Bootで）
テスト範囲に応じて、
テスト対象外のクラスはモック化する
実際にあった１例です。

21. ● CI/CDツールの選定
● 環境の移行・構成
● CI単体テストのよくある問題の解決
● プルリクエストのCI単体テスト時間の最適化（予定）
● 周辺ツールの整備（予定）
CI単体テストを速くするために
やったこと・やるつもりのこと
＝今日お話すること（残り）

22. 今後やりたいこと
開発者により速く、そしてもっと情報をフィードバックするために
● プルリクエストのCI単体テスト時間の最適化
○ テストサイズの導入
○ 変更されたファイルからパッケージやファイル名などによるテスト対象の絞込
● 周辺ツールの整備
○ 静的解析
○ SonarQube
○ SideCI

23. まとめ
● メインで解決したかったこと
→ CI単体テストを速くするために
● CI/CDツールの選定理由
→ Jenkinsを選び
● CI/CDツールの環境・構成
→ 並列テスト・スケールできる環境を作り
● CI/CDツール以外での対応
→ 単体テストのよくある問題を解決し、
これから周辺ツールなどを整備していく。