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 2021
Search
Cybozu
PRO
May 25, 2021
Technology
9
15k
CI/CD 2021
Cybozu
PRO
May 25, 2021
Tweet
Share
More Decks by Cybozu
See All by Cybozu
AIツール開発ワークショップ(Dify)【サイボウズ新人研修2025】
cybozuinsideout
PRO
15
17k
モバイル【サイボウズ新人研修2025】
cybozuinsideout
PRO
3
3.4k
Git/GitHub を使う上で知っておくと嬉しいかも Tips【サイボウズ新人研修2025】
cybozuinsideout
PRO
11
9.1k
GitHub Copilot活用【サイボウズ新人研修2025】
cybozuinsideout
PRO
14
13k
ソフトウェアライセンス【サイボウズ新人研修2025】
cybozuinsideout
PRO
12
7.7k
エンジニアのためのアウトプット講座 〜知識をシェアするはじめの一歩〜【サイボウズ新人研修2025】
cybozuinsideout
PRO
7
4.3k
Docker入門【サイボウズ新人研修2025】
cybozuinsideout
PRO
12
10k
セキュリティ【サイボウズ新人研修2025】
cybozuinsideout
PRO
2
3.1k
TLS 1.3をざっと理解する【サイボウズ新人研修2025】
cybozuinsideout
PRO
2
1.9k
Other Decks in Technology
See All in Technology
AI時代の知識創造 ─GeminiとSECIモデルで読み解く “暗黙知”と創造の境界線
nyagasan
0
190
データ基盤の管理者からGoogle Cloud全体の管理者になっていた話
zozotech
PRO
0
300
解消したはずが…技術と人間のエラーが交錯する恐怖体験
lamaglama39
0
180
AWS表彰プログラムとキャリアについて
naoki_0531
1
150
VLMサービスを用いた請求書データ化検証 / SaaSxML_Session_1
sansan_randd
0
210
生成AI時代におけるAI・機械学習技術を用いたプロダクト開発の深化と進化 #BetAIDay
layerx
PRO
1
970
LTに影響を受けてテンプレリポジトリを作った話
hol1kgmg
0
150
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
masayoshi
1
400
With Devin -AIの自律とメンバーの自立
kotanin0
2
1.1k
【CEDEC2025】ブランド力アップのためのコンテンツマーケティング~ゲーム会社における情報資産の活かし方~
cygames
PRO
0
230
相互運用可能な学修歴クレデンシャルに向けた標準技術と国際動向
fujie
0
200
【CEDEC2025】『Shadowverse: Worlds Beyond』二度目のDCG開発でゲームをリデザインする~遊びやすさと競技性の両立~
cygames
PRO
1
280
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Into the Great Unknown - MozCon
thekraken
40
2k
Speed Design
sergeychernyshev
32
1.1k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Typedesign – Prime Four
hannesfritz
42
2.7k
We Have a Design System, Now What?
morganepeng
53
7.7k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
What's in a price? How to price your products and services
michaelherold
246
12k
Git: the NoSQL Database
bkeepers
PRO
431
65k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Designing for humans not robots
tammielis
253
25k
Transcript
CI/CD ⽣産性向上チーム 宮⽥ 淳平 1
この講義の⽬的 ▌CI/CD の基本的なところを⼀通り知ってもらう ▌キーワードを把握して今後の学習の取っ掛かりとしてもらう 2
CI/CD がない開発の例 3
各⾃の環境で開発 4
リリース前に各⾃の変更を結合して試験 5
不具合だらけ 6
修正を依頼しても原因特定が難しい 7
修正しても新たな不具合を埋め込んで以下繰り返し 8
終わりが⾒えなくて⾟い 9
問題 ▌結合のタイミングでまとめて⼤きな差分が発⽣する l 壊れやすい、原因究明が困難 ▌変更してから問題が⾒つかるまでのタイムラグが⼤きい l 学習が遅れるのでその間にも類似不具合が埋め込まれる 可能性が⾼い ▌リスク(不確実性)が⾼い l
結合後の対応がどれぐらいになるか予測しづらい 10
CI (Continuous Integration) 11
CI とは︖ ▌開発プラクティス ▌⼀⽇に何回もバージョン管理システムに変更をマージする ▌毎回テストなどを含む⾃動ビルドが実⾏される 12
CI がある開発の例 13
開発者がメインラインからタスクブランチを作成する 14
ローカルでコードを変更する 15
タスクブランチにプッシュして PR(プルリクエスト) を作成する 16
CI ツールがタスクブランチのコードでビルドを実⾏する 18
ビルドが失敗したら通るまで修正 & CI 再実⾏ 19
ビルドが成功したらメインラインにマージする 20
CI ツールがメインラインのコードでビルドを実⾏する 21
ビルドが失敗したら通るまで修正する 22
メインラインでビルドが成功したら完了 23
CI の利点 ▌⾼速なフィードバック l 問題の早期発⾒ l ⾼速な学習 ▌頻繁に変更がマージされるようになれば差分が⼤きくならない l 問題発⾒時の調査が簡単になる
l リスク(不確実性)が減る ▌Success/Fail の可視化によるコミュニケーション促進 ▌毎回の変更が⾃動テストで保証される安⼼感 24
CD (Continuous Delivery) 25
CD とは︖ ▌CI の発展型 l コードの変更がトリガーとなって実⾏されることは同じ ▌コード変更からリリースまでに必要な検証を⾏う l 常に信頼できるリリースができる状態を保つ ▌デプロイパイプラインという形で⾃動化する
l 部分的に⼿動作業が⼊ることもある 26
デプロイパイプラインの例 チェックイン トリガー ビルド& 単体テスト トリガー 結合テスト トリガー リリース 28
CD の利点 ▌リリースのコストやリスクを抑えられる l いつでもリリースできる ▌コード変更からリリースまでのフローが可視化される l どこで問題が起きてるか、どこがボトルネックか、 などがすぐにわかる 29
CI/CD 内で実⾏すること 30
静的解析 ▌構⽂チェック l 構⽂エラーを防ぐ ▌コードスタイルチェック l 可読性を⾼める、本質的でない議論を防ぐ ▌コードパターンチェック l エラーが発⽣しやすいパターンを防ぐ
31
⾃動テスト ▌ 単体テスト l ⼩さい単位のコードが役割通り動作するかチェックする ▌ 結合テスト l 複数のコードを組み合わせた機能が正しく動作するかチェックする ▌
受け⼊れテスト(E2E テスト) l ビジネス要求を満たしてるかチェックする ▌ 上記以外にもいろいろ l テストの種類ごとの呼び⽅や⽬的はチームによって異なるので、 認識を揃えることが⼤事 32
⾮機能要件のテスト ▌性能検証、脆弱性検証など ▌CI/CD にどのように組み込むかは時と場合による l 毎回実⾏するには⻑時間になりがち l 組み込めるなら組み込んだほうがいい 33
アーカイブ作成 ▌デプロイ・リリース時に使⽤するアーカイブ ▌結合テスト、E2E テスト、⾮機能要件のテストでも使⽤する l テストに通ったアーカイブをリリースする 34
デプロイ・リリース ▌ メインラインにマージされたときだけ実⾏されることが多い l タスクブランチでも動作確認⽤環境にデプロイとかはある ▌ ステージング環境 l 本番環境によく似せたステージング環境でまずデプロイする ▌
本番環境へのリリース戦略 l 万⼀の問題発⽣に備えることが重要 l ⼀部の環境から広げていく、ロールバック、無停⽌ l カナリアリリース、ブルーグリーンデプロイ、フィーチャーフラグ など 35
その他いろいろ ▌コード変更からリリースまでに必要なことはなんでも ▌デプロイパイプライン作成後もどんどん変化していく 36
CI/CD ツール 37
Jenkins ▌OSS ▌オンプレ構築できる ▌コミュニティが⼤きいのでプラグインが豊富 ▌柔軟でやろうと思えばなんでもできる 38
CircleCI ▌クラウドサービス l オンプレ版の CircleCI Server もサイボウズで利⽤してます ▌シンプル、導⼊しやすい ▌認証とか権限とか GitHub
と連携してるので導⼊が楽 40
GitHub Actions ▌GitHub が提供する CI/CD サービス ▌パブリックリポジトリでは完全無料 ▌CI/CD に限らず GitHub
の様々なイベントにフックできる 42
その他の CI/CD ツール ▌AWS Code シリーズ l CodeBuild, CodeDeploy, CodePipeline,
... l AWS と権限周りを統合しやすい ▌Kubernetes ⽤ CD ツール l Argo CD など l GitOps と呼ばれる⼿法がよく使われる l https://www.weave.works/technologies/gitops/ 43
CI/CD 導⼊ 44
新規開発への導⼊ ▌最初から CI/CD を導⼊するのがおすすめ ▌後回しにすると⾃動化しづらい作りになってしまいがち 45
既存開発への途中からの導⼊ ▌レガシーな部分が原因で難易度が上がりがち ▌⼿を付けやすく効果の⾼そうなところから始めるのがおすすめ l ビジネス的に重要な部分の正常系テストとか ▌いきなり⻑時間かかるジョブを構築するのはおすすめしない 46
CI/CD は⼀⽇にしてならず ▌すべてを⼀気に導⼊する必要はない l コスパのよさそうなところから徐々に ▌決まった型はない l ソフトウェアやチームの性質による ▌チームで認識を合わせることも⼤事 ▌プロダクトと同じで
CI/CD も継続的に改善していく 47
⾃動化する時間がない︖ ▌⾃動化しないから時間がないのです 48
うまく回らないとき ▌チームで振り返る ▌他のチームの運⽤を参考にする ▌詳しそうな⼈に相談する 49
アンチパターンとベストプラクティス 50
ローカルで⻑時間開発しすぎる ▌変更差分が⼤きくなる l 他の開発者の変更と衝突しやすい l 壊れやすい l 原因究明が困難 ▌変更してから問題が⾒つかるまでのタイムラグが⼤きくなる l
問題に気づくのが遅れるほど対応コストは⼤きくなる 51
頻繁に変更をバージョン管理システムにコミットする ▌⽬安的には全員が 1 ⽇ 1 回以上 ▌コミットが⼤きくなりすぎないように意味単位で分割する l 問題発⾒やレビューが簡単になる ▌タスクも粒度が⼩さくなるように分割したほうが不確実性が減る
52
ビルドの実⾏頻度が低い ▌⼀⽇に⼀回とかしか実⾏されないケース ▌ビルド失敗時にどの変更が原因かわかりにくい ▌変更してから問題が⾒つかるまでのタイムラグが⼤きくなる l 問題に気づくのが遅れるほど(ry 53
すべてのコミットでビルドを実⾏する ▌ビルドが失敗したときは直前のコミットが原因の可能性が⾼い l 調査しやすい ▌フィードバックが早い l 対応コストが⼩さくなる 54
ビルドが失敗しても放置される ▌属⼈的になりがち ▌誰も対応しなくなると CI/CD の利点がすべて失われる 55
ビルドが失敗したらチームは最優先で復旧する ▌ビルド失敗=リリースできない問題が存在する ▌⽬安は 10 分以内 l 直前の変更をリバートするのが⼀番楽 ▌ビルド失敗はチームメンバー全員が⾒てるところに通知する l 状態が可視化され、コミュニケーションが円滑になる
56
https://blog.cybozu.io/entry/2386 57
CI/CD のビルド時間が⻑すぎる ▌結合テストや受け⼊れテストを厚くしすぎるとなりがち ▌1 時間以上とかになってくると厳しい l 失敗時に再実⾏することとかを考えると⾟い 58
CI/CD を⾼速に保つ ▌可能な限り並列実⾏する ▌⾃動テストの役割を継続的に⾒直す l テストピラミッドを意識する 59
テストピラミッド GUI Test API Test Unit Test
テストピラミッドのポイント ▌いろいろな粒度のテストを組み合わせる ▌粒度が⼤きくなるほど実⾏時間やメンテナンスコストが⾼くなる ▌より⼩さい粒度のテストで防げるものは防ぐ 61
不安定なビルド ▌不具合ではないのにビルドが失敗する l CI/CD の信頼性が下がる ▌原因はいろいろ l 本番コードではないので書かれる⼿抜きスクリプト l E2E
テストの微妙なタイミングのズレ l 不安定な環境 l 構築⼿順が微妙に異なる、前のビルドのゴミが残ってる、など 62
ビルドを継続的に改善して品質を⾼める ▌ビルドで実⾏されるタスクは製品コードレベルの品質を⽬指す l 特にメンテナンス性を⾼めることが⼤事 ▌ビルド結果を計測する l ビルドの失敗頻度やその原因を振り返れるようにしておくと あとから改善しやすい ▌防ぎづらいレアケースもあるので⾃動リトライも⼀つの⼿段 ▌環境は仮想化して毎回クリーンにする
l Docker コンテナ内でビルドするのが最近は⼀般的 63
まとめ 64
意識してほしいこと ▌⾼速なフィードバックループは不確実性を下げ、学びを最⼤化する l 顧客へ提供する価値の最⼤化につながる l 例えば Amazon では毎秒なにかしら本番環境にデプロイしてる ▌ボトルネックを意識してバランス感覚を持って⾃動化する ▌リリースしてようやく顧客に価値を提供できる
l コードを変更して終わりではない l チーム全体でリリースやその後のフィードバックまで責任を持つ 65
参考⽂献 ▌『継続的インテグレーション⼊⾨』 ▌『継続的デリバリー』 69