2019-14 CI CD - Speaker Deck

2019-14 CI CD

by Cybozu

Embed

Start on current slide

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

Slide 39

Slide 39 text

CircleCI ▌クラウドサービス ⚫ オンプレ版の CircleCI Server も社内で利用してます ▌プラグインとかなくてシンプル、導入しやすい ▌認証とか権限とか GitHub と連携してるので導入が楽 39

Slide 40

Slide 40 text

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