自動化を支えるCI/CDパイプライン

1.

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

2.

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

3.

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

4.

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

5.

解決したかったこと

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

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

18.

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

19.

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

20.

CI/CDパイプライン

21.

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

22.

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

23.

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

24.

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

25.

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

26.

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

27.

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

28.

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

29.

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

30.

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

31.

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

32.

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

33.

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

34.

Pipeline as Codeの導入

35.

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)'

36.

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

37.

まとめ

38.

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

39.

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

40.

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

自動化を支えるCI/CDパイプライン

自動化を支えるCI/CDパイプライン

Want more?

Transcript