Tweet
Tweet

Slide 1

Slide 1 text

1 CI/CDを使い倒して数段上の ソフトウェア開発しよう #devsumi #circlecijp

Slide 2

Slide 2 text

2 CI/CD 戦国時代 Google GCP Cloud Build Microsoft Azure Pipelines AWS CodeBuild GitHub Actions

Slide 3

Slide 3 text

3 CI/CD 戦国時代

Slide 4

Slide 4 text

4 最初の疑問 なぜCI/CDへの関心がこれほど高まっているのか？

Slide 5

Slide 5 text

5 自己紹介: Kim, Hirokuni (金 洋国) - 元CircleCI 開発者 - CircleCI Japan TechLead - CircleCI SRE

Slide 6

Slide 6 text

6 モチベーションについて

Slide 7

Slide 7 text

7 このセッションの基本の流れ What Why Why Not Beyond

Slide 8

Slide 8 text

8 宣伝 (会社) ● 日本語サポート ● ドキュメントの日本語化 ● ユーザーコミュニティー CircleCI初の海外支社 @CircleCIJapan FB Community Group

Slide 9

Slide 9 text

9 CI / 継続的インテグレーション

Slide 10

Slide 10 text

10 What is CI?

Slide 11

Slide 11 text

11 その前に確認 もちろんテストは書いてますよね？

Slide 12

Slide 12 text

12 なぜテストを書くべきか ● 何度も同じ手順を繰り返さないといけない ● 人の目や手に頼ると必ず見落としが発生する

Slide 13

Slide 13 text

13 なぜテストを書くべきか ● 何度も同じ手順を繰り返さないといけない ● 人の目や手に頼ると必ず見落としが発生する それコンピューターにやらせようよ！

Slide 14

Slide 14 text

14 CIとはテストを自動で実行する仕組み 開発者のコード変更に対して ● 常に ● 同じ環境で テストを実行してくれる

Slide 15

Slide 15 text

15 CIとはテストを自動で実行する仕組み 開発者のコード変更に対して ● 常に ● 同じ環境で テストを実行してくれる ※ テストは自分たちで用意する必要がある

Slide 16

Slide 16 text

16 Why CI?

Slide 17

Slide 17 text

17 ただテストを書くだけでは不十分 ● テストがあるけど実行し忘れた ● 昔書いたテストが壊れていて動かない ● テスト結果が環境依存

Slide 18

Slide 18 text

18 ただテストを書くだけでは不十分 ● テストがあるけど実行し忘れた ● 昔書いたテストが壊れていて動かない ● テスト結果が環境依存 テストの信頼性がない

Slide 19

Slide 19 text

19 問題: テストの実行忘れ ● リリース前にテストをしわすれる ● バグを見落とす ● 修正でリリースが遅れる

Slide 20

Slide 20 text

20 解答: 常にテストを回す ● GitHub (VCS)の変更をCI/CDが検知 ● 全変更に対してテスト実行

Slide 21

Slide 21 text

21 問題: テストが壊れてしまう ● 古いテストが壊れている ● テストが悪いのかコードがわからない

Slide 22

Slide 22 text

22 解答: 壊れたテストを素早く検知 ● テストが壊れた時点で検知 ● 直さないとマージできない (後述）

Slide 23

Slide 23 text

23 使われていない自動化は壊れていく “サイボウズを支える CircleCI”より

Slide 24

Slide 24 text

24 問題: テスト結果が環境依存 僕のマシンだとテスト通ってます (｀・ω・´) ｷﾘｯ

Slide 25

Slide 25 text

25 例: テスト環境の差異による問題 CreateNewBook 古いBookレコード CheckNewBookCreated テストPass バグ False Negative テスト対象 テスト ローカルDBに残っているデータのせいで CreateNewBookのバグを検知し損ねる

Slide 26

Slide 26 text

26 解答: CIを唯一のテスト環境にする ● 毎回同じテスト環境が構築される ● まっさらな環境でテストを実行 ● いつ実行しても同じテスト結果になる

Slide 27

Slide 27 text

27 CIの目的 テストの新陳代謝を高めて信頼性をあげる

Slide 28

Slide 28 text

28 Why NOT CI?

Slide 29

Slide 29 text

29 CI導入を妨げる問題 ● テストがない ● メンテナンス

Slide 30

Slide 30 text

30 問題: テストがない ● CIを始めたい ● でも実行するテストが存在しない ● テスト文化の布教にはコストと時間がかかる CIを導入する上でいちばんやっかいな問題

Slide 31

Slide 31 text

31 テストがない状態からCIを始める5ステップ Step 1: お好みのCI/CDツールを選ぶ Step 2: タスクの自動化 Step 3: 可視化する Step 4: マージブロック Step 5: テストを追加していく

Slide 32

Slide 32 text

32 Step 1: お好みのCI/CDツールを選ぶ

Slide 33

Slide 33 text

33 ステップ2: 様々なタスクを自動化しよう テスト以外のタスクを自動化 ● 構文チェック（linting) ● カバレッジ計測 ● 循環的複雑度のチェック ● ドキュメントの自動生成

