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

CircleCI で始める DevOps ~ CircleCI を使った DevOps の始め方

CircleCI で始める DevOps ~ CircleCI を使った DevOps の始め方

2022/08/31に開催された「CircleCIを使ったDevOpsの始め方 - かんたんDevOps x CircleCI ジョイントセミナー」での使用スライドです。

https://vtj-circleci-202208.peatix.com

More Decks by Masahiko Funaki(舟木 将彦)

Other Decks in Programming

Transcript

  1. CircleCIってどんな会社 • 世界最大規模のクラウドCI/CD(継続的インテグレーション/継続的デプロイ)サービス ◦ 22,000以上の組織の 100万以上の開発者が実行する 毎月7億以上のジョブを支えるサービス • ミッション: Manage

    change So software teams can innovate faster (変化をマネージしよう、そうすれば ソフトウェアチームはより速くイノベーションできる ) • 2011年設立、サンフランシスコに本社 2021/05/11 にSeries Fで1億ドルを調達 (これまでに$315Mの投資、$1.7Bの企業価値) • 600+人の社員 (米国、日本、英国、オランダ、フランス+  リモートワーク)
  2. 3 ワークフロー実行回数順位 (CircleCIクラウド版) グローバル 1 米国 2 英国 3 日本

    4 ドイツ 5 カナダ 6 オーストラリア 7 フランス 8 スウェーデン 9 ブラジル 10 イスラエル アジア・太平洋地域 1 日本 2 オーストラリア 3 シンガポール 4 香港 5 ニュージーランド 6 インド 7 韓国 8 マレーシア 9 タイ 10 インドネシア 2010/10~2011/09までの12か月にCircleCIクラウド版で実行されたワークフローより。 ただしサンプルやチュートリアルの実行等は除外している(カウントしていない)。
  3. 6 ソフトウェアはモノからサービスに ビジネスの成長速度を支えるため、ソフトウェアも成長しつづける必要がある → かつて ソフトウェアはモノだったが、これからのソフトウェアはサービス • モノの品質(企業であれば5年償却) 買った時点が一番価値が高く、競合の出現や市場の進化により価値が低下 →

    数年に一度のモデルチェンジやバージョンアップ 開発手法:ウォーターフォール (作業の積み上げ or リリース日からの逆算) • サービスの品質 常に最高のサービスを使い続ける(その時点その時点で最高が異なる ) → 魅力的品質を高めつづける (使っている人、使い方を常に想定、進化 ) 開発手法:アジャイル (要件→設計→実装→テストを小さく回す)      ウォーターフォールが進化してもアジャイルにはならない
  4. 7 サービスとしてのソフトウェア開発のプロセス ソフトウェアの 機能拡張 新技術を 取り込みつつ (Opsしやすい) 安定的な ソフトウェア 利用者の増加

    安定的かつ (Devしやすい) 拡張性を備えた 責任範囲をオーバーラップさせる (サイロにしない) 忙しくなりすぎる、普通に考えたら無理 → できない理由ではなく、できるためにするには?
  5. 8 継続するビジネスを支えるソフトウェア開発を標準化 プラン コード ビルド テスト リリース デプ ロイ 運用

    監視 継続的インテグレーション (CI) 継続的 デプロイ (CD) 自動化できない 非正常系は 自動化できない 自動化できる→継続的であるために自動化すべき ビジネスが継続する限り、ソフトウェアの進化は続く コード追加・修正時は 常にビルド・テスト (最後にまとめてやらな い→早く失敗すれば 早く品質が安定する) サービス停止せず常に リリース/デプロイ (失敗時にはクイックに 修正 / 前バージョンに 戻せる)しくみ 人にしかできない ことは、 細分化した上で できる人が 手を挙げてやる →誰でも見える、  参加できる状態 共有 リポジトリ上 で 常に作業 自動化できる ことは 作業手順の 定義を行い 自動実行させる →依頼しない、 抜け漏れしない 運用・監視しやすい 品質をコードに反映 (必要なデータの取得、 スケーラビリティの 確保)
  6. 10 ソフトウェア開発の現況 〜 今の立ち位置を知る ソースコードを GitHubなどの ソースコード 管理システムで管理 日時や週次で テストやビルドを

    自動実行する コードが追加・修正 されるたび、 テストやビルドを 自動実行する ソースコードを 共有フォルダ等で 取りまとめる 動作する直近のバージョンが 失われる可能性がある Linux/Windows/iOS /Android/GPU環境 向けビルドを(クラウド で)一元管理 テスト時間を短縮す ることで、作った記憶 がホットなうちに修正 可能に 必要に応じた スペックのビルド環境を選 択可能(縦に伸ばす) 直列実行だけでなく、 並列実行が簡単に 設定可能(横に広げる) コード 共有 + 手作業の 自動化 コード 履歴共有 + 手作業の 自動化 (巻戻可) スペックや 多重度が 変化する 自動化 (高速化= 速く気づき 速く直す)
  7. 11 ソフトウェアデリバリーに関わる4つの主要な指標 4つの指標 グローバルの CircleCIユーザー平均値 CircleCIが考える 目標値* スループット (ワークフロー実行回数) 1.43回/日

    プルリクエストの数+ 自動実行数 実行時間 (ワークフロー実行時間) 3.7分 10分 (🙅10分以内) 平均リカバリ所要時間 73.6分 1時間以内 ワークフロー成功率 デフォルトブランチで 77% デフォルトブランチで 90%以上 手動・自動を問わず 現時点の値を踏まえた上で 世の中の平均にまずは 近い目標として到達し、 あるべき姿(目標値)を 実現を目指す取り組みを推進
  8. 14 縦に伸ばす(自動化実行環境のスペックを上げる) リソースクラスと消費クレジット Docker Executor クラス vCPUs RAM クレジット small

    1 2GB 5クレジット/分 medium 2 4GB 10クレジット/分 medium+ 3 6GB 15クレジット/分 large 4 8GB 20クレジット/分 Freeプランでは30,000クレジット/月が無料で付与 (smallクラスなら6000分=100時間に相当) ※月20日換算で一日あたりのジョブ実行時間 5.0時間
  9. 16 横に伸ばす(並列化) 1並列で処理した場合 (parallelism: 1) 4並列で処理した場合 (parallelism: 4) テストファイルは名前で分割 (--split-by指定なし)

    4並列で処理した場合 (parallelism: 4) テストを過去の動作時間 (--split-by=timings )で分割 ※ 他にファイルサイズ(--split-by=filesize )で分割もあり
  10. 17 デモ (単体テストの並列実行ー自動振り分け) 1 5 50 5 45 40 100

    60 1 0 30 20 100 1 5 50 60 20 1 0 45 40 30 5 100 50 1 0 45 1 5 60 20 5 40 30 1並列 3並列 5並列 1’44” 1’14” 1’09” 1’14” 1’15” 6:20 132クレジット (¢7.92相当) 2’09” 2’09” 2’09” 147クレジット (¢8.82相当) 161クレジット(¢ 9.66相当)
  11. 19

  12. 21 • 従来よりも頻繁なリリース(デプロイ)がビジネスサイドから求められている一方、 開発にかけられる時間や人員は、頻繁さに合わせて増強されているわけではない • 「数年に一度のリリースに向けモノを作る」 (時間と共に陳腐化)のではなく、 「頻繁にサービスを充実させていく」 (長く付き合うほど必要不可欠になる )には、

    ビルド・テスト・リリース・デプロイにおける自動化の適用が必要不可欠 • 自動化の適用で生み出した時間を、人による「開発」「運用」の強化に使う • 自動化の適用で「開発現況」を数値データとして初めて見える化できる →「開発の仕組みや考え方、組織のあり方」を変え、効果を測定する上での  メトリクス (ソースコードの行数やテストの数、印象ベースでの達成%に頼ることなく、  新機能やバグ修正がお客様にとって利用可能になるまでの時間を見積可能に) まとめ
  13. 24