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

CircleCI Webinar

CircleCI Webinar

Noboru Kurumai

November 14, 2019
Tweet

More Decks by Noboru Kurumai

Other Decks in Programming

Transcript

  1. 1
    はじめてのCircleCI
    Webinar
    Noboru Kurumai @ Solutions Engineer

    View Slide

  2. 2
    自己紹介
    名前:車井 登 / Noboru Kurumai
    ポジション:Solutions Engineer
    経歴:パッケージソフト開発
       クラウドサービスエンジニア

    View Slide

  3. 3
    はじめに
    - 質問がある場合はいつでもQ&Aに記載をお願いします。時間
    が許す限りお答えします。
    - チャットは参加者全員が見ることができますので、個人情報、
    秘密情報は記載しないようにご注意ください。

    View Slide

  4. 4
    今日お話したいこと
    - CircleCI / CircleCI Japanについて
    - Why CI/CD
    - Why CircleCI
    - Q&A
    - CircleCIのデモ
    - CircleCIの始め方、価格
    - Q&A

    View Slide

  5. 5
    CircleCI について

    View Slide

  6. Introduction to CircleCI
    ● 世界最大規模のクラウド CI/CD サービス
    ● より良いコードをより速く、簡単にリリースすることを可能に
    ● 2011年設立、サンフランシスコ本社
    ● 250人の社員(米国と東京にオフィス)
    ● 19年7月 5,600万ドルのシリーズDを実施、合計1億1,550万ドルを調達
    Representative Customers

    View Slide

  7. 7
    CircleCIの利用実績

    View Slide

  8. 8
    SaaS企業など、多くのユーザーが利用

    View Slide

  9. 9
    2018.06.11 CircleCI Japan発足

    View Slide

  10. 10
    日本語サポート
    https://support.circleci.com/hc/ja

    View Slide

  11. 11
    日本語ドキュメント
    https://circleci.com/docs/ja/

    View Slide

  12. 12
    ユーザーコミュニティー
    @CircleCIJapan
    https://www.facebook.com/grou
    ps/2180735222207131/

    View Slide

  13. 13
    Why CI/CD

    View Slide

  14. 14
    DevOpsの歴史
    2001
    Agile Software Development
    開発対象を厳格に扱うことで変化を管理するの
    ではなく、アジャイル方法論は変化を許容する。
    リスクは完璧な計画によって減少できるもので
    はなく、プロジェクトを小さく分割しつつ、それら
    を素早く結合させることによって減らすことがで
    きる。
    2008
    Continuous Delivery & Deployment
    継続的デリバリーは継続的インテグレーションの拡張として登場。
    ソフトウェアが常にデプロイ可能な状態を保つというプラクティスで
    ある。
    責務(とリスク)を開発者と運用者の間で共有すること - DevOpsカ
    ルチャーの登場。
    チームはテストの自動化だけではなく、テストをパスした際のデプ
    ロイの自動化を目指す。
    1970
    Waterfall
    開発プロセス全体がいくつかのフェーズから構成
    されていて、次のフェーズに進むためには前の
    フェーズを終えていなければならない。
    ただし、隣接するフェーズ間の小さなイテレーショ
    ンは例外的に実施する場合がある。
    (ハードウェアの開発方法論に似ている)
    1994
    Automated Testing & Continuous Integration (Inception & Evolution: 1994-2008)
    開発者は、失敗をより快適なものとして捉え、それが受け入れられないものではなく、む
    しろ自信をつけるものになってきた。 JUnitやCucumberなどのテスティングフレームワー
    クの登場がそれを反映している。
    マイクロプロセスの要求によって登場した継続的インテグレーション (CI)は、開発者が数
    多くの内部リリースを行うことを可能にした。
    すなわち、継続的インテグレーションは常に少量のコードをマージするための方法論で
    あり、開発の最終フェーズで競合を発生させるような巨大なコードのコミットを防ぐ
    2010 - Present

    View Slide

  15. 15
    CI/CDとは
    - CI (Continuous Integration / 継続的インテグレーション)
    - CD (Continuous Delivery / 継続的デリバリ)

    View Slide

  16. 16
    CI: 継続的インテグレーション
    - What?
    全ての開発者が共有リポジトリにコミットを積み重ね、
    全てのコミットをトリガーにしてビルドとテストを繰り返すこと。
    これによりテストに失敗した場合に素早く修正することが可能となる。
    - Why?
    チームの生産性・効率・満足度を上げるため。
    品質を上げ、スピードを上げ、より安定した製品を生み出すため。

    View Slide

  17. 17
    CIでできること
    ● コードのビルド
    ● 静的コード解析
    ● 単体テスト
    ● 結合テスト
    ● 脆弱性チェック
    ● テストサマリー

    View Slide

  18. 18
    CIが解決する問題
    ● 全てのコミットに対してCIする
    ○ 早い段階でバグを発見できる
    ○ 設定で制御可能
    ● 静的解析などでの標準化
    ○ コードの品質UP
    ● テスト失敗したコードのマージブロック
    ○ masterブランチの安全保証

    View Slide

  19. 19
    CD: 継続的デリバリー/デプロイメント
    - (狭義の)Continuous Delivery (継続的デリバリー)
    常にリリース可能な状態を維持する
    - Continuous Deployment (継続的デプロイメント)
    自動でステージング・本番環境へデプロイする

    View Slide

  20. 20
    自動
    Continuous Delivery (継続的デリバリー)
    - リリース作業に人間の意思が介在する
    コードプッシュ
    成果物
    (JAR、TAR、
    Docker Image)
    ステージング
    本番環境
    CI/CD
    人間が
    決定

    View Slide

  21. 21
    自動
    Continuous Deployment (継続的デプロイメント)
    - リリース作業に人間の意思が介在しない
    コードプッシュ
    成果物
    (JAR、TAR、
    Docker Image)
    ステージング
    本番環境
    CI/CD CI/CD

    View Slide

  22. 22
    とは言ってみたものの
    - 継続的デリバリーと継続的デプロイはいろいろな定義がありそう
    - 大事なのはCDを考えるときにステップを刻むこと、ステークホルダーを巻き込むこと
    (一足飛びに本番自動デプロイは難しい)
    成果物の生成
    システムテスト
    ステージング
    自動リリース
    本番環境
    自動リリース
    品質保証
    (第三者検証)
    構成管理
    Blue/Green
    Canary
    監視運用

    View Slide

  23. 23
    エンジニアリングの効率化に欠かせない5つの測定指標
    https://www2.circleci.com/rs/485-ZMH-626/images/5-Key-Metrics-Engineering.pdf
    1. Commit-to-Deploy Time (CDT)
     コードがコミットされてからデプロイされるまでの時間
    3. Queue Time
     CIビルドが始まるまでに待たされる時間
    2. Build Time
     CIビルドに掛かる時間
    5. Engineering Overhead
     ツールのメンテナンスなど開発以外に掛かっている時間
    4. How often Master is Red
     masterブランチが壊れている時間

    View Slide

  24. 24
    Why CircleCI

    View Slide

  25. 25
    CircleCIの概要

    View Slide

  26. Running CI/CD with our hosting options
    cloud
    server Active users
    Active users
    VCS
    VCS
    Databases
    Caches &
    Artifacts
    Build
    Fleet
    (GitHub.com or GitHub Enterprise)
    Databases
    Caches &
    Artifacts
    Build
    Fleet

    View Slide

  27. CircleCI GitLab Connector
    27

    View Slide

  28. 28
    CircleCIは・・・
    - Dockerをサポートしていて、高速にビルド環境を立ち上げることができ、
    - .circleci/config.ymlでテスト環境を統一することができ、
    - ワークフローでジョブを連結することができ、
    - SSHデバッグ機能などでビルドエラーをすばやく取り除き、
    - 複数のキャッシュ機構でビルドを高速化することができ、
    - Orbsを使って簡単にデプロイできる

    View Slide

  29. 29
    Dockerサポート
    - CircleCIはネイティブでDockerをサポートしています。
    - VMによるCIと比べて非常に高速にビルド環境を構築することが可能です。
    https://circleci.com/docs/2.0/circleci-images/

    View Slide

  30. 30
    .circleci/config.ymlでテスト環境を統一

    View Slide

  31. 31
    .circleci/config.ymlでテスト環境を統一
    https://circleci.com/docs/2.0/sample-config/
    Dockerイメージを指定
    コードの取得やテスト内容を
    ステップとして記述
    個々のジョブ定義
    ジョブを組み合わせたワークフロー定義
    ・連続実行
    ・ファンアウト・ファンイン
    ・スケジューリング
    ・ブランチ別
    ・タグ別 ...等

    View Slide

  32. 32
    CircleCIの思想
    - コンフィグはファイルに書かれるべき
    (コードと同じくレビューとバージョン管理を行う)
    - 明示的であるべき

    View Slide

  33. 33
    ワークフロー
    - ビルド設定を分解して、依存関係や並列処理を行うための機能

    View Slide

  34. 34
    ワークフローのタイプ
    ● スケジューリング: ナイトリービルドのように決まった時刻に実行
    ● マニュアル承認: ワークフローの一部で自動実行を中断し、手動による承認によって再開
    ● ブランチ指定: 特定のブランチへのコミットによって実行
    ● タグ指定: Gitのタグによって実行

    View Slide

  35. 35
    SSHデバッグ
    ビルドに失敗した場合など、SSHデバッグをOnにして再実行することで、
    ビルド終了後2時間、もしくはSSHセッションが終わって10分間までは
    コンテナを起動した状態で維持します
    https://circleci.com/docs/2.0/ssh-access-jobs/

    View Slide

  36. 36
    ビルドの高速化(キャッシュ)
    同一ジョブ間のキャッシュ
    ワークフローが繰り返し実行される中で、同一ジョブ
    で利用される永続データを使い回す。
    同一ワークフロー内のキャッシュ
    同一ワークフロー内の異なるジョブ間でデータを共
    有する。

    View Slide

  37. 37
    ビルドの高速化(並列処理)
    4並列でそれぞれ10個のテストを実行
    https://circleci.com/gh/kurumai/circleci-step-by-step/210

    View Slide

  38. 38
    ビルドの高速化(リソースクラス)

    View Slide

  39. 39
    設定のパッケージングと再利用(Orbs)
    - Orbsとは、CircleCIの設定を再利用し、さらにそれを自由に配布する仕組み
    - Orbsを使うと他の人が書いたCircleCIの設定を自分のプロジェクトの
    .circleci/config.yml に差し込むことができる。
    -
    OrbsはOrbsレジストリ上で誰でも公開することができ、他のユーザーが作ったOrb
    を誰でも使うことが可能

    View Slide

  40. 40
    Orbsの種類
    - Orbs Registry
    https://circleci.com/orbs/registry/
    - Certified (CircleCI)
    - Partner (CircleCI認定パートナー)
    - 3rd party (その他)

    View Slide

  41. 41
    質とスピード / Quality and Speed https://speakerdeck.com/twada/quality-and-speed

    View Slide

  42. 42
    質とスピード / Quality and Speed https://speakerdeck.com/twada/quality-and-speed

    View Slide

  43. 43
    Q&A

    View Slide

  44. 44
    Demo

    View Slide

  45. 45
    GitHubとCircleCI
    https://github.com/kurumai/pelican-bookstore/issues/1

    View Slide

  46. 46
    GitHubとCircleCI
    https://github.com/kurumai/pelican-bookstore/pull/3

    View Slide

  47. 47
    Orbs https://circleci.com/gh/kurumai/circleci-step-by-step/271

    View Slide

  48. 48
    CircleCIの始め方
    - CircleCIはGitHubのOAuthアプリケーションとして動作します。
    - CircleCIにログインした段階でGitHubとの連携設定は完了しています。
    - サンプルを見ながらCircleCIの設定ファイル(config.yml)をリポジトリに追加したあと、CircleCIの画面からビルドを開始してく
    ださい。
    https://circleci.com/add-projects/gh/kurumai

    View Slide

  49. 49
    CircleCI Cloud

    View Slide

  50. 50
    CircleCI Server(オンプレ版)
    +
    ご利用環境に応じたサポート費用

    View Slide

  51. 51
    Q&A

    View Slide

  52. Thank you.
    52

    View Slide