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
2019-14 CI CD
Search
Cybozu
PRO
July 10, 2019
Technology
6
160k
2019-14 CI CD
Cybozu
PRO
July 10, 2019
Tweet
Share
More Decks by Cybozu
See All by Cybozu
Recruitment Pitch in New Business Division
cybozuinsideout
PRO
0
12
サイボウズ Office/メールワイズチームの改善の取り組み「困りごと共有会」
cybozuinsideout
PRO
1
16
サイボウズのOSPO
cybozuinsideout
PRO
1
91
非エンジニアの私が試行錯誤の末見出したスクラムマスターの道
cybozuinsideout
PRO
2
130
Kubernetes でもJava アプリでTLS 接続を終端したい
cybozuinsideout
PRO
2
150
Google I/O - 2024 What’s new in flutter
cybozuinsideout
PRO
2
260
Waffle Festival2024(斉藤裕希)
cybozuinsideout
PRO
3
560
主体的な活動で巨大な影響範囲のテストを乗りこなしていく話
cybozuinsideout
PRO
2
360
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
40k
Other Decks in Technology
See All in Technology
Git 研修 Basic【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
310
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
Matterport を使ってクラスメソッド各拠点のバーチャルオフィスツアーを作成してみた
wakatsuki
0
160
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
13
3.6k
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
220
地理情報とAPIのトレンド
nagix
0
160
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
130
スレットハンティングについて知っておきたいこと
hacket
0
130
Scaling Technical Excellence at 104: Evolution in AWS and Developer Empowerment
scotthsieh825
1
160
AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略(JAWS-UG朝会#59資料改修20分版)
htan
0
330
累計ダウンロード数1億8000万を超えるアプリケーションプラットフォームのレガシーシステム脱却とモダン化への道
kmitsuhashi
0
120
Azure AI ことはじめ
tsubakimoto_s
0
130
Featured
See All Featured
Pencils Down: Stop Designing & Start Developing
hursman
118
11k
Designing with Data
zakiwarfel
96
5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
17
1.5k
BBQ
matthewcrist
82
9k
Learning to Love Humans: Emotional Interface Design
aarron
269
39k
Testing 201, or: Great Expectations
jmmastey
33
6.9k
Teambox: Starting and Learning
jrom
130
8.6k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
20
7.2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
17
8.7k
Faster Mobile Websites
deanohume
303
30k
Art, The Web, and Tiny UX
lynnandtonic
291
20k
The Language of Interfaces
destraynor
151
23k
Transcript
CI/CD 生産性向上チーム 宮田 淳平 1
この講義の目的 ▌CI/CD の基本的なところを一通り知ってもらう ▌キーワードを把握して今後の学習の取っ掛かりとしてもらう 2
CI/CD がない開発の例 3
各自の環境で開発 4
リリース前に各自の変更を結合して試験 5
不具合だらけ 6
修正を依頼しても原因特定が難しい 7
修正しても新たな不具合を埋め込んで以下繰り返し 8
終わりが見えなくて辛い 9
問題 ▌結合のタイミングでまとめて大きな差分が発生する ⚫ 壊れやすい、原因究明が困難 ▌変更してから問題が見つかるまでのタイムラグが大きい ⚫ 学習が遅れるのでその間にも類似不具合が埋め込まれる 可能性が高い ▌リスク(不確実性)が高い ⚫
結合後の対応がどれぐらいになるか予測しづらい 10
CI (Continuous Integration) 11
CI とは? ▌開発プラクティス ▌一日に何回もバージョン管理システムに変更をマージする ▌毎回テストなどを含む自動ビルドが実行される 12
CI がある開発の例 13
開発者がメインラインからタスクブランチを作成する 14 master Task A
ローカルでコードを変更する 15 master Task A
タスクブランチにプッシュして PR(プルリクエスト) を作成する 16 master Task A
(メインラインとの衝突があればマージして修正する) 17 master Task A
CI ツールがタスクブランチのコードでビルドを実行する 18 master Task A CI
ビルドが失敗したら通るまで修正 & CI 再実行 19 master Task A CI
ビルドが成功したらメインラインにマージする 20 master Task A CI
CI ツールがメインラインのコードでビルドを実行する 21 master Task A CI
ビルドが失敗したら通るまで修正する 22 master Task A CI
メインラインでビルドが成功したら完了 23 master Task A CI
CI の利点 ▌高速なフィードバック ⚫ 問題の早期発見 ⚫ 高速な学習 ▌頻繁に変更がマージされるようになれば差分が大きくならない ⚫ 問題発見時の調査が簡単になる
⚫ リスク(不確実性)が減る ▌Success/Fail の可視化によるコミュニケーション促進 ▌毎回の変更が自動テストで保証される安心感 24
CD (Continuous Delivery) 25
CD とは? ▌CI の発展形 ⚫ コードの変更がトリガーとなって実行されることは同じ ▌コード変更からリリースまでに必要な検証を行う ⚫ 常に信頼できるリリースができる状態を保つ ▌デプロイパイプラインという形で自動化する
⚫ 部分的に手動作業が入ることもある 26
https://en.wikipedia.org/wiki/Continuous_delivery より 27
CD の利点 ▌リリースのコストやリスクを抑えられる ⚫ いつでもリリースできる ▌コード変更からリリースまでのフローが可視化される ⚫ どこで問題が起きてるか、どこがボトルネックか、 などがすぐにわかる 28
CI/CD 内で実行すること 29
静的解析 ▌構文チェック ⚫ 構文エラーを防ぐ ▌コードスタイルチェック ⚫ 可読性を高める、本質的でない議論を防ぐ ▌コードパターンチェック ⚫ エラーが発生しやすいパターンを防ぐ
30
自動テスト ▌ 単体テスト ⚫ 小さい単位のコードが役割通り動作するかチェックする ▌ 結合テスト ⚫ 複数のコードを組み合わせた機能が正しく動作するかチェックする ▌
受け入れテスト(E2E テスト) ⚫ ビジネス要求を満たしてるかチェックする ▌ 上記以外にもいろいろ ⚫ テストの種類ごとの呼び方や目的はチームによって異なるので、 認識を揃えることが大事 31
非機能要件のテスト ▌性能検証 ▌脆弱性検証 ▌CI/CD にどのように組み込むかは時と場合による ⚫ 毎回実行するには長時間になりがち ⚫ 組み込めるなら組み込んだほうがいい 32
アーカイブ作成 ▌デプロイ・リリース時に使用するアーカイブ ▌結合テスト、E2E テスト、非機能要件のテストでも使用する ⚫ テストに通ったアーカイブをリリースする 33
デプロイ・リリース ▌メインラインにマージされたときだけ実行されることが多い ⚫ タスクブランチでも動作確認用環境にデプロイとかはある ▌ステージング環境 ⚫ 本番環境によく似せたステージング環境でまずデプロイする ▌本番環境へのリリース戦略 ⚫ 万一の問題発生に備えることが重要
⚫ 一部の環境から広げていく、ロールバック、無停止 ⚫ カナリアリリース、ブルーグリーンデプロイ、フィーチャーフラグ など 34
その他いろいろ ▌コード変更からリリースまでに必要なことはなんでも ▌デプロイパイプライン作成後もどんどん変化していく 35
社内で利用されている CI/CD ツール 36
Jenkins ▌OSS ▌オンプレ構築できる ▌コミュニティが大きいのでプラグインが豊富 ▌柔軟でやろうと思えばなんでもできる 37
38
CircleCI ▌クラウドサービス ⚫ オンプレ版の CircleCI Server も社内で利用してます ▌プラグインとかなくてシンプル、導入しやすい ▌認証とか権限とか GitHub
と連携してるので導入が楽 39
40
その他いろいろ ▌AWS Code シリーズ ⚫ CodeBuild, CodeDeploy, CodePipeline, ... ⚫
AWS と権限周りを統合しやすい ⚫ 使い勝手が微妙なので CodeBuild ぐらいしか使われてない ▌Argo CD ⚫ Kubernetes 用 CD ツール ⚫ GitOps できる ⚫ https://www.weave.works/technologies/gitops/ 41
CI/CD 導入 42
新規開発への導入 ▌最初から CI/CD を導入するのがおすすめ ▌後回しにすると自動化しづらい作りになってしまいがち 43
途中から導入 ▌レガシーな部分が原因で難易度が上がりがち ⚫ 『レガシーコード改善ガイド』 ▌手を付けやすく効果の高そうなところから ⚫ ビジネス的に重要な部分の正常系テストとか ▌いきなり長時間かかるジョブを構築するのはおすすめしない 44
CI/CD は一日にしてならず ▌すべてを一気に導入する必要はない ⚫ コスパのよさそうなところから徐々に ▌決まった型はない ⚫ ソフトウェアやチームの性質による ▌チームで認識を合わせることも大事 ▌プロダクトと同じで
CI/CD も継続的に改善していく 45
自動化する時間がない? ▌自動化しないから時間がないのです 46
うまく回らないとき ▌チームで振り返る ▌他のチームの運用を参考にする ▌詳しそうな人に相談する 47
アンチパターンとベストプラクティス 48
ローカルで長時間開発しすぎる ▌変更差分が大きくなる ⚫ 他の開発者の変更と衝突しやすい ⚫ 壊れやすい ⚫ 原因究明が困難 ▌変更してから問題が見つかるまでのタイムラグが大きくなる ⚫
問題に気づくのが遅れるほど対応コストは大きくなる 49
頻繁に変更をバージョン管理システムにコミットする ▌目安的には全員が 1 日 1 回以上 ▌コミットが大きくなりすぎないように意味単位で分割する ⚫ 問題発見やレビューが簡単になる ▌タスクも粒度が小さくなるように分割したほうが不確実性が減る
50
ビルドの実行頻度が低い ▌一日に一回とかしか実行されないケース ▌ビルド失敗時にどの変更が原因かわかりにくい ▌変更してから問題が見つかるまでのタイムラグが大きくなる ⚫ 問題に気づくのが遅れるほど(ry 51
すべてのコミットでビルドを実行する ▌ビルドが失敗したときは直前のコミットが原因の可能性が高い ⚫ 調査しやすい ▌フィードバックが早い ⚫ 対応コストが小さくなる 52
ビルドが失敗しても放置される ▌属人的になりがち ▌誰も対応しなくなると CI/CD の利点がすべて失われる 53
ビルドが失敗したらチームは最優先で復旧する ▌ビルド失敗=リリースできない問題が存在する ▌目安は 10 分以内 ⚫ 直前の変更をリバートするのが一番楽 ▌ビルド失敗はチームメンバー全員が見てるところに通知する ⚫ 状態が可視化され、コミュニケーションが円滑になる
54
55 https://blog.cybozu.io/entry/2386
CI/CD のビルド時間が長すぎる ▌結合テストや受け入れテストを厚くしすぎるとなりがち ▌1 時間以上とかになってくると厳しい ⚫ 失敗時に再実行することとかを考えると辛い 56
CI/CD を高速に保つ ▌可能な限り並列実行する ▌自動テストの役割を継続的に見直す ⚫ テストピラミッドを意識する 57
テストピラミッド GUI Test API Test Unit Test
テストピラミッド ▌いろいろな粒度のテストを組み合わせる ▌粒度が大きくなるほど実行時間やメンテナンスコストが高くなる ▌より小さい粒度のテストで防げるものは防ぐ 59
不安定なビルド ▌不具合ではないのにビルドが失敗する ⚫ CI/CD の信頼性が下がる ▌原因はいろいろ ⚫ 本番コードではないので書かれる手抜きスクリプト ⚫ E2E
テストの微妙なタイミングのズレ ⚫ 不安定な環境 ⚫ 構築手順が微妙に異なる、前のビルドのゴミが残ってる、など 60
ビルドを継続的に改善して品質を高める ▌ビルドで実行されるタスクは製品コードレベルの品質を目指す ⚫ 特にメンテナンス性を高めることが大事 ▌ビルド結果を計測する ⚫ ビルドの失敗頻度やその原因を振り返れるようにしておくと あとから改善しやすい ▌防ぎづらいレアケースもあるので自動リトライも一つの手段 ▌環境は仮想化して毎回クリーンにする
⚫ Docker コンテナ内でビルドするのが最近は一般的 61
まとめ 62
意識してほしいこと ▌高速なフィードバックループは不確実性を下げ、学びを最大化する ⚫ 顧客へ提供する価値の最大化につながる ⚫ 例えば Amazon では毎秒なにかしら本番環境にデプロイしてる ▌ボトルネックを意識してバランス感覚を持って自動化する ▌リリースしてようやく顧客に価値を提供できる
⚫ コードを変更して終わりではない ⚫ チーム全体でリリースやその後のフィードバックまで責任を持つ 63
時間あればその他小ネタ 64
Continuous Delivery vs Continuous Deployment ▌コード変更ごとにリリースまでの検証を行うのはどちらも同じ ▌Continuous Delivery ⚫ 毎回本番環境にリリースするとは限らない
▌Continuous Deployment ⚫ 毎回本番環境へのリリースまで自動で行う ▌どちらを選ぶかは時と場合に合わせて 65
DevOps ▌CI/CD より広いスコープを扱ってる ⚫ 顧客に価値を提供する組織文化、プロセス、 技術的プラクティスなど ⚫ 厳密な定義はない ▌去年ざっくり講義したので興味ある人はどうぞ ⚫
https://speakerdeck.com/cybozuinsideout/2018-14- devops 66
参考文献 ▌『継続的インテグレーション入門』 ▌『継続的デリバリー』 67