Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Agile Japan 2019の登壇資料

Kim, Hirokuni

July 18, 2019
Tweet

More Decks by Kim, Hirokuni

Other Decks in Technology

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の問題
    ● テスト環境で1週間テスト
    ● 本番と構成が違っていてバグを見逃す

    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