Save 37% off PRO during our Black Friday Sale! »

勇気が出るCI/CD! 開発者は何を見る、何を知る、そして何をする?

勇気が出るCI/CD! 開発者は何を見る、何を知る、そして何をする?

2021/02/18 Developers Summit 18-B-5 でお話しさせていただいたスライドです。「継続的」「勇気」という観点からCI(継続的インテグレーション), CD(継続的デプロイメント)についてお話しさせていただきました。

akiko.pusuさんにまとめていただきました。ありがとうございました! https://note.com/akiko_pusu/n/n749f1e5d664b

Transcript

  1. 1 勇気が出るCI/CD! 開発者は何を見る、何を知る、 そして何をする? CircleCI Developer Advocate 舟木将彦 (@mfunaki) #devsumi

    18-B-5
  2. 自己紹介 (@mfunaki) HIC Researcher Dejima Developer Sybase Eng Mgr SAP

    Design Thinker 転 Microsoft Digital Adviser 買 転 買 CircleCI Developer Advocate 転
  3. 3 本日のアジェンダ こんな流れ 1. 生産性を高めるために 手に入れたもの 2. 自動化によって不要に なったもの 3.

    自動化の領域、人の領域 4. 大事なことを先送りしない 5. みんなどうしているのか 6. 根性で勇気を振り絞らない (←マッチョな話はしません)
  4. 最初に質問です

  5. ソフトウェアエンジニアの生産性を高めるのは何? 速いCPU、リッチなメモリ、広い画面? 肩こりや腰痛と無縁になれる椅子?

  6. どれも正しいと思います。 手に入れているのは「もの」のように見えて、 実は「ストレスを感じない開発環境」。

  7. 質問2

  8. この2枚の「一日乗車券」、何が違う? その日の終電まで有効 (紙の切符にスタンプや 手書きで情報登録) 使い始めから24時間有効 (裏面の磁性体に デジタル情報を登録) 人手ゆえの制約

  9. 9 現場の立場では • キセル発見などのノウハウを 長年かけて継承し、一人前に なるような修行は不要 →他にやることはある、生まれる デジタル情報+ 自動化+α... マネージメントする立場では

    • 人手で切符を集めて乗降駅や 枚数をカウントするといった 分析の前段となる待ち時間は不要 →リアルタイムに現況把握可能
  10. None
  11. 人手でやってません? ビルド、テスト、リリース、デプロイ

  12. None
  13. 13 継続するビジネスと開発・運用の継続をつなげる プラン コード ビルド テスト リリース デプ ロイ 運用

    監視 継続的インテグレーション (CI) 継続的 デプロイ (CD) 自動化できない 非正常系は 自動化できない 自動化できる→継続的であるために自動化すべき ビジネスが継続する限り、プロジェクトは続く 共有 リポジトリ上 で 常に作業 コード追加・修正時は 常にビルド・テスト (最後にまとめてやらな い→早く失敗すれば 早く品質が安定する) サービス停止せず常時 リリース/デプロイ (失敗時にはクイックに 修正 / 前バージョンに 戻せる)しくみ 運用・監視しやすい 品質をコードに反映 (必要なデータの取得、 スケーラビリティの 確保) 継続的ではない: 「それ、手元の  コードでは  もう直したんです  けど」 継続的: • お願いドリブンでな いこと • 遠慮なしに依頼可 能な状態 • 依頼しなくても 左から右に (自動的に)流れる 状態 ここで勇気が 必要だと 継続性にディレイが 生じる
  14. CI/CDの重要さは 既に理解している そ ん な こ と eXtreme Programmingの5つの価値 1. コミュニケーション 2. シンプル 3.

    フィードバック 4. 上の3つを実現するための 勇気 5. 尊重 スクラムの5つの価値基準 1. 確約 2. 集中 3. 公開 4. 尊敬 5. 正しいことをする勇気 困難な問題に取り組む 勇気
  15. CI/CDの重要さは 既に理解している 共感・理解をヨコにいる技術を持つ人に広げよう タテにいる責任を持つ人にも広げよう 頭で理解してもらうだけでなく 腹に落としてもらって 行動してもらわないと 変化は実現しない

  16. 16 早く何度も(同じじゃない)失敗できる 機会/環境/仕組み/文化…さえあれば もっと早く品質を高められ 成功できる! なんでCI/CDを導入したいの?

  17. 17 VCSとCI/CDの導入は「最初のフェーズ」からやる マシュマロ・チャレンジ 18分間で 乾燥パスタ20本+タコ糸90cm+ テープ90cm+はさみ でタワーを作り、一番高いチームが 勝ち。 ただし、タワーの頂上には マシュマロを刺しておくこと。

    出典: https://youtu.be/H0_yKBitO8M
  18. 18 大人と幼稚園児の アプローチの違い 大人 18分間のほとんどを • 計画(Plan) • 構築(Build) で使い、最後の最後になって頂上にマシュマロを突き刺す

    →あえなく倒れてしまい、  (どんなに一生懸命頑張っていたとしても )結果は0cm。 幼稚園児 18分間を通じて、 • 低いタワーを作る • マシュマロを刺す: MVP - Minimum Viable Product • タワーの高さを少し高くする を繰り返す。 タワーが倒れてしまったら、直前まで立っていたタワーの高さに戻す。 →DevOpsな皆様なら、聞いたことある話
  19. テスト・ビルド・ リリース・デプロイ 後でもできる、簡単だと思って、 最後まで手をつけない 500円玉と同じ程度には 重いって分かってたら もっと早く 取り掛かっていたのでは? 大して中身も なくて

    スカスカに 見える 私ですが
  20. 「それはおかしい」 「もっとこうしよう」 必要なのはファーストペンギン的な勇気ではなく、 とりあえず触ってみましょう的な無鉄砲さではなく、

  21. CircleCIの考える 進化する勇気を支える数字 縦の人・横の人と共感できる 「課題」「あるべき像」「ロードマップ」の共有

  22. 22 実データから見る自動化(CI/CD) 調査期間  2020/08/01~30  (2019年版は90日間) 調査対象  44,000組織  160,000プロジェクト  200万ジョブ/日 https://circleci.com/ja/resources/2020-state-of-software-delivery/

  23. 23 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 スループット ワークフローの実行数 0.7回/日 プルリクエストのマージごと いつでも(遠慮せずに)ビルド可能 実行時間

    ワークフローの実行時間 4分以内 5~10分 自動化可能なことは全て任せる 復旧時間 ワークフローの失敗~成功の時間 56分以内 60分以内 大きな失敗を最後にではなく、すぐ に復旧できる失敗を早期に 成功率 ワークフローの成功数/実行数 デフォルトブランチで 80% デフォルトブランチで 90%以上 自動化における4つの評価ポイント ここの数値に「近い目標」として まずは追いつき ここの数値を「あるべき姿」として 目指す 現時点での数値を「課題」として 把握した上で
  24. 24 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 スループット ワークフローの実行数 0.7回/日 プルリクエストのマージごと いつでも(遠慮せずに)ビルド可能 評価ポイント1:

    スループット パーセンタイル 5 50 90 95 実行数(回/日) 平均値: 8.22 0.03 0.70 16.03 32.125 金曜日(UTC)のスループットは11%減少 土日(UTC)のスループットは70%減少 月曜日(UTC)のスループットは9%減少
  25. 25 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 実行時間 ワークフローの平均実行時間 4分以内 5~10分 自動化可能なことは全て任せる 評価ポイント2:

    実行時間 パーセンタイル 5 50 90 95 実行時間 平均値: 24.6分 12秒 3.96分 21.35分 34.01分 エンジニア1人のチームで実行時間が最長
  26. 26 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 復旧時間 ワークフローの失敗~成功の時間 56分以内 60分以内 大きな失敗を最後にではなく、すぐ に復旧できる失敗を早期に

    評価ポイント3: 復旧時間 パーセンタイル 5 50 75 90 95 復旧時間 平均値: 14.85時間 2.06分 55.11分 9.5時間 39時間 3.4日 75と90の間に夜(非労働時間)のギャップがある エンジニア数が増えるに従い(200人までは)減少 →チームの多様性重要(いつ、どれだけ働けるか+燃え尽きない)
  27. 27 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 成功率 ワークフローの成功数/実行数 デフォルトブランチで 80% デフォルトブランチで 90%以上

    評価ポイント4: 成功率 パーセンタイル 5 50 75 90 95 成功率 平均値: 54% 0% 61% 89% 100% 100% 企業規模(エンジニアの数)と成功率の間に相関はない デフォルトブランチの成功率 > 非デフォルトブランチの成功率
  28. 28 CircleCI – Insights (インサイト ダッシュボード) 自分が関わる 個々のプロジェクトや 組織で進行中の プロジェクトの

    CI/CD状況を理解し、 最適化するための情報
  29. 29

  30. 30 評価ポイント1: スループット 評価ポイント3: 復旧時間 評価ポイント2: 実行時間 評価ポイント4: 成功率

  31. 31 評価ポイント2: 実行時間 評価ポイント4: 成功率

  32. 32 使用クレジット • ハイスペック(クレジット高) で単独実行するのか、 • ロースペック(クレジット安) で同時実行するのか、 ジョブの性質(コンパイル、 テスト等)に合わせ、

    より時短・生産性効果が 出るように使い分ける!
  33. 33 先出し: State of DevOpsレポート 2020 近日公開 入手方法はTwitterで @CircleCIJapan をフォロー!

  34. なぜCircleCIのCI/CDだと 勇気が出るのか を知りたい 一人じゃないから

  35. 使いたいツールを組み込めるパーツ(Orbs)が充実 https://circleci.com/ja/orbs/ 今使っている、これから導入したいツール群 • 静的コード解析 • 単体テスト • テストカバレッジ •

    E2Eテスト • 各種クラウドプラットフォームへのデプロイ • 結果通知 などなど(自作も可能)
  36. 日本語のウェブサイト・技術情報・情報発信

  37. CircleCI Advent Calendar 2020 https://qiita.com/advent-calendar/2020/circleci

  38. 教育やPoCレベル以上のリアルユースケース https://discuss.circleci.com/t/advent-calendar-2020-circleci/38539

  39. 雑誌・書籍・技術系同人誌が充実 https://discuss.circleci.com/t/circleci-2020-12-22/37369 https://discuss.circleci.com/t/circleci-booth-2020-12-26/37388

  40. ソフトウェアの開発 開発しているものは何か?

  41. 41 継続でき、変化でき、支持を得続けられる「資産」 過去 現在 未来 機能A 機能B 機能C 機能A 機能B

    機能C 機能A 機能C 機能D 資産ポートフォリオを構成する機能や重み付け、 各機能を内製するのか、パッケージを使うのか、 OSSを使うのか、外注するのか …は さまざまな制約(開発者の数、スキル、予算、タイミング、時間、技術の成熟度 …)から、 「みんなの脳」で考え、勇気を持って議論し、「みんなの指」で生み出そう!
  42. CircleCIをもっと知りたい!なら 最新の情報なら @CircleCIJapan をフォロー! #CircleCIJp タグつけて情報共有! イベント、セミナー、勉強会の情報なら connpassのCircleCIグループから! https://circleci.connpass.com/ 動画でCircleCIについて学ぶなら

    CircleCIチャンネルを登録! (日本語プレイリストもあり )
  43. Thank you. 43