10/1と10/4にCircleCIのイベントに参加しました。振り返ることでCircleCIについての理解を深めたいと思います。

イベント参加前の理解度

継続的インテグレーション(CI)と継続的デリバリー(CD)のこと。詳しい意味は理解してない。
GitHubと連携してテストとビルドを自動化してくれて、デプロイに対する手動的な作業が軽減される。
- リリーススパンを短くするために必要。テストを人力で行うと非常に時間がかかる。
CircleCIはCI/CDツールの中で人気が高い。

イベントに参加してわかったこと

※（ほぼウェビナーの内容ですみません...）

CI/CDとは
- CI(継続的インテグレーション)とは
  - 全てのコミットをトリガーとしてビルドとテストを繰り返すこと。これによりテストに失敗した場合に素早く問題点を修正できる。
    - コミット単位なのでどこでバグが入り込んだかすぐにわかることで調査の時間が減り生産性が上がる。
    - プロダクトの品質、リリーススピードが向上される。
  - テスト失敗したコードのマージをブロック
    - masterブランチの品質を担保できる。
- CDとは
  - 継続的デリバリー
    - 常にリリース可能な状態を維持する。
    - 成果物作成までを自動化して、ステージングおよび本番環境へのリリースを人力で行う。
  - 継続的デプロイメント
    - 自動でステージングして本番環境へのデプロイまで行う。
CircleCIの概要
- 動作の流れ(一例)
  1.GitHubにソースコードをpush
  2.GitHubからCircleCIへwebhookが送られる
  3.CircleCI上でビルド
  4.失敗したらエンジニアに通知される。成功したらmasterブランチにマージされる。
- いかに早くデプロイできるか、いかに早くRed（失敗）をフィードバックするかを考えられたプロダクト。
- Dockerもサポートしている。
- config.ymlでテスト環境を明示的にでき、環境を統一化できる。
  - コードレビューができ、バージョン管理できるメリットがある。
  - 規模が大きくなれば冗長になってしまい保守性が下がってしまうデメリットがある。(Orbsで改善できる)
- CircleCIの特徴
  - ワークフローでの処理実行
    - スケジューリングできる。（1時に開始するといったバッチジョブのようなイメージ。）
    - オプション
      1.マニュアル承認：最後は手動によって承認できる
      2.ブランチ指定：特定のブランチへのコミットに実行
      3.タグ指定：指定されたタグに実行
  - SSHデバッグ
    - ビルド失敗した場合、SSH デバッグをONにして再実行することで最大２時間 or SSHセッション終了10後までビルド失敗したコンテナに入れる。これによりデバッグができる。
  - Orbs
    - config.ymlの一部を切り出してパッケージ化でき、再利用して、再配布できる。
    - 実行時に参照元も合わせたconfigが表示できるので何をやったかわかりやすい。（プリコンパイルのイメージに近い。）
    - Orbsの種類
      1.Certified：CircleCI公式
      2.Partner：CircleCI認定パートナー
      3.3rd party：その他個人、法人
- 日本語サポートに対応している。
- CircleCI公式YouTubeがある

感想

~~ほぼ自分の思った通り。~~
CI/CD自体をバージョン管理できるのでconfig,ymlでコード化できるのが良いなと思った。ymlのテストもできそう？
あとはWebアプリにCircleCIを適用して、今後自分でCircleCIを使ってOrbsの理解を深めたい。（イベントだけだと理解できていない。）
Performaneプランではユーザー数と＋ビルドの時間で課金される。
- ビルド時間で課金するのは面白いなと思いました。費用を減らしたいと思ってビルド時間を下げようとするため、CircleCIの思想となっている「いかに早くデプロイする、失敗を通知する」という力学が働きやすそう。

徒然なるままに

学習メモがメインです

CircleCIについて理解したこと

イベント参加前の理解度

イベントに参加してわかったこと

感想