Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
自動化を支えるCI/CDパイプライン
Search
Junichi Mitsunaga
March 19, 2019
Technology
0
1.8k
自動化を支えるCI/CDパイプライン
Azure DevOpsツールを使ったCI/CD導入例を紹介します
Junichi Mitsunaga
March 19, 2019
Tweet
Share
More Decks by Junichi Mitsunaga
See All by Junichi Mitsunaga
New Relic_開発・運用チームを生成AIで繋ぐビジネス視点を醸成するオブザーバビリティ戦略
junichimitsunaga
1
63
Azure DevOps Community LT 文化醸成とツール支援
junichimitsunaga
0
89
Other Decks in Technology
See All in Technology
登壇ネタの見つけ方 / How to find talk topics
pinkumohikan
5
590
Core Audio tapを使ったリアルタイム音声処理のお話
yuta0306
0
150
ビギナーであり続ける/beginning
ikuodanaka
2
250
Lazy application authentication with Tailscale
bluehatbrit
0
110
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
0
180
React開発にStorybookとCopilotを導入して、爆速でUIを編集・確認する方法
yu_kod
1
110
作曲家がボカロを使うようにPdMはAIを使え
itotaxi
0
390
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
1.3k
5min GuardDuty Extended Threat Detection EKS
takakuni
0
180
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
5
4.6k
生成AI開発案件におけるClineの業務活用事例とTips
shinya337
0
180
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
0
420
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
42
2.7k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
RailsConf 2023
tenderlove
30
1.1k
Building an army of robots
kneath
306
45k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
940
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
Stop Working from a Prison Cell
hatefulcrawdad
270
20k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Into the Great Unknown - MozCon
thekraken
39
1.9k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
800
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
VelocityConf: Rendering Performance Case Studies
addyosmani
331
24k
Transcript
ポッケの自動化を支える 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パイプラインのコード化を検討する
ご清聴 ありがとうございました