「第1回 はじめてのCircleCIウェビナー」を聴講しました
@CircleCI Japan の @kurumaiさん による「第1回 はじめてのCircleCIウェビナー」を聴講しました。
CI/CDとは何ぞという部分からなぜやる（流行っている）のか、CircleCIではどう実現するのかということが丁寧にまとまっていてとても勉強になりました。
SSHデバッグや並列処理に関しては知らなかったので、これからもっと活用していきたいです。 第1回ということなので2回、3回とあるんだと思いますが、次回以降も楽しみです！
スライド
以降はスライドのメモです。
DevOpsの歴史
- 1970~: Waterfall
- 1994~: Automated Testing & Continuous Integration
- 2001~: Agile Software Development
- 2010~: Continuous Delivery & Deployment
CI/CDとは
- CI(Continuous Integration)
- CD(Continuous Delivery/Deployment)
CIとは
- What?
- 全ての開発者が共有リポジトリにコミットを積み重ね、全てのコミットをトリガーにしてビルドとテストを繰り返すこと。
- Why?
- チームの生産性・効率・満足度をあげるため。
- 品質をあげ、スピードをあげ、より安定した製品を生み出すため。
CIでできること（=CircleCIでできること)
CIが解決する問題
- 全てのコミットに対してCIする
- 早い段階でバグを発見できる
- 設定で制御可能
- 静的解析などで標準化
- コードの品質UP
- テスト失敗したコードのマージブロック
- masterブランチの安全保証
- 人間によるコードレビューだけでなく機械的にも実施する
CDとは
- （狭義の）Continuous Delivery
- 常にリリース可能な状態を維持する
- Continuous Deployment
- 自動でステージング・本番環境へデプロイする
- 必ず本番環境まで自動でデプロイするべきかはプロダクトの制約などにもよる
- 切り戻しも自動化できる
とは言ってみたものの
- 色々な定義がありそう
- 大事なのはCDを考えるときにステップを刻むこと、ステークホルダーを巻き込むこと（一足跳びに本番自動デプロイは難しい）
Puppet: State of DevOps Report 2018
- Puppet社が30,000人に対する調査結果を公開（内、6-7%が日本）
- 業績が上がった上位11%を「高」、下位10%を「低」、それ以外を「中」で分類
- 業績が高い企業の大多数がテストパターンとデプロイパターンを「いつも」または「ほとんど」再利用していると回答
5 Metrics You Should Know to Understand Your Engineering Efficiency
- Commit-to-Deploy Time(CDT)
- コードがコミットされてからデプロイされるまでの時間
- Build Time
- CIビルドに掛かる時間
- Queue Time
- CIビルドが始まるまでに待たされる時間
- How often Master is Red
- masterブランチが壊れている時間
- ngineering Overhead
- ツールのメンテナンスなど開発以外にかかっている時間
PDF: https://www2.circleci.com/rs/485-ZMH-626/images/5-Key-Metrics-Engineering.pdf
CircleCIは・・・
- Dockerをサポートしていて、高速にビルド環境を立ち上げることができ、
- .circleci/config.ymlでテスト環境を統一することができ、
- ワークフローでジョブを連結することができ
- SSHデバッグ機能などでビルドエラーをすばやく取り除き、
- 複数のキャッシュ機構でビルドを高速化することができ、
- Orbsを使って簡単にデプロイできる
Dockerサポート
- CircleCIはネイティブでDockerをサポートしています。
- VMによるCIと比べて非常に早く環境を立ち上げることが可能。
.circleci/config.ymlでテスト環境を統一
- CircleCI-Publicにさまざまな言語・フレームワークのサンプルconfig.ymlがある
CircleCIの思想
- コンフィグはファイルに書かれるべき（コードと同じくレビューとバージョン管理を行う）
- 明示的であるべき
- その結果、デメリットも
- 1から設定を書かないといけない
- 冗長になる
ワークフロー
- スケジューリング
- マニュアル承認
- ブランチ指定
- タグ指定
SSHデバッグ
ビルドに失敗した場合など、SSHデバッグをOnにして再実行することで、ビルド終了後2時間、もしくはSSHセッションが終わって10分間まではコンテナを起動した状態で維持する。
ビルドの高速化（キャッシュ）
- 同一間ジョブのキャッシュ
- ワークフローが繰り返し実行される中で、同一ジョブで利用される永続データを使い回す
- ex.)依存ライブラリのキャッシュ
- 同一ワークフロー内のキャッシュ
- 同一ワークフロー内の異なるジョブ間でデータを共有する
- ex.)ビルド結果を渡してテスト・デプロイ
ビルド高速化（並列処理）
https://circleci.com/gh/kurumai/circleci-step-by-step/210
設定のパッケージングと再利用（Orbs）
- Orbsとは、CircleCIの設定を再利用し、さらにそれを自由に配布する仕組み
- Orbsを使うと他の人が書いたCircleCIの設定をプロジェクトの.circleci/config.ymlに差し込むことができる
- Orbs Registry
- Cetified(CircleCI), Partner(CircleCI認定パートナー), 3rd party(その他)
