Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
CI/CD 生産性向上チーム 宮田 淳平 1
Slide 2
Slide 2 text
この講義の目的 ▌CI/CD の基本的なところを一通り知ってもらう ▌キーワードを把握して今後の学習の取っ掛かりとしてもらう 2
Slide 3
Slide 3 text
CI/CD がない開発の例 3
Slide 4
Slide 4 text
各自の環境で開発 4
Slide 5
Slide 5 text
リリース前に各自の変更を結合して試験 5
Slide 6
Slide 6 text
不具合だらけ 6
Slide 7
Slide 7 text
修正を依頼しても原因特定が難しい 7
Slide 8
Slide 8 text
修正しても新たな不具合を埋め込んで以下繰り返し 8
Slide 9
Slide 9 text
終わりが見えなくて辛い 9
Slide 10
Slide 10 text
問題 ▌結合のタイミングでまとめて大きな差分が発生する ⚫ 壊れやすい、原因究明が困難 ▌変更してから問題が見つかるまでのタイムラグが大きい ⚫ 学習が遅れるのでその間にも類似不具合が埋め込まれる 可能性が高い ▌リスク(不確実性)が高い ⚫ 結合後の対応がどれぐらいになるか予測しづらい 10
Slide 11
Slide 11 text
CI (Continuous Integration) 11
Slide 12
Slide 12 text
CI とは? ▌開発プラクティス ▌一日に何回もバージョン管理システムに変更をマージする ▌毎回テストなどを含む自動ビルドが実行される 12
Slide 13
Slide 13 text
CI がある開発の例 13
Slide 14
Slide 14 text
開発者がメインラインからタスクブランチを作成する 14 master Task A
Slide 15
Slide 15 text
ローカルでコードを変更する 15 master Task A
Slide 16
Slide 16 text
タスクブランチにプッシュして PR(プルリクエスト) を作成する 16 master Task A
Slide 17
Slide 17 text
(メインラインとの衝突があればマージして修正する) 17 master Task A
Slide 18
Slide 18 text
CI ツールがタスクブランチのコードでビルドを実行する 18 master Task A CI
Slide 19
Slide 19 text
ビルドが失敗したら通るまで修正 & CI 再実行 19 master Task A CI
Slide 20
Slide 20 text
ビルドが成功したらメインラインにマージする 20 master Task A CI
Slide 21
Slide 21 text
CI ツールがメインラインのコードでビルドを実行する 21 master Task A CI
Slide 22
Slide 22 text
ビルドが失敗したら通るまで修正する 22 master Task A CI
Slide 23
Slide 23 text
メインラインでビルドが成功したら完了 23 master Task A CI
Slide 24
Slide 24 text
CI の利点 ▌高速なフィードバック ⚫ 問題の早期発見 ⚫ 高速な学習 ▌頻繁に変更がマージされるようになれば差分が大きくならない ⚫ 問題発見時の調査が簡単になる ⚫ リスク(不確実性)が減る ▌Success/Fail の可視化によるコミュニケーション促進 ▌毎回の変更が自動テストで保証される安心感 24
Slide 25
Slide 25 text
CD (Continuous Delivery) 25
Slide 26
Slide 26 text
CD とは? ▌CI の発展形 ⚫ コードの変更がトリガーとなって実行されることは同じ ▌コード変更からリリースまでに必要な検証を行う ⚫ 常に信頼できるリリースができる状態を保つ ▌デプロイパイプラインという形で自動化する ⚫ 部分的に手動作業が入ることもある 26
Slide 27
Slide 27 text
https://en.wikipedia.org/wiki/Continuous_delivery より 27
Slide 28
Slide 28 text
CD の利点 ▌リリースのコストやリスクを抑えられる ⚫ いつでもリリースできる ▌コード変更からリリースまでのフローが可視化される ⚫ どこで問題が起きてるか、どこがボトルネックか、 などがすぐにわかる 28
Slide 29
Slide 29 text
CI/CD 内で実行すること 29
Slide 30
Slide 30 text
静的解析 ▌構文チェック ⚫ 構文エラーを防ぐ ▌コードスタイルチェック ⚫ 可読性を高める、本質的でない議論を防ぐ ▌コードパターンチェック ⚫ エラーが発生しやすいパターンを防ぐ 30
Slide 31
Slide 31 text
自動テスト ▌ 単体テスト ⚫ 小さい単位のコードが役割通り動作するかチェックする ▌ 結合テスト ⚫ 複数のコードを組み合わせた機能が正しく動作するかチェックする ▌ 受け入れテスト(E2E テスト) ⚫ ビジネス要求を満たしてるかチェックする ▌ 上記以外にもいろいろ ⚫ テストの種類ごとの呼び方や目的はチームによって異なるので、 認識を揃えることが大事 31
Slide 32
Slide 32 text
非機能要件のテスト ▌性能検証 ▌脆弱性検証 ▌CI/CD にどのように組み込むかは時と場合による ⚫ 毎回実行するには長時間になりがち ⚫ 組み込めるなら組み込んだほうがいい 32
Slide 33
Slide 33 text
アーカイブ作成 ▌デプロイ・リリース時に使用するアーカイブ ▌結合テスト、E2E テスト、非機能要件のテストでも使用する ⚫ テストに通ったアーカイブをリリースする 33
Slide 34
Slide 34 text
デプロイ・リリース ▌メインラインにマージされたときだけ実行されることが多い ⚫ タスクブランチでも動作確認用環境にデプロイとかはある ▌ステージング環境 ⚫ 本番環境によく似せたステージング環境でまずデプロイする ▌本番環境へのリリース戦略 ⚫ 万一の問題発生に備えることが重要 ⚫ 一部の環境から広げていく、ロールバック、無停止 ⚫ カナリアリリース、ブルーグリーンデプロイ、フィーチャーフラグ など 34
Slide 35
Slide 35 text
その他いろいろ ▌コード変更からリリースまでに必要なことはなんでも ▌デプロイパイプライン作成後もどんどん変化していく 35
Slide 36
Slide 36 text
社内で利用されている CI/CD ツール 36
Slide 37
Slide 37 text
Jenkins ▌OSS ▌オンプレ構築できる ▌コミュニティが大きいのでプラグインが豊富 ▌柔軟でやろうと思えばなんでもできる 37
Slide 38
Slide 38 text
38
Slide 39
Slide 39 text
CircleCI ▌クラウドサービス ⚫ オンプレ版の CircleCI Server も社内で利用してます ▌プラグインとかなくてシンプル、導入しやすい ▌認証とか権限とか GitHub と連携してるので導入が楽 39
Slide 40
Slide 40 text
40
Slide 41
Slide 41 text
その他いろいろ ▌AWS Code シリーズ ⚫ CodeBuild, CodeDeploy, CodePipeline, ... ⚫ AWS と権限周りを統合しやすい ⚫ 使い勝手が微妙なので CodeBuild ぐらいしか使われてない ▌Argo CD ⚫ Kubernetes 用 CD ツール ⚫ GitOps できる ⚫ https://www.weave.works/technologies/gitops/ 41
Slide 42
Slide 42 text
CI/CD 導入 42
Slide 43
Slide 43 text
新規開発への導入 ▌最初から CI/CD を導入するのがおすすめ ▌後回しにすると自動化しづらい作りになってしまいがち 43
Slide 44
Slide 44 text
途中から導入 ▌レガシーな部分が原因で難易度が上がりがち ⚫ 『レガシーコード改善ガイド』 ▌手を付けやすく効果の高そうなところから ⚫ ビジネス的に重要な部分の正常系テストとか ▌いきなり長時間かかるジョブを構築するのはおすすめしない 44
Slide 45
Slide 45 text
CI/CD は一日にしてならず ▌すべてを一気に導入する必要はない ⚫ コスパのよさそうなところから徐々に ▌決まった型はない ⚫ ソフトウェアやチームの性質による ▌チームで認識を合わせることも大事 ▌プロダクトと同じで CI/CD も継続的に改善していく 45
Slide 46
Slide 46 text
自動化する時間がない? ▌自動化しないから時間がないのです 46
Slide 47
Slide 47 text
うまく回らないとき ▌チームで振り返る ▌他のチームの運用を参考にする ▌詳しそうな人に相談する 47
Slide 48
Slide 48 text
アンチパターンとベストプラクティス 48
Slide 49
Slide 49 text
ローカルで長時間開発しすぎる ▌変更差分が大きくなる ⚫ 他の開発者の変更と衝突しやすい ⚫ 壊れやすい ⚫ 原因究明が困難 ▌変更してから問題が見つかるまでのタイムラグが大きくなる ⚫ 問題に気づくのが遅れるほど対応コストは大きくなる 49
Slide 50
Slide 50 text
頻繁に変更をバージョン管理システムにコミットする ▌目安的には全員が 1 日 1 回以上 ▌コミットが大きくなりすぎないように意味単位で分割する ⚫ 問題発見やレビューが簡単になる ▌タスクも粒度が小さくなるように分割したほうが不確実性が減る 50
Slide 51
Slide 51 text
ビルドの実行頻度が低い ▌一日に一回とかしか実行されないケース ▌ビルド失敗時にどの変更が原因かわかりにくい ▌変更してから問題が見つかるまでのタイムラグが大きくなる ⚫ 問題に気づくのが遅れるほど(ry 51
Slide 52
Slide 52 text
すべてのコミットでビルドを実行する ▌ビルドが失敗したときは直前のコミットが原因の可能性が高い ⚫ 調査しやすい ▌フィードバックが早い ⚫ 対応コストが小さくなる 52
Slide 53
Slide 53 text
ビルドが失敗しても放置される ▌属人的になりがち ▌誰も対応しなくなると CI/CD の利点がすべて失われる 53
Slide 54
Slide 54 text
ビルドが失敗したらチームは最優先で復旧する ▌ビルド失敗=リリースできない問題が存在する ▌目安は 10 分以内 ⚫ 直前の変更をリバートするのが一番楽 ▌ビルド失敗はチームメンバー全員が見てるところに通知する ⚫ 状態が可視化され、コミュニケーションが円滑になる 54
Slide 55
Slide 55 text
55 https://blog.cybozu.io/entry/2386
Slide 56
Slide 56 text
CI/CD のビルド時間が長すぎる ▌結合テストや受け入れテストを厚くしすぎるとなりがち ▌1 時間以上とかになってくると厳しい ⚫ 失敗時に再実行することとかを考えると辛い 56
Slide 57
Slide 57 text
CI/CD を高速に保つ ▌可能な限り並列実行する ▌自動テストの役割を継続的に見直す ⚫ テストピラミッドを意識する 57
Slide 58
Slide 58 text
テストピラミッド GUI Test API Test Unit Test
Slide 59
Slide 59 text
テストピラミッド ▌いろいろな粒度のテストを組み合わせる ▌粒度が大きくなるほど実行時間やメンテナンスコストが高くなる ▌より小さい粒度のテストで防げるものは防ぐ 59
Slide 60
Slide 60 text
不安定なビルド ▌不具合ではないのにビルドが失敗する ⚫ CI/CD の信頼性が下がる ▌原因はいろいろ ⚫ 本番コードではないので書かれる手抜きスクリプト ⚫ E2E テストの微妙なタイミングのズレ ⚫ 不安定な環境 ⚫ 構築手順が微妙に異なる、前のビルドのゴミが残ってる、など 60
Slide 61
Slide 61 text
ビルドを継続的に改善して品質を高める ▌ビルドで実行されるタスクは製品コードレベルの品質を目指す ⚫ 特にメンテナンス性を高めることが大事 ▌ビルド結果を計測する ⚫ ビルドの失敗頻度やその原因を振り返れるようにしておくと あとから改善しやすい ▌防ぎづらいレアケースもあるので自動リトライも一つの手段 ▌環境は仮想化して毎回クリーンにする ⚫ Docker コンテナ内でビルドするのが最近は一般的 61
Slide 62
Slide 62 text
まとめ 62
Slide 63
Slide 63 text
意識してほしいこと ▌高速なフィードバックループは不確実性を下げ、学びを最大化する ⚫ 顧客へ提供する価値の最大化につながる ⚫ 例えば Amazon では毎秒なにかしら本番環境にデプロイしてる ▌ボトルネックを意識してバランス感覚を持って自動化する ▌リリースしてようやく顧客に価値を提供できる ⚫ コードを変更して終わりではない ⚫ チーム全体でリリースやその後のフィードバックまで責任を持つ 63
Slide 64
Slide 64 text
時間あればその他小ネタ 64
Slide 65
Slide 65 text
Continuous Delivery vs Continuous Deployment ▌コード変更ごとにリリースまでの検証を行うのはどちらも同じ ▌Continuous Delivery ⚫ 毎回本番環境にリリースするとは限らない ▌Continuous Deployment ⚫ 毎回本番環境へのリリースまで自動で行う ▌どちらを選ぶかは時と場合に合わせて 65
Slide 66
Slide 66 text
DevOps ▌CI/CD より広いスコープを扱ってる ⚫ 顧客に価値を提供する組織文化、プロセス、 技術的プラクティスなど ⚫ 厳密な定義はない ▌去年ざっくり講義したので興味ある人はどうぞ ⚫ https://speakerdeck.com/cybozuinsideout/2018-14- devops 66
Slide 67
Slide 67 text
参考文献 ▌『継続的インテグレーション入門』 ▌『継続的デリバリー』 67