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
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
45k
テクニカルライティング
cybozuinsideout
PRO
4
300
サイボウズのアジャイルクオリティ2024
cybozuinsideout
PRO
3
270
モブに早く慣れたい人のためのガイド2024
cybozuinsideout
PRO
3
370
モバイル
cybozuinsideout
PRO
3
190
ソフトウェアライセンス
cybozuinsideout
PRO
4
160
ソフトウェアテスト
cybozuinsideout
PRO
3
260
自動テスト
cybozuinsideout
PRO
3
270
Docker入門2024
cybozuinsideout
PRO
3
460
Other Decks in Technology
See All in Technology
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
370
あなたの知らない Function.prototype.toString() の世界
mizdra
PRO
0
120
アプリエンジニアのためのGraphQL入門.pdf
spycwolf
0
100
強いチームと開発生産性
onk
PRO
35
11k
EventHub Startup CTO of the year 2024 ピッチ資料
eventhub
0
130
エンジニア人生の拡張性を高める 「探索型キャリア設計」の提案
tenshoku_draft
1
130
Adopting Jetpack Compose in Your Existing Project - GDG DevFest Bangkok 2024
akexorcist
0
110
ドメインの本質を掴む / Get the essence of the domain
sinsoku
2
160
Shopifyアプリ開発における Shopifyの機能活用
sonatard
4
260
ISUCONに強くなるかもしれない日々の過ごしかた/Findy ISUCON 2024-11-14
fujiwara3
8
880
Lambdaと地方とコミュニティ
miu_crescent
2
370
AWS Lambda のトラブルシュートをしていて思うこと
kazzpapa3
2
180
Featured
See All Featured
Making Projects Easy
brettharned
115
5.9k
Typedesign – Prime Four
hannesfritz
40
2.4k
RailsConf 2023
tenderlove
29
900
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Why Our Code Smells
bkeepers
PRO
334
57k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
The Cult of Friendly URLs
andyhume
78
6k
Designing Experiences People Love
moore
138
23k
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