勇気が出る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. 質問２
8. この２枚の「一日乗車券」、何が違う？ その日の終電まで有効 (紙の切符にスタンプや 手書きで情報登録) 使い始めから24時間有効 (裏面の磁性体に デジタル情報を登録) 人手ゆえの制約
9. 9 現場の立場では • キセル発見などのノウハウを 長年かけて継承し、一人前に なるような修行は不要 →他にやることはある、生まれる デジタル情報＋ 自動化＋α... マネージメントする立場では • 人手で切符を集めて乗降駅や 枚数をカウントするといった 分析の前段となる待ち時間は不要 →リアルタイムに現況把握可能
11. 人手でやってません？ ビルド、テスト、リリース、デプロイ
13. 13 継続するビジネスと開発・運用の継続をつなげる プラン コード ビルド テスト リリース デプ ロイ 運用 監視 継続的インテグレーション (CI) 継続的 デプロイ (CD) 自動化できない 非正常系は 自動化できない 自動化できる→継続的であるために自動化すべき ビジネスが継続する限り、プロジェクトは続く 共有 リポジトリ上 で 常に作業 コード追加・修正時は 常にビルド・テスト (最後にまとめてやらな い→早く失敗すれば 早く品質が安定する) サービス停止せず常時 リリース/デプロイ (失敗時にはクイックに 修正 ／ 前バージョンに 戻せる)しくみ 運用・監視しやすい 品質をコードに反映 (必要なデータの取得、 スケーラビリティの 確保) 継続的ではない： 「それ、手元の 　コードでは 　もう直したんです 　けど」 継続的： • お願いドリブンでな いこと • 遠慮なしに依頼可 能な状態 • 依頼しなくても 左から右に (自動的に)流れる 状態 ここで勇気が 必要だと 継続性にディレイが 生じる
14. CI/CDの重要さは 既に理解している そ　ん　な　こ　と eXtreme Programmingの５つの価値 1. コミュニケーション 2. シンプル 3. フィードバック 4. 上の３つを実現するための 勇気 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%以上 自動化における４つの評価ポイント ここの数値に「近い目標」として まずは追いつき ここの数値を「あるべき姿」として 目指す 現時点での数値を「課題」として 把握した上で
24. 24 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 スループット ワークフローの実行数 0.7回/日 プルリクエストのマージごと いつでも(遠慮せずに)ビルド可能 評価ポイント１: スループット パーセンタイル 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分 自動化可能なことは全て任せる 評価ポイント２: 実行時間 パーセンタイル 5 50 90 95 実行時間 平均値: 24.6分 12秒 3.96分 21.35分 34.01分 エンジニア１人のチームで実行時間が最長
26. 26 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 復旧時間 ワークフローの失敗～成功の時間 56分以内 60分以内 大きな失敗を最後にではなく、すぐ に復旧できる失敗を早期に 評価ポイント３: 復旧時間 パーセンタイル 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%以上 評価ポイント４: 成功率 パーセンタイル 5 50 75 90 95 成功率 平均値: 54% 0% 61% 89% 100% 100% 企業規模(エンジニアの数)と成功率の間に相関はない デフォルトブランチの成功率 ＞ 非デフォルトブランチの成功率
28. 28 CircleCI – Insights (インサイト ダッシュボード) 自分が関わる 個々のプロジェクトや 組織で進行中の プロジェクトの CI/CD状況を理解し、 最適化するための情報
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