概要
昨今、多くのサービス(アプリケーション)がVMやコンテナなどの仮想基盤上で動作するようになってきました。そのような中、開発スタイルも多様になり、今ではアジャイル開発をしている現場も多くなってきました。私が参画していたウォータフォール開発が主流だった基盤開発案件も、チームによってはアジャイル開発が進められるようになってきました。アジャイル開発では、CI (継続的インテグレーション：ビルドやテストを自動化し、短期間で品質管理を行う手法) がよく用いられます。
本記事では、基盤構築・検証試験などの複数Projectを抱える基盤開発案件において、GitLab上での効率的なCIパイプライン設計検討を行った軌跡をご紹介したいと思います。(対象読者はGitLab CI/CD機能を少し触ったことのある方になります)
各ProjectのCIパイプライン設計
私が参画していた基盤開発案件では、サーバ構築・構築後基盤試験・VM/運用系試験がそれぞれ別Project(リポジトリ)で開発されており、それぞれのProjectについては、CIパイプラインが動作するようにしていました。以下はサーバ構築ProjectにおけるCIパイプラインの例になります。
一方で、サーバ構築・構築後基盤試験・VM/運用系試験を一気通貫で定期的にパイプラインを回すといった設計ができていませんでした。これにより、基盤試験を行った直後に運用試験を行うことで発生するバグなどの検出が早期に発見できていないという課題がありました。そこで、結合試験の観点でのエラーを早期に発見できるように、サーバ構築・構築後基盤試験・VM/運用系試験を一気通貫で定期的にパイプラインを回せるように検討することにしました。
複数ProjectのCIパイプライン設計
設計検討
前述のように、現状以下の3つのProjectが存在します。
- サーバ構築Project (ここでは "Server-Construction-demo" とします)
- 構築後基盤試験Project (ここでは "Server-Check-demo" とします)
- VM・運用系試験Project (ここでは "VM-test-demo" とします)
これらを上から順番に一気通貫でパイプラインを実行するためには、サーバ構築前にサーバが削除されている状態である必要があるため、追加で「サーバ削除Project」を作成する必要があると考えました。(ここでは "Server-Destroy-demo" とします)
よって、以下のフローでパイプラインを回すことを想定しました。
実装検討
今回は、"Server-Construction-demo" と "Server-Check-demo" の部分のみをとりだして、この2つのProjectのパイプラインが通貫で流れるようにする例を示します。
実装前の前提条件として、パイプラインを実施する runner が「Group runner」として設定されている必要があります。具体的には、一気通貫で流したい複数のProjectが1つの共通したGroupに属しており、そのGroupのCI/CD Settingsで Group runner として設定されている必要があります。(GitLab runner に関しては、こちら を参照ください)
GitLabにおいて、複数Projectをまたぐパイプラインを実施するためには、起点となるProject(今回の場合は "Server-Construction-demo" )のCI設定ファイル(.gitlab-ci.yml)に手を加える必要があります。
まずは、"Server-Check-demo" のパイプラインを実施する stage を追加します。
次に stage で定義した server_check ジョブを末尾に追加します。このとき、trigger: project: で次に流すProjectのパイプラインを指定することができます。(ここでは次に流したい "Server-Check-demo" を指定しています)
また、trigger: strategy: depend とすることで、別Projectのパイプライン実行をミラーリングできるようにしています。(逆にこれをつけないと、下流のパイプラインが作成された段階でsuccess表示となってしまいます)
そのほか、ブランチの指定・変数の受け渡しなども可能です。それらについては、こちら を参照ください。
結果
"Server-Construction-demo" → "Server-Check-demo" でパイプラインを通貫で実行することができました。両方のProjectのCI/CD Pipelineから確認可能です。
今後の展望
任意のProject間でのパイプライン実行
今回は複数Projectにまたがるパイプライン設計の検討/実装デモを実施できたことによって、構築→基盤試験→運用試験 を一気通貫で定期的にパイプラインを回せる道筋をつけることができました。今後は以下のように、一気通貫だけでなくProjectの任意の固まりごとにパイプラインを実施できる設計を検討していこうと考えています。
CogF(コグニティブ・ファウンデーション)を活用したパイプライン実行
現在、複数の環境を複数のチームが使用しており、環境利用調整がネックとなっています。こちらについても、調整を自動化して、適切な環境を自動で選択してパイプラインを実行できるような仕組みにしていきたいと思っています。(既存のCIパイプラインの仕組みは、特定の環境を静的に指定して流すものとなっているため、環境を動的に切り替えて実施できるように工夫していきたいです)
実行可能環境の提案に CogF(コグニティブ・ファウンデーション) を活用できると、より良いのではないかと想像しています。
