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

〜 何をするためにCI/CDツールを選ぶか 〜

2017/03/07　リクルートライフスタイル関根 康史

自己紹介● 関根 康史 （ @AHA_oretama ）● リクルートライフスタイル

○ 2015/8 〜

● ブッキングテーブル → （SET 活動中）

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以外の名前を考えてます…

自動化を支えるCI/CDツール非常に多くのツールが存在

ただし…

● どれを選べばいいか分からない

● 運用をどうするか

● (どのツールを選んでも)テストが増えればCIが遅くなる

という問題が発生する

https://stackshare.io/search/q=continuous-integration

今日お話すること● メインで解決したかったこと

● CI/CDツールの選定理由

● CI/CDツールの環境・構成

● CI/CDツール以外での対応

CI/CDツールは何が一番よいかというお話ではなく、

こういう理由でこうした、というお話です。

リクルートライフスタイルには多くのサービスがあるが、

（ServerSideを中心に）CI単体テストの実行に数時間かかるものも存在した

⇒ ✓ リリース効率・頻度のアップ

　 ✓ 開発者への早期のフィードバックを行う

そのために、CI単体テストの実行時間を短時間にする！

メインで解決したかったこと

CI単体テストは速いほうがよい

⇒ 不具合は早く見つける方が対策費用を抑えられる※一般にCIは１０分以内に終わるのが良い、と言われている。 遅くとも２０分以内に終わるのが望ましい。

逆に遅くなったときに起こりうることは？

● 別の人のコミットが混じりやすくなり、テストの失敗原因の特定に時間がかかる

● 作成者が作ったものを忘れる

● 作成者が自分の分のコミットでCIが回っているか忘れる

● エンジニアがテスト結果に興味がなくなる

● テストの失敗したまま放置されやすくなる

● テスト自体回さなくなってしまう

● リリース日にエラーしているとその日のリリースをとりやめなければならなくなる

● 緊急リリースを行う前にCIを回さず、デグレが本番で発生する

CI単体テストの速度の重要性

CI単体テストを速くするためにやったこと・やるつもりのこと

● CI/CDツールの選定

● 環境の移行・構成

● CI単体テストのよくある問題の解決

● プルリクエストのCI単体テスト時間の最適化（予定）

● 周辺ツールの整備（予定）

＝今日お話すること（残り）

CI単体テストを速くするためにやったこと・やるつもりのこと

● CI/CDツールの選定

● 環境の移行・構成

● CI単体テストのよくある問題の解決

● プルリクエストのCI単体テスト時間の最適化（予定）

● 周辺ツールの整備（予定）

＝今日お話すること（残り）

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

● 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

pipeline { agent any stages { stage('Example') { steps { echo 'Hello World' } } } post { always { echo 'I will always say Hello again!' } }}

Jenkins 2.X Declarative PipelineDeclarative Pipelineを使うためpipelineで囲む

処理は　stages -> stage -> steps で定義

pipelineの最後に行う処理。条件は変更可能(alwaysは必ず実行）

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も指定可能

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 PipelineAutoInstallしたツールを使用できる

● maven● jdk● gradle のみ

ジョブの起動トリガー● cron● pollScm のみ

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を使用できる

CI単体テストを速くするためにやったこと・やるつもりのこと

● CI/CDツールの選定

● 環境の移行・構成

● CI単体テストのよくある問題の解決

● プルリクエストのCI単体テスト時間の最適化（予定）

● 周辺ツールの整備（予定）

＝今日お話すること（残り）

環境の移行・Jenkinsの構成

Oracle

社内サーバ Slave

Slave

● 性能が良くない社内サーバから AWSへ（性能＆安定性UP）● ジョブ数に応じて、AMIからSlaveを自動生成するようにして自動でスケール

● RDS内部でスキーマを切り、 Slaveごとに別の仮想DBを用意

● Slave構成にすることでテストの並列実行が可能に

Jenkins Slave EC2 vs ECSEC2 Slave ECS(EC2 Container Service)

タイプ インスタンス Docker

ベース AMIからインスタンス起動 Docker Imageから起動

スレーブ管理者 主にインフラ 主に開発者

スケール ジョブが滞留したらスケールする ECS Auto Scaling に対応

メリット 同じ環境のプロジェクトで使いやすい簡単に始められる

環境がクリーン起動が早い

デメリット 起動に若干時間がかかる環境がカオティックになりやすい

イメージ作成・管理が必要

現時点ではEC2 Slaveを採用。

● 既存プロジェクトがDocker未使用のところが多い

● Jenkinsはプロジェクト単位で立てているため、あまり環境がカオティックにならない

CI単体テストを速くするためにやったこと・やるつもりのこと

● CI/CDツールの選定

● 環境の移行・構成

● CI単体テストのよくある問題の解決

● プルリクエストのCI単体テスト時間の最適化（予定）

● 周辺ツールの整備（予定）

＝今日お話すること（残り）

CI単体テストのよくある問題の解決

問題 解決

10000件のデータ登録でエラーになるテストケースで、10000件のデータを登録しようとしている。

上限をテスト内で変更し、

大量データをいれないようにする。

Debugレベルのログが大量に出力されてしまい、ログファイルも開けない。CI単体テストも遅くなる。

適切なログレベル（Error またはWarn以上）に設定

する。

本番環境でしかつながらないサーバに対して、通信を行って通信エラーになるまで数秒間待機してしまう。

テスト用の通信しないクラスを作成して、

上書きする

１クラスのテストに対してWEBアプリケーションを起動してしまう。（主にSpring-Bootで）

テスト範囲に応じて、テスト対象外のクラスはモック化する

実際にあった１例です。

● CI/CDツールの選定

● 環境の移行・構成

● CI単体テストのよくある問題の解決

● プルリクエストのCI単体テスト時間の最適化（予定）

● 周辺ツールの整備（予定）

CI単体テストを速くするためにやったこと・やるつもりのこと

＝今日お話すること（残り）

今後やりたいこと開発者により速く、そしてもっと情報をフィードバックするために

● プルリクエストのCI単体テスト時間の最適化○ テストサイズの導入

○ 変更されたファイルからパッケージやファイル名などによるテスト対象の絞込

● 周辺ツールの整備○ 静的解析

○ SonarQube○ SideCI

まとめ● メインで解決したかったこと

→ CI単体テストを速くするために

● CI/CDツールの選定理由

→ Jenkinsを選び

● CI/CDツールの環境・構成

→ 並列テスト・スケールできる環境を作り

● CI/CDツール以外での対応

→ 単体テストのよくある問題を解決し、

　 これから周辺ツールなどを整備していく。