この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
皆さんこんにちは。[石橋]https://twitter.com/1484_yuji)です。昨日参加させて頂いた、CircleCIユーザーコミュニティのオンラインイベントである「はじめてのCircleCI」のイベントレポートを書かせて頂きます。
イベント概要
今回は、CI/CDは知っているけど、
- CI/CDのより詳しい情報を集めている方
- CircleCIを触ったことがないが試してみたい方
- DevOpsを社内に浸透させようとしている方
向けのオンラインセミナーという形で行われました。
CircleCIとは
- 世界最大規模のクラウドCI/CDサービス
- より良いコードをより速く、簡単にリリースすることを可能にする
- 2011年設立、サンフランシスコ本社、300人以上の社員(米国、東京、英国にオフィス)
- 2500万の月間ジョブ(2017年時点では300万件)(伸びがすごい！！)
- 50万人以上のCircleCIを使用する開発者数(2017年時点では17.5万人)(伸びがすごい！！)
- 日本でも多くの企業での導入事例
- 日本語でのサポート
- 日本語のドキュメント
- 世界中のユーザーコミュニティ
Why CI/CD
CI/CDとは
CI (Continuous Integration / 継続的インテグレーション)
- What?
- 全ての開発者が共有リポジトリにコミットを積み重ね、全てのコミットをトリガーにしてビルドとテストを繰り返すこと。
- これによりテストに失敗した場合に素早く修正することが可能となる。
- Why?
- チームの生産性・効率・満足度をあげるため。
- 品質を上げ、スピードを上げ、より安定した製品を生み出すため。
- CIでできること
- コードのビルド、静的コード解析、単体テスト、結合テスト、結合テスト、脆弱性チェック、テストサマリー
- CIが解決する問題
- 全てのコミットに対してCIする
- 早い段階でバグを発見できる
- 設定でテスト・ビルドを制御可能
- 静的解析などで標準化
- コードの品質UP
- テスト失敗したコードのマージブロック
- masterブランチの安全保証
CD (Continuous Delivery / 継続的デリバリ)
- (狭義の)Continuous Deliverly(継続的デリバリー)
- 常にリリース可能な状態を維持する
- リリース作業に人間の意思が介在する
- Continuous Deployment(継続的デプロイメント)
- 自動でステージング・本番環境へデプロイする
- リリース作業に人間の意思が介在しない
CI/CDに関する資料
Puppet: State of DevOps Report 2018
- 業績の良い会社はテストパターンやデプロイパターンの再利用が多い
- Commit-to-Deploy Time(CDT)
- コードがコミットされてからデプロイされるまでの時間
- Build Time
- CIビルドにかかる時間
- Queue Time
- CIビルドが始まるまでに待たされる時間
- How often Master is Red
- masterブランチが壊れている時間
- エンジニアリングの間接コスト
- ツールのメンテナンスなど開発以外に掛かっている時間
CircleCIの3000万件のワークフローから得られたDevOpsに関する知見
Why CircleCI
CircleCIの概要
CircleCI機能や特徴
- 運用コスト・維持コスト削減
- 運用チームや自社環境の構築が不要(オンプレ版は必要)
- .circleci/config.ymlでテスト環境の統一
- 開発スピード向上
- Dockerサポートにより、高速にビルド環境を立ち上げ
- SSHデバック機能でビルドエラーの迅速な解決
- パラレルジョブ・マルチコンテナでキュー(待ち時間)を解消
- 複数のキャッシュ機能でビルドを高速化
- パイプラインでジョブを連結
- パイプライン改善
- Orbs(configのパッケージ)を使って、簡単にビルドやテスト・デプロイが可能
Dockerサポート
- circleciはネイティブでdockerをサポートしてる
- vmによるciと比べて非常に高速にビルド環境を構築することが可能です。
.circleci/config.ymlでテスト環境を統一
- 個々のジョブ定義
- Dockerイメージの指定、ステップとしてコードの取得やテスト内容を記載
- ジョブを組み合わせたワークフロー定義
- 連続実行、ファンアウト・ファンイン、スケジューリング、ブランチ別、タグ別など
CircleCIの思想
- コンフィグはファイルに書かれるべき(コードと同じくレビューとバージョン管理を行う)
- 明示的であるべき
- その結果のデメリットも
- 1から設定を書かないといけない
- 冗長になる
ワークフロー
- ビルド設定を分解して、依存関係や並列処理を行うための機能
- ワークフローのタイプ
- スケジューリング:ナイトリービルドのように決まった時刻に実行
- マニュアル承認:ワークフローの一部で自動実行を中断し、手動による承認によって再開
- ブランチ指定:特定のブランチへのコミットによって実行
- タグ指定:Gitのタグによって実行
SSHデバック
- ビルドに失敗した場合など、SSHデバックをOnにして再実行することで、ビルド終了後2時間、もしくはSSHセッションが終わって10分間までは、コンテナを起動した状態で維持する
ビルドの高速化
- ファイルの再利用
- 同一ジョブ間のキャッシュ
- ワークフローが繰り返し実行される中で、同一ジョブで利用される永続データを使い回す
- 同一ワークフロー内のデータの引き継ぎ
- 同一ワークフロー内の異なるジョブ間でデータを共有する
- 並列処理
- 並列に実行するジョブ数を制限することで、時間がかかるジョブがボトルネックにならない
- リソースクラス
- ビルドを実行する環境(DockerやLinux)のスペックを調整できる
- vCPUやメモリなどの組み合わせを選択可能
設定パッケージングと再利用(Orbs)
- Orbsとは、CircleCIの設定を再利用し、さらにそれを自由に配布する仕組み
- Orbsを使うと他の人が書いたCircleCIの設定を自分のプロジェクトの.circleci/config.ymlに差し込むことができる。
- OrbsはOrbsレジストリ上で誰でも公開することができ、他のユーザーが作ったOrbを誰でも使うことが可能
- Orbsの種類
- Orbs Registry
- Certified(CircleCI)
- Partner(CircleCI認定パートナー)
- 3rd party(その他)
まとめ
今回の勉強会に参加したことで、CircleCIの基本的な機能を学ぶことができました。また、勉強会の最後にデモとして、実際に構築されたパイプラインがどのように動くかという様子も見せて頂きました。次は実際にCircleCIでCI/CDパイプラインを構築するブログを書きたいと思います。
参考
CircleCIの3000万件のワークフローから得られたDevOpsに関する知見
2