Slide 34

Slide 34 text

34 ステップ3: 可視化しよう CI結果を可視化しよう ● ステータスバッジ ● ダッシュボードの作成 ● メール・チャットでの通知

Slide 35

Slide 35 text

35 CIやってる感が出てくる ”お、俺たちCIしてるっぽい”

Slide 36

Slide 36 text

36 Step 4: マージブロック有効化 マージするための条件をブランチごとに 指定できる機能 ● CIが通らないとマージできない ● 管理者しかマージできない ● Force Push禁止 ● Etc, etc CircleCIが通らないとマージできない

Slide 37

Slide 37 text

37 Step 5: テストの追加 少しずつテストを追加していく ● ユニットテストはとりあえず後回し ● 最も大事なビジネスロジック ● この時点では無理は禁物....

Slide 38

Slide 38 text

38 CI導入を妨げる問題 ● テストがない ● メンテナンス

Slide 39

Slide 39 text

39 問題: メンテナンス ● CI/CDツールのメンテナンスは大変 ● 通常専任のエンジニアが必要 ● CircleCIのようなクラウド型がおすすめ

Slide 40

Slide 40 text

40 クラウド型 VS オンプレミス型 クラウド型 オンプレミス型 AWS CodeBuild CircleCI GCP Cloud Build Travis CI Jenkins Concourse CI

Slide 41

Slide 41 text

41 CIのまとめ ● テストの信頼性と品質を向上させる ● テストがなくてもCIは始めれる ● できる自動化からはじめよう ● クラウド型のツールで運用コストを下げる

Slide 42

Slide 42 text

42 Beyond CI

Slide 43

Slide 43 text

43 開発フロー コードをPush

Slide 44

Slide 44 text

44 開発フロー コードをPush CIでテスト

Slide 45

Slide 45 text

45 開発フロー コードをPush CIでテスト masterへマージ

Slide 46

Slide 46 text

46 開発フロー コードをPush CIでテスト masterへマージ 自動

Slide 47

Slide 47 text

47 開発フロー コードをPush CIで自動テスト masterへマージ 自動 リリース 手動

Slide 48

Slide 48 text

48 CD / 継続的デプロイメント

Slide 49

Slide 49 text

49 What is CD?

Slide 50

Slide 50 text

50 CDとは？ Continuous Deployment (継続的デプロイメント) 自動でステージング・本番環境へデプロイ Continuous Delivery (継続的デリバリー) 常にリリース可能な状態を維持する

Slide 51

Slide 51 text

51 Continuous Delivery (継続的デリバリー) リリース作業に人間の意思が介在する コードプッ シュ JARファイル CI Dockerイメージ ステージング 本番環境 人間が 決定 CD Continuous Delivery

Slide 52

Slide 52 text

52 Continuous Deployment (継続的デプロイメント) リリースに人の意思が介在しない コードプッシュ JARファイル Dockerイメージ ステージング 本番環境 Continuous Delivery CD CI CD Continuous Deployment

Slide 53

Slide 53 text

53 Why CD?

Slide 54

Slide 54 text

54 リリース後に発覚する仕様バグ ● リリースして実際に使ってみた ● ユーザーの要求を満たしていない ● 仕様が全然間違っていた

Slide 55

Slide 55 text

55 なぜこのようなことが起こるのか 本当に必要な機能はクライアント/ユーザー にも使ってみないとわからない

Slide 56

Slide 56 text

56 解答: フィードバックループを使おう ● 細かい単位でリリースする ● フィードバックを早めに得る ● カイゼンする

Slide 57

Slide 57 text

57 CDなしだとだとループが回らない ● リリースの許可が必要 ● ヒューマンエラー フィードバックループが回 らない

Slide 58

Slide 58 text

58 CDなくしてフィードバックループなし No CD, No Feedback Loop

Slide 59

Slide 59 text

59 最初の疑問 なぜCI/CDへの関心がこれほど高まっているのか？

Slide 60

Slide 60 text

60 Why NOT CD?

Slide 61

Slide 61 text

61 Why NOT CD? ● 技術的な問題 ● 組織的な問題 CDを始める上での2つの問題

Slide 62

Slide 62 text

62 CD導入の技術的な問題 ● エンタープライズなアーキテクチャー ● レガシー (技術的負債が多い)アーキテクチャー そもそもシステムがCDに向いてない

Slide 63

Slide 63 text

