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

デブサミ2019のセッション

Transcript

1. 1 を使い倒して数段上の ソフトウェア開発しよう #devsumi #circlecijp
2. 2 戦国時代 Google GCP Cloud Build Microsoft Azure Pipelines AWS CodeBuild
3. 3 戦国時代
4. 4 最初の疑問 なぜ への関心がこれほど高まっているのか？
5. 5 自己紹介 Kim, Hirokuni (金 洋国) - 元CircleCI 開発者 - CircleCI Japan Tech Lead ”この発言は個人の見解ではなく所属する組 織を代表しています!!”
6. 6 モチベーションについて
7. 7 このセッションの基本の流れ What Why Why Not Beyond
8. 8 宣伝 会社 • 日本語サポート • ドキュメントの日本語化 • ユーザーコミュニティー CircleCI初の海外支社 @CircleCIJapan FB Community Group
9. 9 宣伝 個人 電動キックボードを体験できるサービス Hop-on! を運営 • 日本で唯一のサービス(のはず) • みなとみらいで体験できます • 続きはWebで！
10. 10 継続的インテグレーション
12. 12 その前に確認 もちろんテストは書いてますよね？
13. 13 なぜテストを書くべきか • 何度も同じ手順を繰り返さないといけない • 人の目や手に頼ると必ず見落としが発生する
14. 14 なぜテストを書くべきか • 何度も同じ手順を繰り返さないといけない • 人の目や手に頼ると必ず見落としが発生する それコンピューターにやらせようよ！
15. 15 とはテストを自動で実行する仕組み 開発者のコード変更に対して • 常に • 同じ環境で テストを実行してくれる
17. 17 ただテストを書くだけでは不十分 • テストがあるけど実行し忘れた • 昔書いたテストが壊れていて動かない • テスト結果が環境依存
18. 18 ただテストを書くだけでは不十分 • テストがあるけど実行し忘れた • 昔書いたテストが壊れていて動かない • テスト結果が環境依存 テストの信頼性がない
19. 19 問題 テストの実行忘れ • リリース前にテストをしわすれる • バグを見落とす • 修正でリリースが遅れる
20. 20 解答 常にテストを回す • GitHub (VCS)の変更をCI/CDが検知 • 全変更に対してテスト実行
21. 21 問題 テストが壊れてしまう • 古いテストが壊れている • テストが悪いのかコードがわからない
22. 22 解答 壊れたテストを素早く検知 • テストが壊れた時点で検知 • 直さないとマージできない (後述）
23. 23 使われていない自動化は壊れていく “サイボウズを支える CircleCI”より
24. 24 問題 テスト結果が環境依存 僕のマシンだとテスト通ってます (｀・ω・´) ｷﾘｯ
25. 25 例 テスト環境の差異による問題 CreateNewBook 古いBookレコード CheckNewBookCreated テストPass バグ False Negative テスト対象 テスト ローカルDBに残っているデータのせいで CreateNewBookのバグを検知し損ねる
26. 26 解答 を唯一のテスト環境にする • 毎回同じテスト環境が構築される • まっさらな環境でテストを実行 • いつ実行しても同じテスト結果になる
27. 27 の目的 テストの新陳代謝を高めて信頼性をあげる
29. 29 導入を妨げる問題 • テストがない • メンテナンス
30. 30 問題 テストがない • CIを始めたい • でも実行するテストが存在しない • テスト文化の布教にはコストと時間がかかる CIを導入する上でいちばんやっかいな問題
31. 31 テストがない状態から を始める ステップ Step 1: お好みのCI/CDツールを選ぶ Step 2: タスクの自動化 Step 3: 可視化する Step 4: マージブロック Step 5: テストを追加していく
32. 32 お好みの ツールを選ぶ
33. 33 ステップ 様々なタスクを自動化しよう テスト以外のタスクを自動化 • 構文チェック（linting) • カバレッジ計測 • 循環的複雑度のチェック • ドキュメントの自動生成
34. 34 ステップ 可視化しよう CI結果を可視化しよう • ステータスバッジ • ダッシュボードの作成 • メール・チャットでの通知
35. 35 やってる感が出てくる ”お、俺たちCIしてるっぽいw”
36. 36 マージブロック有効化 マージするための条件をブランチごとに 指定できる機能 • CIが通らないとマージできない • 管理者しかマージできない • Force Push禁止 • Etc, etc CircleCIが通らないとマージできない
37. 37 テストの追加 少しずつテストを追加していく • ユニットテストはとりあえず後回し • 最も大事なビジネスロジック • この時点では無理は禁物....
38. 38 導入を妨げる問題 • テストがない • メンテナンス
39. 39 問題 メンテナンス • CI/CDツールのメンテナンスは大変 • 通常専任のエンジニアが必要 • CircleCIのようなクラウド型がおすすめ
40. 40 クラウド型 オンプレミス型 クラウド型 オンプレミス型 AWS CodeBuild CircleCI GCP Cloud Build Travis CI Jenkins Concourse CI
41. 41 のまとめ • テストの信頼性と品質を向上させる • テストがなくてもCIは始めれる • できる自動化からはじめよう • クラウド型のツールで運用コストを下げる
43. 43 開発フロー コードをPush
44. 44 開発フロー コードをPush CIでテスト
45. 45 開発フロー コードをPush CIでテスト masterへマージ
46. 46 開発フロー コードをPush CIでテスト masterへマージ 自動
47. 47 開発フロー コードをPush CIで自動テスト masterへマージ 自動 リリース 手動
48. 48 継続的デプロイメント
50. 50 とは？ Continuous Deployment (継続的デプロイメント) 自動でステージング・本番環境へデプロイ Continuous Delivery (継続的デリバリー) 常にリリース可能な状態を維持する
51. 51 Continuous Delivery (継続的デリバリー) リリース作業に人間の意思が介在する コードプッシュ JARファイル CI/CD Dockerイメージ ステージング 本番環境 自動 人間が 決定
52. 52 Continuous Deployment (継続的デプロイメント) リリースに人の意思が介在しない コードプッシュ JARファイル CI/CD Dockerイメージ ステージング 本番環境 全自動 CI/CD
53. 53 広義の継続的デリバリー ビジネス価値を継続的に デリバリーしていくこと
54. 54 デプロイとリリースの違い デプロイ コードを本番環境に配置すること リリース 配置したコードでトラフィックをさばくこと
56. 56 よくあるリリース後の問題 • 検証環境で見つからなかったバグ • 仕様と全然違う動きをする • そもそも仕様が間違ってた
57. 57 解答 フィードバックループを使おう • 細かい単位でリリースする • フィードバックを早めに得る • カイゼンする
58. 58 なしだとだとループが回らない • リリースの許可が必要 • ヒューマンエラー フィードバックループが回 らない
59. 59 なくしてフィードバックループなし No CD, No Feedback Loop
60. 60 最初の疑問 なぜ への関心がこれほど高まっているのか？
62. 62 • 技術的な問題 • 組織的な問題 CDを始める上での2つの問題
63. 63 導入の技術的な問題 • エンタープライズなアーキテクチャー • レガシーなアーキテクチャー そもそもアーキテクチャーがCDに向いてない
64. 64 解答 導入の技術的な問題 • サービスの疎結合 • 徐々にモダン化 時間をかけてアップデート
65. 65 導入の組織的な問題 CDするには不向きな組織 • 官僚的な組織 • 失敗に対する許容が低い組織
66. 66 解答 導入の組織的な問題 誰か教えてください....
67. 67 組織の問題に関してはこれ呼んでください！
68. 68 新システムにはまず を導入しよう 家永 英治さんのブログより
69. 69 での事例 Before: • 常に200台以上のビルドマシンからなるフリート • Chat Ops (hubot)でデプロイ • およそ2日で完全に入れ替わる • しばらく古いコードと新しいコードが混在する問題
70. 70 での事例 1年かけて以下を実施した • DockerとKubernetesの導入 • マイクロサービス化
71. 71 のまとめ • CDが回るとフィードバックループも回る • CDに向いていない技術・組織はある • 既存システムに導入が無理なら新システムから
73. 73 完全に理解した、でしょうか？
74. 74 のその先 迅速なロールバック $ git revert CD 修正完了
75. 75 のその先 本番環境でのテスト
76. 76 テスト環境での失敗例 １週間テスト環境でテスト
77. 77 テスト失敗例 １週間テスト環境でテスト ↓ リリース (完璧だ!)
78. 78 テスト失敗例 １週間テスト環境でテスト ↓ リリース (完璧だ!) ↓ 本番環境のDockerのバージョンが古くて バグを踏む
79. 79 テスト失敗例 Dockerのバージョンも同じにした！
80. 80 テスト失敗例 Dockerのバージョンも同じにした！ ↓ リリース (今度こそ完璧だ!)
81. 81 例 Dockerのバージョンも同じにした！ ↓ リリース (今度こそ完璧だ!) ↓ GitHubのAPI RateLimitにひっかかる
82. 82 なぜこんなことが起こるか？ CI/CDでテスト可能部分 外部サービス ビジネス要求 仕様 トラフィック・負荷 テスト可能な部分はとても小さい！
83. 83 僕たちの重大な学び リリースしてみないと結局わからない！
84. 84 のその先 高度なリリース手法 • カナリーリリース • ブルー グリーン デプロイ
85. 85 がもたらす心理的安全性 • 迅速なロールバック • 本番環境でのテスト • 高度なリリース手法 これらがもたらすものは、、、
86. 86 がもたらす心理的安全性 • 迅速なロールバック • 本番環境でのテスト • 高度なリリース手法 これらがもたらすものは、、、 プログラミングに対する 圧倒的な心理的安全
87. 87 CI/CD Makes Programming FUN!!
88. 88 の未来
89. 89 はどこへ向かうのか？ CI
90. 90 はどこへ向かうのか？ CI CDelivery
91. 91 はどこへ向かうのか？ CI CDelivery CDeployment
92. 92 はどこへ向かうのか？ CI CDelivery CDeployment ????
93. 93 はどこへ向かうのか？ CI CDelivery CDeployment ???? 自動化 自動化 自動化 CI/CDの歴史は自動化の歴史
94. 94 確実な自動化の未来 今手動でやっていることを意識しなくてもいい時代 • CIやCDの設定 • モニタリング • デプロイ環境の構築
95. 95 の未来 $ git commit -m “First commit” && git push 最初からクライマックス!!
96. 96 ユーザーコミュニティーのご紹介 FB Community Group
97. Thank you. 97