ポッケの自動化を支える CI/CDパイプライン 株式会社ポッケ 満永　淳一

自己紹介 ■ 名前：満永　淳一 ■ twitter：@Junichi_M_ ■ 所属：株式会社ポッケ ■ 役割： アプリケーションエンジニア → SREエンジニアになろうとしている

お伝えしたいこと ■ポッケのCI/CDパイプライン – ポッケで利用しているツールや実装について ■CI/CDパイプライン運用の注意点 お伝えしないこと ・利用しているOSS ・ Infrastructure as codeの取り組み

アジェンダ ■解決したかったこと ■CI/CDパイプライン構成 ■CI/CDパイプラインの運用 ■まとめ

解決したかったこと

背景 モノリスからの脱却、マイクロサービス化

背景 ドメイン分析からマイクロサービス化もできた

背景 テストコード実装も根付いてきた

背景 そろそろ環境作って動かしたいよね？

マイクロサービス化で実現したいこと アプリ編 ■ 定期的に品質の確認をしたい ■ 変更に強いシステムにしたい ■ デリバリーを容易にしたい

マイクロサービス化で実現したいこと アプリ編 ■ 定期的に品質の確認をしたい ・いつからテストに失敗したか不明 ■ 変更に強いシステムにしたい ・デグレが起こる ■ デリバリーを容易にしたい ・数が多いので手動デプロイはキツイ

次やること 継続的インテグレーション、 継続的デリバリーをしよう！

継続的インテグレーション(Continuous integration) 継続的インテグレーションとは？ プロダクトのソースコードがチェックインされるたびに、 テストやビルドといった一連のプロセスを自動で実行すること 参考 https://www.atmarkit.co.jp/ait/articles/1903/19/news007.html

継続的デリバリー(Continuous delivery) 継続的デリバリーとは？ 継続的に動作するソフトウェアをリリースすること 迅速なビジネス価値を提供できる ユーザーからのフィードバックをビジネス価値に変換できる リスクの少ないリリースプロセスの確立

CI/CDパイプラインの構成

CI/CDパイプライン草案 こんな感じにしたいね

CI/CDパイプライン草案 こんな感じにしたいね CI/CDツールって重要

CI/CDツール Azure DevOpsを選びました

CI/CDツールにAzure DevOpsを選んだ理由 Azure DevOps とは? マイクロソフトの DevOps ツールで、Git リポジトリやプロジェクト管理のためのカンバンボード、ダッシュボー ド、CI/CD のパイプライン作成など、様々な機能を有している https://medium.com/@yuhattor/microsoft-の-devops-への道のり-db59c0848d78より一部抜粋 参考 https://medium.com/@yuhattor/microsoft-の-devops-への道のり-db59c0848d78

CI/CDパイプライン

(再掲)マイクロサービス化で実現したいこと アプリ編 ■ 定期的に品質の確認をしたい ■ 変更に強いシステムにしたい ■ デリバリーを容易にしたい

解決できたこと① ■ 定期的に品質の確認をし たい ■ 変更に強いシステムにし たい 通知が来るので失敗したら すぐにわかる テストが実行されるので デグレが検知できる

解決できたこと② ■ デリバリーを容易にし たい 本番とStagingを差別化 ・PdM ・責任者 ・SRE

全て解決 ■ 定期的に品質の確認 をしたい → 解決 ■ 変更に強いシステムに したい → 解決 ■ デリバリーを容易にし たい → 解決

CI/CDパイプラインの運用

CI/CDツールを導入して気づいたこと① ■ テスト失敗の原因特定時間が短縮できた ■ エンジニアがテスト結果に興味を示すようになった

CI/CDツールを導入して気づいたこと② ■ CIが失敗した原因が分かりずらい ■ CI/CDツールの管理が属人化した Azure DevOpsおじさんの誕生 手作業で設定している部分が多い ■ 変更が発生した場合、反映に時間がかかった マイクロサービスだとCI/CDパイプライン数も多いので 運用に時間がかかる

CI/CDツールを導入して気づいたこと② ■ CIが失敗した原因が分かりずらい 　原因の特定が難しかった 　発生する大量のlogの中から失敗したテストをさがす…

CIが失敗した原因が分かりずらい テストの粒度を分けました

テストサイズによる分割 Googleが提唱しているTest Sizesの概念を参考にテストフェーズを分割を試みた Test Sizesとは？ ■ Small ネットワークアクセスなどは全てモック化し、外部の依存がないテスト 　 単体テスト ■ Medium ローカルホストだけからのアクセスがある環境でのテスト ■ Large プロダクション環境に近い環境でのテスト エンドツーエンドまたはシステムテスト

テストサイズによる分割 テストの分割において、Googleが提唱しているTest Sizesの概念を参考にテストフェーズを分割 参考 https://www.atmarkit.co.jp/ait/articles/1903/19/news007_2.html#l_news007_03.png

テストサイズによる分割 テストの分割において、Googleが提唱しているTest Sizesの概念を参考にテストフェーズを分割 参考 https://www.atmarkit.co.jp/ait/articles/1903/19/news007_2.html#l_news007_03.png

CIパイプライン GUIは非常にシンプルなので作成はそこ まで複雑ではない ↓ 新しいCIパイプラインを作成する際には 特定の場所を変更する ↓ 手作業なので手順が必要 ↓ 変更があると反映まで時間がかかる CIパイプライン設定画面

Pipeline as Codeの導入

CIパイプライン CIパイプラインのタスクをコードベースで 管理 ↓ テンプレート化ができた 変更に強くなった pool: name: Default-Pool demands: maven steps: - task: Maven@1 displayName : 'TEST COVERAGE' inputs: mavenPomFile : ut/pom.xml goals: 'clean verify jacoco:report -Dwebs.mock="mock"' codeCoverageToolOption : JaCoCo codeCoverageClassFilter : '+:**.batch.facade.*,+:**.batch.util.*' - task: Docker@1 displayName : 'Build an image' inputs: azureSubscriptionEndpoint : 'sampleEndPoint' azureContainerRegistry : sampleEndPointRegistory imageName : 'sampleEndPointRegistory/$(Build.Repository.Name):$(Build.BuildNumber)' - task: Docker@1 displayName : 'Push an image' inputs: azureSubscriptionEndpoint : 'sampleEndPoint' azureContainerRegistry : sampleEndPointRegistory command: 'Push an image' imageName : 'sampleEndPointRegistory/$(Build.Repository.Name):$(Build.BuildNumber)'

CDパイプライン GUIは非常にシンプルなので作成はそこ まで複雑ではない ↓ 手作業なので手順が必要 CDパイプライン設定画面

まとめ

所感 ■ pipeline as codeのように全体の流れを自動化することで 　流れ自体にも信頼性が生まれてきた ■ CI/CDを導入してそれなりに運用出来てきた… 振り返ってみるとまだまだカイゼンすることがたくさんある

今後やること ■ DevSecOpsを目指す 　　パイプラインの流れにセキュリティ診断を導入する ■ CIパイプラインの最適化 CIテスト時間の最適化 CIパイプラインのテストサイズによる最適化 ■ CDパイプラインのコード化を検討する

ご清聴 ありがとうございました