63 CD導入の組織的な問題 CDするには不向きな組織 ● 官僚的な組織 ● 失敗に対する許容が低い組織

Slide 64

Slide 64 text

64 解答: 時間をかけてアップデート ● サービスの疎結合 ● 徐々にモダン化 ● チームのDevOps化を進める CD導入の銀の弾丸はない

Slide 65

Slide 65 text

65 新システムにはまずCI/CDを導入しよう 家永 英治さんのブログより

Slide 66

Slide 66 text

66 CircleCIでの事例 Before: ● 常に200台以上のビルドマシンからなるフリート ● Chat Ops (hubot)でデプロイ ● およそ2日で完全に入れ替わる ● しばらく古いコードと新しいコードが混在する問題

Slide 67

Slide 67 text

67 CircleCIでの事例 1年かけて以下を実施した ● DockerとKubernetesの導入 ● マイクロサービス化

Slide 68

Slide 68 text

68 CDのまとめ ● CDが回るとフィードバックループも回る ● CDに向いていない技術・組織はある ● 既存システムに導入が無理なら新システムから

Slide 69

Slide 69 text

69 Beyond CD

Slide 70

Slide 70 text

70 CI/CD完全に理解した

Slide 71

Slide 71 text

71 左CEOのJim, 右CTOのRob

Slide 72

Slide 72 text

72 CDのその先1: 迅速なロールバック $ git revert CD 修正完了

Slide 73

Slide 73 text

73 CDのその先2: 本番環境でのテスト

Slide 74

Slide 74 text

74 テスト環境での失敗例 １週間テスト環境でテスト

Slide 75

Slide 75 text

75 テスト失敗例 １週間テスト環境でテスト ↓ リリース (完璧だ!)

Slide 76

Slide 76 text

76 テスト失敗例 １週間テスト環境でテスト ↓ リリース (完璧だ!) ↓ 本番環境のDockerのバージョンが古くて バグを踏む

Slide 77

Slide 77 text

77 テスト失敗例 Dockerのバージョンも同じにした！

Slide 78

Slide 78 text

78 テスト失敗例 Dockerのバージョンも同じにした！ ↓ リリース (今度こそ完璧だ!)

Slide 79

Slide 79 text

79 例 2 Dockerのバージョンも同じにした！ ↓ リリース (今度こそ完璧だ!) ↓ GitHubのAPI使用制限にひっかかる

Slide 80

Slide 80 text

80 なぜこんなことが起こるか？ テスト可能部分 外部サービス ビジネス要求 仕様 トラフィック・負荷 テスト可能な部分はとても小さい！

Slide 81

Slide 81 text

81 なぜこんなことが起こるか？ テスト可能部分 外部サービス ビジネス要求 仕様 トラフィック・負荷 テスト可能な部分はとても小さい！

Slide 82

Slide 82 text

82 僕たちの重大な学び リリースしてみないと結局わからない！

Slide 83

Slide 83 text

83 CDのその先3: 高度なリリース手法 ● カナリーリリース ● ブルー グリーン デプロイ

Slide 84

Slide 84 text

84 CDをつかいこなすと、、、 ● 迅速なロールバック ● 本番環境でのテスト ● 高度なリリース手法 これらがもたらすものは、、、

Slide 85

Slide 85 text

85 CDをつかいこなすと、、、 ● 迅速なロールバック ● 本番環境でのテスト ● 高度なリリース手法 これらがもたらすものは、、、 プログラミングに対する 圧倒的な心理的安全

Slide 86

Slide 86 text

86 Why CD? CI/CD Makes Programming FUN!!

Slide 87

Slide 87 text

87 CI/CDの未来

Slide 88

Slide 88 text

88 CI/CDはどこへ向かうのか？ CI

Slide 89

Slide 89 text

89 CI/CDはどこへ向かうのか？ CI CDelivery

Slide 90

Slide 90 text

90 CI/CDはどこへ向かうのか？ CI CDelivery CDeployment

Slide 91

Slide 91 text

91 CI/CDはどこへ向かうのか？ CI CDelivery CDeployment ????

Slide 92

Slide 92 text

92 CI/CDはどこへ向かうのか？ CI CDelivery CDeployment ???? 自動化 自動化 自動化 CI/CDの歴史は自動化の歴史

Slide 93

Slide 93 text

93 確実な自動化の未来 今手動でやっていることを意識しなくてもいい時代 ● CIやCDの設定 ● モニタリング ● デプロイ環境の構築

Slide 94

Slide 94 text

94 CI/CDの未来 $ git commit -m “First commit” && git push 最初からクライマックス!!

Slide 95

Slide 95 text

Thank you. 95

Slide 96

Slide 96 text

96 デプロイとリリースの違い デプロイ コードを本番環境に配置すること リリース 配置したコードでトラフィックをさばくこと