PipeCD

PipeCD

次に、後半のNghia氏によるPipeCDの解説に移ろう。

CIとCDは同じものではないという再確認

Nghia氏はCI/CDと一連の単語のように語られているが、実際にはソースコードのビルドから単体テスト～アーティファクトリポジトリーへの格納までがCI（Continuous Integration）、バイナリーやライブラリーをステージングや本番環境などのクラスターに実装するのがCD（Continuous Delivery）ということを説明した。CIツールとしてはJenkins、GitHub Actions、CircleCI、Concourseなどが挙げられている。そしてCDツールには、今回の説明の対象であるPipeCDのほか、Harness、Flux、ArgoCDなどが挙げられている。

またサイバーエージェントでは開発チームごとに最適なツールの選択の自由があるため、多種のCDツールが社内で使われていることを紹介した。

CDの課題、チームごとにCDの経験値に差があること

そこで社内のプロダクトチームとインフラストラクチャープラットフォームチーム、それぞれの要望を満足させるためのツールを開発したというのがPipeCDの背景だ。

開発チームとインフラチーム双方の要望を満たすためのツールを開発

ここで注目したいのは、プロダクトチームとプラットフォームチームの両方の要望を満たすことを目指していることだろう。CI/CDやDevOpsは、どちらかと言えばデベロッパー目線でインフラをソースコードでプログラミングするように扱うことが主題となっていて、安定運用させることを目指す運用チームの視点が欠ける傾向にある。ここでは、PipeCDの開発自体をプラットフォームチームが行うことで、デベロッパーの負担を下げようとしているようだ。

PipeCDとは

PipeCDはGitOpsをコアとしたツールであり、構成情報や変更指示などはすべてGit上のコードとして残されるようになっているのが特徴だろう。

GitOpsを具体化したPipeCD

そしてインフラストラクチャーを担当するプラットフォームチームにとっての利点として、シンプルなアーキテクチャーで運用コストが低いこと、スケーラブルであることなどを挙げた。

シンプルな構造がプラットフォームチームへの利点

サービスを開発するプロダクトチームへの利点は多くあるが、ここでは可視化、観測性を挙げて説明を行っている。デプロイする内容を予め検証するPlan Previewなどが紹介された。

デベロッパー向けの利点の例

また自動化という点では、デプロイされたコードのメトリクスを取得することで過去のデータとの比較や分析が行えること、問題が発生した場合に自動でロールバックする機能などが紹介された。

CA社内のチーム構成。プラットフォームチームがPipeCDを開発

このスライドでは社内の開発体制を紹介している。PipeCD自体はプラットフォームチームが開発し、プロダクトチームはユーザーとしてエージェントを導入するだけで利用可能になるというのが、CDツールとして優れている点だろう。

また将来の構想として多くの機能拡張を予定していることを紹介してセッションを終えた。

PipeCDの将来構想

この機能拡張の計画は、PipeCDのドキュメントとしても公開されており、オープンソースプロジェクトとして透明度を上げる要因として評価されるべきだろう。

Feature Status | PipeCD

現状では、PipeCDにサイバーエージェント以外のコントリビューターが積極的に参加しているようには見えず、露出も非常に少ないというのが実情だろう。Myshoesとともにコミュニティが拡がることを期待したい。

Myshoes公式GitHubページ：https://github.com/whywaita/myshoes

PipeCD公式サイト：https://pipecd.dev/