Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

自動化を支えるCI/CDツールの私の選択 ~何をするためにCI/CDツールを選ぶか~

2,704 views

Published on

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

Published in: Technology
  • Be the first to comment

自動化を支えるCI/CDツールの私の選択 ~何をするためにCI/CDツールを選ぶか~

  1. 1. 自動化を支える CI/CDツールの私の選択 〜 何をするためにCI/CDツールを選ぶか 〜 2017/03/07 リクルートライフスタイル 関根 康史
  2. 2. 自己紹介 ● 関根 康史 ( @AHA_oretama ) ● リクルートライフスタイル ○ 2015/8 〜 ● ブッキングテーブル → (SET 活動中)
  3. 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. 4. 自動化を支えるCI/CDツール 非常に多くのツールが存在 ただし… ● どれを選べばいいか分からない ● 運用をどうするか ● (どのツールを選んでも) テストが増えればCIが遅くなる という問題が発生する https://stackshare.io/search/q=continuous-integration
  5. 5. 今日お話すること ● メインで解決したかったこと ● CI/CDツールの選定理由 ● CI/CDツールの環境・構成 ● CI/CDツール以外での対応 CI/CDツールは何が一番よいかというお話ではなく、 こういう理由でこうした、というお話です。
  6. 6. リクルートライフスタイルには多くのサービスがあるが、 (ServerSideを中心に)CI単体テストの実行に数時間かかるものも存在した ⇒ ✓ リリース効率・頻度のアップ   ✓ 開発者への早期のフィードバックを行う そのために、CI単体テストの実行時間を短時間にする! メインで解決したかったこと
  7. 7. CI単体テストは速いほうがよい ⇒ 不具合は早く見つける方が対策費用を抑えられる ※一般にCIは10分以内に終わるのが良い、と言われている。 遅くとも20分以内に終わるのが望ましい。 逆に遅くなったときに起こりうることは? ● 別の人のコミットが混じりやすくなり、テストの失敗原因の特定に時間がかかる ● 作成者が作ったものを忘れる ● 作成者が自分の分のコミットでCIが回っているか忘れる ● エンジニアがテスト結果に興味がなくなる ● テストの失敗したまま放置されやすくなる ● テスト自体回さなくなってしまう ● リリース日にエラーしているとその日のリリースをとりやめなければならなくなる ● 緊急リリースを行う前にCIを回さず、デグレが本番で発生する CI単体テストの速度の重要性
  8. 8. CI単体テストを速くするために やったこと・やるつもりのこと ● CI/CDツールの選定 ● 環境の移行・構成 ● CI単体テストのよくある問題の解決 ● プルリクエストのCI単体テスト時間の最適化(予定) ● 周辺ツールの整備(予定) =今日お話すること(残り)
  9. 9. CI単体テストを速くするために やったこと・やるつもりのこと ● CI/CDツールの選定 ● 環境の移行・構成 ● CI単体テストのよくある問題の解決 ● プルリクエストのCI単体テスト時間の最適化(予定) ● 周辺ツールの整備(予定) =今日お話すること(残り)
  10. 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. 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. 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. 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. 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. 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. 16. CI単体テストを速くするために やったこと・やるつもりのこと ● CI/CDツールの選定 ● 環境の移行・構成 ● CI単体テストのよくある問題の解決 ● プルリクエストのCI単体テスト時間の最適化(予定) ● 周辺ツールの整備(予定) =今日お話すること(残り)
  17. 17. 環境の移行・Jenkinsの構成 Oracle 社内サーバ Slave Slave ● 性能が良くない社内サーバから AWSへ(性能&安定性UP) ● ジョブ数に応じて、AMIからSlaveを自動生成するようにして自動でスケール ● RDS内部でスキーマを切り、 Slaveごとに別の仮想DBを用意 ● Slave構成にすることでテストの並列実行が可能に
  18. 18. Jenkins Slave EC2 vs ECS EC2 Slave ECS(EC2 Container Service) タイプ インスタンス Docker ベース AMIからインスタンス起動 Docker Imageから起動 スレーブ管理者 主にインフラ 主に開発者 スケール ジョブが滞留したらスケールする ECS Auto Scaling に対応 メリット 同じ環境のプロジェクトで使いやすい 簡単に始められる 環境がクリーン 起動が早い デメリット 起動に若干時間がかかる 環境がカオティックになりやすい イメージ作成・管理が必要 現時点ではEC2 Slaveを採用。 ● 既存プロジェクトがDocker未使用のところが多い ● Jenkinsはプロジェクト単位で立てているため、あまり環境がカオティックにならない
  19. 19. CI単体テストを速くするために やったこと・やるつもりのこと ● CI/CDツールの選定 ● 環境の移行・構成 ● CI単体テストのよくある問題の解決 ● プルリクエストのCI単体テスト時間の最適化(予定) ● 周辺ツールの整備(予定) =今日お話すること(残り)
  20. 20. CI単体テストのよくある問題の解決 問題 解決 10000件のデータ登録でエラーになるテストケースで、 10000件のデータを登録しようとしている。 上限をテスト内で変更し、 大量データをいれないようにする。 Debugレベルのログが大量に出力されてしまい、 ログファイルも開けない。CI単体テストも遅くなる。 適切なログレベル(Error またはWarn以上)に設定 する。 本番環境でしかつながらないサーバに対して、 通信を行って通信エラーになるまで数秒間待機してしまう。 テスト用の通信しないクラスを作成して、 上書きする 1クラスのテストに対してWEBアプリケーションを 起動してしまう。(主にSpring-Bootで) テスト範囲に応じて、 テスト対象外のクラスはモック化する 実際にあった1例です。
  21. 21. ● CI/CDツールの選定 ● 環境の移行・構成 ● CI単体テストのよくある問題の解決 ● プルリクエストのCI単体テスト時間の最適化(予定) ● 周辺ツールの整備(予定) CI単体テストを速くするために やったこと・やるつもりのこと =今日お話すること(残り)
  22. 22. 今後やりたいこと 開発者により速く、そしてもっと情報をフィードバックするために ● プルリクエストのCI単体テスト時間の最適化 ○ テストサイズの導入 ○ 変更されたファイルからパッケージやファイル名などによるテスト対象の絞込 ● 周辺ツールの整備 ○ 静的解析 ○ SonarQube ○ SideCI
  23. 23. まとめ ● メインで解決したかったこと → CI単体テストを速くするために ● CI/CDツールの選定理由 → Jenkinsを選び ● CI/CDツールの環境・構成 → 並列テスト・スケールできる環境を作り ● CI/CDツール以外での対応 → 単体テストのよくある問題を解決し、   これから周辺ツールなどを整備していく。

×