なぜ今CI/CDがアジャイル組織に必要とされるのか?

 なぜ今CI/CDがアジャイル組織に必要とされるのか?

Agile Japan 2019の登壇資料

9996db3588c75fb4f2b582fa4021cfdb?s=128

Kim, Hirokuni

July 18, 2019
Tweet

Transcript

  1. 1 なぜ今CI/CDがアジャイル組織に必要 とされるのか? Kim, Hirokuni (CircleCI SRE/Japan Tech Lead) #agilejapan

    #circlecijpanan
  2. 2 CircleCIについて • 世界最大規模のクラウド CI/CD サービス • より良いコードをより速く、簡単にリリースすることを可能に • 2011年設立、サンフランシスコ本社

    • 220人以上の社員、5大陸に在籍(米国と東京にオフィス) • 18年1月 3,100万ドルのシリーズCを実施、合計5,950万ドルを調達 Representative Customers
  3. 3 サークルシーアイ チョットデキル 左: CEO Jim Rose 右: CTO Rob

    Zubber
  4. 4 海外初オフィスとなるCircleCI Japan

  5. 5 自己紹介 Kim, Hirokuni (金 洋国) - CircleCI SRE -

    CircleCI Japan設立 - CircleCI Japan Tech Lead Twitter: https://twitter.com/kimhirokuni
  6. 6 宣伝 (個人) 電動キックボードを公道で体験できるサービス Hop-on! を運営 • みなとみらい・渋谷で体験できます • 続きは

    https://hop-on.jp で!
  7. 7 アジャイルとは? • 0/1な定義ではなく属性の度合い ◦ 自律的 ◦ フラット ◦ 変化に対する柔軟性

    ◦ 失敗から学ぶ姿勢
  8. 8 アジャイルとは? • 0/1な定義ではなく属性の度合い ◦ 自律的 ◦ フラット ◦ 変化に対する柔軟性

    ◦ 失敗から学ぶ姿勢
  9. 9 自分が考えるアジャイルなチームとは? 失敗を推奨しそこから 学ぶ仕組みが存在する

  10. 10 自分が考えるアジャイルなチームとは? 失敗を推奨しそこから 学ぶ仕組みが存在する CI/CDがどのように貢献するか <- 今日のテーマ

  11. 11 CI/CDとは何か?

  12. 12 CI/CD 戦国時代 Google GCP Cloud Build Microsoft Azure Pipelines

    AWS CodeBuild
  13. 13 CI/CDとは何か? 2つの開発手法から構成される • Continuous Integration (継続的インテグレーション) • Continuous Deployment

    (継続的デプロイメント)
  14. 14 CIとはテストを自動で実行する仕組み 開発者のコード変更に対して • 常に • 同じ環境で テストを実行してくれる

  15. 15 CIの流れ 2. VCSからCircleCIへ通知 1. コードをプッシュ 3. CircleCIでテスト実行 4. テスト結果通知

  16. 16 CIの流れ 2. VCSからCircleCIへ通知 1. コードをプッシュ 3. CircleCIでテスト実行 4. テスト結果通知

  17. 17 CIの流れ 2. VCSからCircleCIへ通知 1. コードをプッシュ 3. CircleCIでテスト実行 4. テスト結果通知

  18. 18 CIの流れ 2. VCSからCircleCIへ通知 1. コードをプッシュ 3. CircleCIでテスト実行 4. テスト結果通知

  19. 19 なぜCIが重要か? • テストがあるけど実行し忘れた • 昔書いたテストが壊れていて動かない • テスト結果が環境依存 CIがないと色々問題が CIがないとき

    CIがあるとき
  20. 20 なぜCIが重要か? • テストがあるけど実行し忘れた • 昔書いたテストが壊れていて動かない • テスト結果が環境依存 CIでさくっと解決! •

    常に自動で実行される • テストが壊れた時点で通知がくる • まっさらな環境でテストを実行 CIがないとき CIがあるとき
  21. 21 CIがある開発フロー コードをPush

  22. 22 CIがある開発フロー コードをPush CIでテスト

  23. 23 CIがある開発フロー コードをPush CIでテスト masterへマージ

  24. 24 CIがある開発フロー コードをPush CIでテスト masterへマージ 自動

  25. 25 CIがある開発フロー コードをPush CIで自動テスト masterへマージ 自動 デプロイ 手動

  26. 26 CD (継続的デプロイメント)とは? 開発者のコード変更に対して • CIを実行後 • 自動で デプロイしてくれる

  27. 27 なぜCDが重要か? • 毎回のデプロイ作業が大変 • 間違った環境にデプロイ (ヒューマンエラー) CDがないと色々な問題が

  28. 28 アジャイルとCI/CDの関係

  29. 29 CI/CDまでの歴史 アジャル DevOps CI/CD 時間

  30. 30 アジャイル • 顧客と対話 • コミュニケーションの重要性 • 変化への対応

  31. 31 CI/CDまでの歴史 アジャル DevOps 時間

  32. 32 DevOps • 開発 (Dev)と運用 (Ops)の協調 • 作業の自動化

  33. 33 アジャイルとDevOps アジャイル: 開発チームと顧客との積極的な協力 DevOps: 開発 (Dev) と 運用 (Ops)

    の協調
  34. 34 CI/CDまでの歴史 アジャル DevOps CI/CD 時間

  35. 35 CI/CD • DevOpsのアイデアを実現するためのツール • テスト・デプロイを自動化

  36. 36 抽象度のピラミッド図 アジャイル DevOPs CI/CD 抽象度 高い 低い

  37. 37 CircleCIのチーム紹介

  38. 38 グローバルチーム • アジア • ヨーロッパ • 北アメリカ

  39. 39 ボーイング方式 • ワーキング・トュギャザー • 時差の有効活用 • 継続的なペアリング • 無理のないアラート対応

    • 障害時対応
  40. 40 リモートチーム成功の秘訣 Over Communication • 質問・疑問があればなんでもSlackに • SlackよりZoomを • Slackでメンションをためらわない

  41. 41 開発手法: 独自のKANBAN方式 (1) KANBANとは? • ご存知TOYOTAの工場での生産手法が起源 • 仕事を細分化 •

    プロセスの視覚化 • 開発者は Ready For Devな作業をプルしていく
  42. 42 開発手法: 独自のKANBAN方式 (2) 分散チームに合うようにカスタマイズ • ミーティングの数や種類 • Story Point

    • WIP Limitの有無
  43. 43 チーム構成 Eng. Manager: チーム全体の管理。コードは書かない Tech Lead: 設計や重要な技術的決定に責任を持つ Team Lead:

    Eng. Managerへの一歩手前 Engineering Manager Team Lead Tech Lead Developers 1チーム7人から10人の構成
  44. 44 Competency Matrix

  45. 45 エンジニア組織の原則 • 全てのエンジニアがマネジャーのキャリアパスを目指す わけではない • 若手エンジニアでもリードできる • エンジニアによって成長過程や強みはそれぞれ •

    エンジニアは成長していく • コードを書く力は求められる技術のほんの一部 Competency Matrixはここに公開されています
  46. 46 エンジニアチームの重要原則: アイデアを常にテストする • 早くMVPを作る • ユーザーからのフィードバックを得る • 修正を常に本番環境へ反映させる

  47. 47 CI/CDで失敗から学ぶチームを作る

  48. 48 Thinking Time ⏰ Q: 失敗から学ぶチームはどうすれば作れるか?

  49. 49 Thinking Time ⏰ Q: 失敗から学ぶチームはどうすれば作れるか? A: 失敗のコストを下げる

  50. 50 失敗のコストが下がると少なくなるもの • 責任の追求 • 対応のミーティング • 無駄なチェックリスト • etc.

  51. 51 開発での失敗あるある 1 手戻りの問題 • 2ヶ月仕様定義 • 4ヶ月実装 • リリース後大きな仕様の間違いが発覚

  52. 52 開発での失敗あるある 2 QAの問題 • テスト環境で1週間テスト • 本番と構成が違っていてバグを見逃す

  53. 53 なぜこのような問題が起こるのか? テスト可能部分 外部サービス ビジネス要求 仕様 トラフィック・負荷 テスト可能部分 外部サービス ビジネス要求

    仕様 トラフィック・負荷 テスト可能領域はとても小さい
  54. 54 我々の重大な気づき 結局リリースしてみないとわからない!

  55. 55 シフト・レフト ライト 本番環境でテスト • CDで常に本番環境へデプロイする • 実際にユーザーに使ってもらう • 問題・失敗を見つける

    • 修正 • CDでもう一度デプロイ
  56. 56 シフト・レフト ライト 設計・デザイン 開発 リリース テスト 時間 設計・デザイン 開発

    リリース テスト 設計・デザイン 開発 リリース テスト フィードバック フィードバック
  57. 57 でも本番環境でテストってほんとに大丈夫?

  58. 58 本番環境でテストするための技術 • カナリーリリース • フィーチャーフラグ • ブルー・グリーンデプロイメント

  59. 59 フィードバックループ • 問題の早期発見 • 素早いフィードバック • カイゼン

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

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

  62. 62 結論: CDを活用して失敗から学ぶチームを作ろう • 早く失敗できる • 失敗のコストが下がる • フィードバックループが回る CDをうまく活用すると、、、

  63. 63 前半のスライド 失敗を推奨しそこから 学ぶ仕組みが存在する

  64. 64 前半のスライド 失敗を推奨しそこから ↑ CDで本番環境でテスト 学ぶ仕組みが存在する

  65. 65 前半のスライド 失敗を推奨しそこから ↑ CDで本番環境でテスト 学ぶ仕組みが存在する ↑ フィードバックループ

  66. 66 Japan to APAC! : 多数のポジションを日本で採用中! circleci.com/careers Senior Full Stack

    Software Engineer Senior Site Reliability Engineer Account Executive Customer Success Manager Japan Marketing Manager Solutions Engineer Sales Development Representative Tokyo, Japan グローバルプラットフォームを作るディ ベロッパーの採用 日本とAPACを担当するメンバーの採 用
  67. Thank you. 67 Optional Name