父は重機整備士でしたが、業界にまだ専用ツールが存在しない難しい作業のために、自ら道具を作ってしまうことがよくありました。その姿が、いつも不思議で印象的でした。まさか自分がIT分野でツール作りに情熱を注ぐようになるとは、当時は思いもしませんでしたが、今やそれが長年にわたる喜びの一つになっています。
GitLab を使い始めてから4年以上、CI/CDのインクルード可能な共有テンプレートを作り続けてきました。これらのテンプレートは、Node.js の NPM、Python の PyPI、.NET の NuGet といったアプリケーション言語の依存関係マネージャーと同様に、他のユーザーが直接依存できる形で設計されています。
GitLab 自体も、Auto DevOps やセキュリティスキャンツール群を通じて、こうした共有CI依存関係の構築に長年の実績を持っています。
GitLab CI/CDカタログの登場により、この長年のアプローチが正式な仕組みとして整備され、誰もがGitLab CI/CDコンポーネントを世界中のユーザーに向けて公開できるようになりました。
共有テンプレートアプローチと比較した場合の主なアップグレードポイントは次のとおりです。
- コンポーネントの独立バージョン管理は、コンテナバージョンの継承に依存しない新しいバージョニングの仕組みです。GitLab CI/CDコンポーネントのバージョンは、CIコードと任意の数のコンテナ（またはコンテナなし）を一つのCI/CDコンポーネントバージョンとしてまとめます。本番グレードのDevSecOpsでは、依存関係のバージョンを固定する機能が不可欠です。これは、本番グレードのアプリケーションコードで依存バージョンを固定するのと、まったく同じ理由・メリットによるものです。
- **グローバルな可視性（制御付き）**は、GitLab.comのカタログ（またはセルフマネージドインスタンスでは社内全体）を通じて利用できます。個々のコンポーネントの可視性は、ソースプロジェクトのセキュリティ設定にも依存するため、セキュアなグループにコンポーネントを公開することも可能です。
- カタログメタデータは、ほとんどのコード共有の仕組みと同様に、どのコンポーネントを使用するかを判断するために必要なデータです。
コードを見てみましょう
説明よりも実例を示すのが好みなので、いくつかのコンポーネント例を見てみましょう。いずれもソースを公開しています（タイトルをクリックするとコンポーネントにアクセスできます）。
1. Hello World
最小構成のコンポーネントとして、その結果とソースの両方を示せる Hello World コンポーネントがまだ存在しないことに気づいたため、作成しました。この例では、CIコードのみを「コンポーネント化」する方法を示しています。
2. Hello World Container
CI/CDコンポーネントが完全に機能するためにコンテナが必要な場合があります。この例では、コンポーネント自体と同じプロジェクトで公開されるコンテナが含まれています。
3. GitVersion Ultimate Auto Semversioning
このコンポーネントは、老舗の「GitVersion」ユーティリティを自動化するものです。GitVersion は、最後のバージョンを保存することなく、次のセマンティックバージョンを完全に自動で選択します。多くの本番候補が同時に進行しているような忙しいリポジトリでも対応できます。このコンポーネントが従う設計原則の一つは「最小設定」、つまり「設定ゼロで最も有用なことをデフォルトで行う」というものです。プロジェクトに GitVersion.yml が存在しない場合、GitVersion に不慣れなユーザーにとって最も有用な出発点となるファイルをコンポーネントが自動生成します。
4. Amazon CodeGuru Secure SAST Scanner
このコンポーネントはセキュリティスキャナーであり、近年実践してきたセキュリティスキャンのベストプラクティスに従っています。たとえば、GitLab Ultimate のライセンスが検出された場合、スキャナーは GitLab の SAST JSON 形式で出力し、ネイティブの GitLab スキャナーと同様にマージリクエストやダッシュボードに結果を統合します。また、セキュリティポリシーによるマージ承認の対象にもなります。GitLab Ultimate のライセンスがない場合は、パイプラインの「テスト結果」タブで基本的な差分なしの検出結果を確認できる JUNIT XML 形式で出力します。さらに、スキャン可能なファイル種別が存在する場合にのみ動作し、GitLab の SAST_DISABLED プロパティがオンになっている場合は無効化されます。
5. Checkov IaC SAST
Checkov IaC SAST も同様のセキュリティスキャナーコンポーネントで、上記のセキュリティスキャナー原則に従いつつ、スキャン可能なファイル種別に特化しています。これらのコンポーネントの重要なベストプラクティスの一つは、安定性のためにコンテナタグを固定することです。ただし、デフォルト値を持つ「コンポーネントインプット」を通じて行うことで、コンポーネントユーザーが最後にテストされたバージョンより新しいまたは古いバージョンでテストしたり、特定バージョンに固定したりできるようにしています。つまり、共有依存関係として安定性を提供しつつ、柔軟性も兼ね備えているということです。
6. Super-Linter
Super-Linter は、多くの言語向けのリンターを集めたコミュニティ主導のコンポーネントです。もともと GitHub Action として始まったため、この例はオープンソースの GitHub Action を GitLab CI/CDコンポーネントに移植する手軽さを示すものでもあります。私のコンポーネントの多くで大切にしているベストプラクティスの一つは、コンポーネントが動作している状態のサンプルコードへのリンクを必ず提供することです。これにより、アップデート時のテストも容易になります。
7. Kaniko
Kaniko は、Docker-in-Docker（DinD）の特権モードを必要とせずにコンテナをビルドできるコンテナです。このコンポーネントは、多くの OpenContainers ラベルとマルチアーキテクチャビルドをサポートしています。
8. CI Component Publishing Utilities
コンポーネントを作るにつれ、「コンポーネント公開用のCIコード」が何度も重複していることに気づき、それ自体をコンポーネント化する候補になりました。ここに挙げた他のコンポーネントはすべて、このコンポーネントを活用しています。また、このコンポーネント自身もコンポーネントを使用しており、GitVersion Ultimate Auto Semversioning を使って次のバージョンを取得しています。
なお、CI Component Publishing Utilities は自分自身を公開します。私の多くのコンポーネントでは、標準の「インプット」READMEセクションを「インプットと設定」に拡張し、設定がインプット経由かどうかを示す列を追加しています。インプットを優先するのが原則ですが、変数の方が柔軟性が高い場合や、ユーティリティがすでにサポートしている環境変数を通じてユーザーが主要な設定を行えることを文書化したい場合もあります。CI Component Publishing Utilities は Kaniko CI コンポーネントも使用しており、プロジェクトのルートに Dockerfile が見つかった場合（または変数でパスを指定した場合）に、同じバージョンのコンテナをビルドします。これにより、コンポーネントとそれをサポートするコンテナのバージョンが同期されます。マルチアーキテクチャのコンテナビルドにも対応しています。詳細は上記のドキュメントをご覧ください！
コンポーネントテンプレートを使って始める
Hello World コンポーネントは、新しいコンポーネントを始める際の個人的なテンプレートとして活用しています。CI Component Publishing Utilities と適切な README が組み込まれています。
CIコードのみのコンポーネントには Hello World のソースをコピーして始め、コンテナが必要なものには Hello World Container から始めます。クリーンなコミット履歴を保つため、基本的にソースだけを新しいプロジェクトにコピーしています。
コンポーネントが安定して十分に開発されたと感じたら、手動でパイプラインを実行し、バージョンを 1.1.0 以上に強制設定します。その後は CI Component Publishing Utilities が自動でバージョンをインクリメントしていきます。
CI コンポーネント開発者のガイドとプラクティス
Darwin の CI コンポーネント開発者ガイド — コンポーネント構築のアプローチを広く公開したいと考え、CI/CDコンポーネントとして公開するという方法を選びました。また、CI/CDコンポーネントのアーキテクチャと CI/CDカタログを作成した GitLab パイプラインオーサリングチームが、CI コンポーネントのベストプラクティスとして優れた内容を公開しています。私のプラクティスはこれらを参照しつつ、自分自身の経験から得た独自のものも多数含まれています。
CI/CDコンポーネントとソースを探す
GitLab CI/CDカタログの検索機能はまだ改善中ですが、ソースプロジェクトの説明文は自由テキストで検索できます。そこで、すべてのコンポーネントソースプロジェクトの説明に共通テキストを含めることで、カタログ内で作成したコンポーネントを一覧表示できるようにしました。
GitLab.com 上の場所にかかわらず、コンポーネントソースを見つけやすくするために次の対策を行っています。
- すべてのプロジェクトに DarwinJS Component Builder Library というリポジトリトピックを追加しています。
- 有機的に発見した
GitLab CICD Componentsタグも付与しています。
上記の方法はどちらも、コンポーネントとそのソースへのインデックスを提供するのに役立ちます。
私の CI/CDコンポーネント開発の歩みが、今後の皆さんのお役に立てれば幸いです。
CI/CDカタログとコンポーネントについてさらに詳しく：
