Tweet
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