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

Agile Japan 2019の登壇資料

Transcript

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

   View Slide

2. 2
   CircleCIについて
   ● 世界最大規模のクラウド CI/CD サービス
   ● より良いコードをより速く、簡単にリリースすることを可能に
   ● 2011年設立、サンフランシスコ本社
   ● 220人以上の社員、5大陸に在籍（米国と東京にオフィス）
   ● 18年1月 3,100万ドルのシリーズCを実施、合計5,950万ドルを調達
   Representative Customers
   

   View Slide

3. 3
   サークルシーアイ チョットデキル
   左: CEO Jim Rose
   右: CTO Rob Zubber
   

   View Slide

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

   View Slide

5. 5
   自己紹介
   Kim, Hirokuni (金 洋国)
   - CircleCI SRE
   - CircleCI Japan設立
   - CircleCI Japan Tech Lead
   Twitter: https://twitter.com/kimhirokuni
   

   View Slide

6. 6
   宣伝 (個人)
   電動キックボードを公道で体験できるサービス Hop-on! を運営
   ● みなとみらい・渋谷で体験できます
   ● 続きは https://hop-on.jp で！
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

11. 11
    CI/CDとは何か?
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

20. 20
    なぜCIが重要か？
    ● テストがあるけど実行し忘れた
    ● 昔書いたテストが壊れていて動かない
    ● テスト結果が環境依存
    CIでさくっと解決!
    ● 常に自動で実行される
    ● テストが壊れた時点で通知がくる
    ● まっさらな環境でテストを実行
    CIがないとき CIがあるとき
    

    View Slide

21. 21
    CIがある開発フロー
    コードをPush
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

37. 37
    CircleCIのチーム紹介
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

41. 41
    開発手法: 独自のKANBAN方式 (1)
    KANBANとは？
    ● ご存知TOYOTAの工場での生産手法が起源
    ● 仕事を細分化
    ● プロセスの視覚化
    ● 開発者は Ready For Devな作業をプルしていく
    

    View Slide

42. 42
    開発手法: 独自のKANBAN方式 (2)
    分散チームに合うようにカスタマイズ
    ● ミーティングの数や種類
    ● Story Point
    ● WIP Limitの有無
    

    View Slide

43. 43
    チーム構成
    Eng. Manager: チーム全体の管理。コードは書かない
    Tech Lead: 設計や重要な技術的決定に責任を持つ
    Team Lead: Eng. Managerへの一歩手前
    Engineering
    Manager
    Team Lead
    Tech Lead
    Developers
    1チーム7人から10人の構成
    

    View Slide

44. 44
    Competency Matrix
    

    View Slide

45. 45
    エンジニア組織の原則
    ● 全てのエンジニアがマネジャーのキャリアパスを目指す
    わけではない
    ● 若手エンジニアでもリードできる
    ● エンジニアによって成長過程や強みはそれぞれ
    ● エンジニアは成長していく
    ● コードを書く力は求められる技術のほんの一部
    Competency Matrixはここに公開されています
    

    View Slide

46. 46
    エンジニアチームの重要原則: アイデアを常にテストする
    ● 早くMVPを作る
    ● ユーザーからのフィードバックを得る
    ● 修正を常に本番環境へ反映させる
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

53. 53
    なぜこのような問題が起こるのか？
    テスト可能部分
    外部サービス
    ビジネス要求
    仕様
    トラフィック・負荷
    テスト可能部分
    外部サービス
    ビジネス要求
    仕様
    トラフィック・負荷
    テスト可能領域はとても小さい
    

    View Slide

54. 54
    我々の重大な気づき
    結局リリースしてみないとわからない!
    

    View Slide

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

    View Slide

56. 56
    シフト・レフト ライト
    設計・デザイン 開発 リリース
    テスト
    時間
    設計・デザイン 開発 リリース
    テスト
    設計・デザイン 開発 リリース
    テスト
    フィードバック
    フィードバック
    

    View Slide

57. 57
    でも本番環境でテストってほんとに大丈夫？
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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を担当するメンバーの採
    用
    

    View Slide

67. Thank you.
    67
    Optional Name
    

    View Slide