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

by Kim, Hirokuni

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2 戦国時代 Google GCP Cloud Build Microsoft Azure Pipelines AWS CodeBuild

Slide 3

Slide 3 text

3 戦国時代

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 自己紹介 Kim, Hirokuni (金洋国) - 元CircleCI 開発者 - CircleCI Japan Tech Lead ”この発言は個人の見解ではなく所属する組織を代表しています!!”

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 宣伝個人電動キックボードを体験できるサービス Hop-on! を運営 ● 日本で唯一のサービス(のはず) ● みなとみらいで体験できます ● 続きはWebで！

Slide 10

Slide 10 text

10 継続的インテグレーション

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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 解答を唯一のテスト環境にする ● 毎回同じテスト環境が構築される ● まっさらな環境でテストを実行 ● いつ実行しても同じテスト結果になる

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

32 お好みのツールを選ぶ

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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 継続的デプロイメント

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

53 広義の継続的デリバリービジネス価値を継続的にデリバリーしていくこと

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Slide 56

Slide 56 text

56 よくあるリリース後の問題 ● 検証環境で見つからなかったバグ ● 仕様と全然違う動きをする ● そもそも仕様が間違ってた

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Slide 62

Slide 62 text

62 ● 技術的な問題 ● 組織的な問題 CDを始める上での2つの問題

Slide 63

Slide 63 text

63 導入の技術的な問題 ● エンタープライズなアーキテクチャー ● レガシーなアーキテクチャーそもそもアーキテクチャーがCDに向いてない

Slide 64

Slide 64 text

64 解答導入の技術的な問題 ● サービスの疎結合 ● 徐々にモダン化時間をかけてアップデート

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

66 解答導入の組織的な問題誰か教えてください....

Slide 67

Slide 67 text

67 組織の問題に関してはこれ呼んでください！

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

Slide 73

Slide 73 text

73 完全に理解した、でしょうか？

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

75 のその先本番環境でのテスト

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

85 がもたらす心理的安全性 ● 迅速なロールバック ● 本番環境でのテスト ● 高度なリリース手法これらがもたらすものは、、、

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

87 CI/CD Makes Programming FUN!!

Slide 88

Slide 88 text

88 の未来

Slide 89

Slide 89 text

89 はどこへ向かうのか？ CI

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

92 はどこへ向かうのか？ CI CDelivery CDeployment ????

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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