はじめてのCircleCI

Transcript

1. 1 はじめての CircleCI CircleCI – Principal Developer Advocate 舟木 将彦
2. 2 はじめに - 質問がある場合は、いつでも Q&A でお聞きください。 時間の都合上、すべての質問にお答えできない場合が ありますが、できるだけ対応いたします。 - チャットは参加者全員が見ることができますので、 個人情報、秘密情報は絶対に記載しないでください。 - 終了後アンケートへのご回答をお願いいたします。 アンケートは5分程度で完了します。ご意見やご感想を お聞かせください。
3. 3 今日のゴール - ソフトウェア開発に CI/CD が必要な理由を理解する - CircleCI の特徴やメリットを知る - CircleCI を導入する場合の、CI/CD パイプラインの 設計方法や考え方を知る
4. 4 ソフトウェア開発に CI/CD が必要な理由
5. 5 ソフトウェアのリリースを短期間に繰り返す理由 • 顧客のニーズを正確に把握することは重要だが、実際には難しい。 「もし私が顧客に何が欲しいかを聞いていたら、彼らは『もっと早い馬が欲しい』と 答えただろう」 • 追加、変更されたコードが常にテストされた状態で、より短いサイクルで 安定したリリースやデプロイをすることができたら、 開発者は実装や修正を早く実行可能なシステムに反映することができ、 その結果、顧客は自分が欲しいものを見つけやすくなる 例) ◦ Spotify は２週間ごとに新しい機能をリリース ◦ Amazon は１日あたり約136,000回のデプロイ
6. 6 CI/CD が指す範囲 • ソフトウェアライフサイクルにおける各フェーズを 「どうしても人が携わらなければならない部分(自動化できない)」 「作業手順に落とし込める部分(自動化できる)」観点で分類 • コードの追加・修正(リポジトリへのマージ)を起点に、ビルド～デプロイフェーズを あらかじめ用意しておいた手順にしたがって実行する →コードは常にテストされ、リリース可能な状態である
7. 7 継続的 (Continuous) とは • 「コードは常にテストされ、リリース可能な状態である」ためには、 ◦ ビルド、テスト、リリース、デプロイの担当者がいる／いない、同じことをたのんで 申し訳ないといった要因ですぐにできない、抜け漏れが出ることがないように、 ◦ ビルド、テスト、リリース、デプロイに関しては、コードの追加・修正を起点に 自動実行する(コードを起点に、ビルド以降のフェーズを順次つなげて実行) • 継続的であることにより、 ◦ 問題に早く気が付くことができる、その結果、問題を早く修正することができる ◦ 開発の現況を示すメトリックスを常時、自動的に計測、記録することができる
8. 8 CircleCI の特徴やメリット
9. 9 1. 今すぐに始められる • 自動実行のための環境を用意したり、 ソフトウェアをインストールしなくても、 サインアップすればすぐに使える (Free プランで毎月6,000分まで自動実行可能) • コードを格納するリポジトリとして、 GitHub / GitLab / Bitbucket と連携可能 • ビルドやテストを実行する環境として、 Linux コンテナやVM、Windows VM、 macOS 環境、GPU環境 を幅広いスペックで クラウド上に用意 https://qiita.com/mfunaki/items/14080547b352be9d265c
10. 10 2. 充実したドキュメントとサポート • 日本語のドキュメントや チュートリアル、ビデオなどを 提供 • 日本語での、日本の時間帯に 合わせた技術サポートを提供 (翻訳や取り次ぎではなく、 サポートエンジニアが在籍) • ドキュメントや過去のサポート 事例をもとに Ask AI で AI が 24時間日本語で対応可能 https://circleci.com/docs/ja/
11. 11 2. 充実したドキュメントとサポート • 日本語のドキュメントや チュートリアル、ビデオなどを 提供 • 日本語での、日本の時間帯に 合わせた技術サポートを提供 (翻訳や取り次ぎではなく、 サポートエンジニアが在籍) • ドキュメントや過去のサポート 事例をもとに Ask AI で AI が 24時間日本語で対応可能
12. 12 3. 自動化＋効率化、高速化や品質向上をサポート • 効率化サポート ◦ CircleCI Orb を使った自動化定義の部品化・再利用促進 (よく似た一連の処理を切り出し、変化する部分だけをパラメータで渡す) • 高速化サポート ◦ 低スペック～高スペックまでさまざまな実行環境を用意 ◦ 過去100回のテストログをもとに実行時間を平準化した並列実行をサポート • 品質向上サポート ◦ テスト結果分析ダッシュボード「テストインサイト」でテスト実行結果を見える化 • 全社向けルール、監査サポート ◦ 設定ファイルのポリシーを組織に対して適用可能(禁止事項の定義) ◦ 監査ログの提供や CircleCI が使用する IP アドレスを特定の範囲に限定可能
13. 13 CI/CD パイプラインの 設計・考え方
14. 14 CircleCI を使ったソフトウェア開発サイクル
15. 15 設定ファイル (config.yml) の基本的な構造 個々のジョブ 定義 Dockerイメージを指定 コードの取得やテスト内容を ステップとして記述 ジョブを組み合わせた ワークフロー定義 ・連続実行 ・ファンアウト・ファンイン ・スケジューリング ・ブランチ別 ・タグ別 ...等
16. 16 テストを並行実行して完了時間を短縮 並列実行時の割り振り方 •ファイル名のアルファベット順 •過去のテスト実行時の所要時間 ベースで均等割(timings) •ファイルサイズで均等割 (filesize) •マニュアル指定
18. 18 テストを並行実行して完了時間を短縮 時間は1/3、 費用はほとんど変わらない 100秒かかるテストケースを 見直さないと、 並列数を増やしても、 これ以上の短縮は見込めない。
19. 19 リソースクラスやサイズを上げて時間を短縮 • Docker, Linux VM(Intel, Arm), Windows VM, macOS VM などの プラットフォームに対応 • CPU・RAMをカスタマイズする ことによるパフォーマンス向上 ◦ https://circleci.com/docs/ja/2.0 /configuration- reference/#resource_class • Docker リソースに関しては、 CPU・RAM 使用率を WebUI で 確認することが可能
20. 20 再利用可能な自動化定義で簡潔に記述、高速に実行 パラメータを切り出して共通化 python/install-packagesで 依存ライブラリをインストール • パッケージマネージャに pip 指定 • 依存ライブラリは requirements.txt に指定 • 依存ライブラリはキャッシュしてお き、次回ビルド時の時間を短縮
21. 21 部品化された自動化定義 (Orb) を使い記述を簡潔に、実行を高速に
22. 22 CircleCI Orb レジストリ • 公開された Orb の一覧 https://circleci.com/developer/orbs • 命名規約 組織名/Orb名@バージョン番号 • 自組織にのみ公開することも可能 (プライベート Orb)
23. 23 サンプル: CircleCI-Public https://github.com/CircleCI-Public/
24. 24 カスタムリソース 最適なパフォーマンスを発揮し、 スピードを向上するリソースを 選択できます。 (Docker, Linux, macOS, Windows など) Docker レイヤーの キャッシュ 高度なレイヤーキャッシュで 実行時間を短縮します。 カスタムキャッシュ 制御可能なキーを使用して、実行され るすべてのファイルをキャッシュし、 ビルドを高速化します。 並列ジョブ 柔軟で自動化されたプロビジョニング により、チームは並列実行を最大限に 活用し、ワークフローが完了するまで 待機するダウンタイムを 短縮できます。 テスト分割 複数のコンテナでテストを自動的に 分割し、RSpec、Cucumber、 minitest、Django、Node などの多く のテストを実行できます 最速でデプロイできるプラットフォーム性能
25. 25 コードとしてのコンフィグ パイプラインを他のソースコードと 同じように管理。パイプラインで何が起こって いるのかを簡単に理解することができます。 SSH デバッグ ビルドコンテナに SSH 接続して、 ログファイル、実行中のプロセス、 ディレクトリパスを表示します。 クリーンな環境 自動的にジャストインタイムで プロビジョニングされる クリーンなイメージで、実行を開始できます。 Orbs CircleCIの設定ファイルの一部を パッケージング、共有、再利用することが可能 開発生産性を向上させる強力な機能
26. 26 CircleCI × AWS
27. 27 CircleCI × GCP
28. 28 CircleCI × Azure
29. 29 SSH を使用したデバッグ 一番良いトラブルシューティングの方法は、ジョブの 実行中にジョブ環境にセキュアにアクセスして問題を デバッグすることです。 ビルド環境に SSH で接続できない場合、開発者が取れる 道はひとつです。開発環境に CI/CD 環境を再現して、 アプリケーション、スタック トレース、およびシステム ログだけを頼りに問題を正確に特定し、解決しなければ なりません。 このようなトラブルシューティングでは、開発者も SRE チームも膨大な時間を浪費することになります。
30. SSH Port Forwarding: 自PCで操作、CircleCI環境で実行 https://youtu.be/WEa22I-alU4
31. 31 CircleCI ランナー
32. 32 CircleCI ランナー
33. https://circleci.com/ja/blog/deep-learning-nvidia-gpu-executor/ https://circleci.com/ja/blog/physical-computing-with-circleci-3/
34. 34 開発スピードの課題・改善点を見つける (インサイト)
35. 35 おわりに
36. 36 今日のゴール (振り返り) - ソフトウェア開発に CI/CD が必要な理由が理解できた - CircleCI の特徴やメリットが分かった - CircleCI を導入する場合の、CI/CD パイプラインの 設計方法や考え方を知ることができた
37. 37 次のゴール - CircleCI をトライアルで使ってみる - CircleCI を使って、まずはテストの一部を自動化してみる - CircleCIを使ってテストを高速化してみる ・・・ - CI/CDを通してチームの生産性、プロダクトの品質を 上げ、コストを削減する
38. 38 CircleCI を無料ではじめる https://circleci.com/ja/signup
39. 39 アンケートへのご回答をよろしくお願いします Q&A