pipeline-as-codeファイルとは何か？リポジトリ内のパイプライン

pipeline-as-codeファイルとは、パイプラインを定義するバージョン管理された構成で、それがビルドするコードの隣にリポジトリ内で保存されます。

かつて、パイプラインはCIサーバーのWeb UIをクリックして構成されていました。その状態は、レビューもリバートもできない場所に存在していました。pipeline-as-codeはそれを変えました。パイプラインの定義はリポジトリ内のファイルです。pull requestでレビューされ、コードとともにバージョン管理され、再現可能です。パイプラインはプロジェクトとともに移動します。

なぜパイプラインをリポジトリに置くのか

レビュー済み: 変更はpull requestを通る。
バージョン管理: 履歴が誰がいつ何を変えたかを示す。
再現可能: 同じコミットが同じようにビルドする。
branch可能: branchが自分自身のパイプラインを変更できる。

ファイルが存在する場所

プラットフォームごとにファイルを特定の場所に期待します。GitHub Actionsは .github/workflows/*.yml を使い、GitLabは .gitlab-ci.yml を使い、他にも独自のものがあります。その場所は、プラットフォームがスキャンする慣例です。

簡単な例

.github/workflows/ci.yml にあるGitHub Actionsファイルは、triggers、jobs、stepsをYAMLで宣言します。branch上でそれを編集すると、そのbranchのプッシュは新しいパイプラインを実行し、他のbranchはmergeするまで古いものを維持します。

UI構成 vs pipeline-as-code

サーバーのUIにconfigをクリックするのは手早いですが、レビューに見えず、失われやすいです。pipeline-as-codeは、多少の初期構造を、監査可能性、履歴、そしてリポジトリだけからパイプラインを再作成できる能力と引き換えにします。

ファイルをメンテナンス可能に保つ

パイプラインが成長するにつれ、ファイルも成長します。テンプレートとreusable workflowはそれが肥大化するのを防ぎ、エントリーポイントをリポジトリに保ちつつ、共有ロジックをプロジェクトごとのファイルから抽出できるようにします。

重要なポイント

pipeline-as-codeファイルは、パイプラインをバージョン管理されたconfigとして定義します。
ソースの隣でレビューされ、バージョン管理され、再現可能です。
各プラットフォームは、スキャンする慣例的な場所にファイルがあることを期待します。