CI/CD Conference 2021からCI/CDのパターンを解説したセッションを紹介

CI/CD Conferenceから、株式会社野村総合研究所（以下、NRI）のシステムエンジニアである土屋大樹氏が行ったCI/CDのパターンを解説するセッションを紹介する。セッションのタイトルは「現場に合わせて考えたパイプラインのデザインパターン」ともので、CI/CDにはツールからではなくアプリケーションのタイプや組織の大きさ、成熟度などによって最適なパターンがあるのでは？ というNRIの顧客案件などからCI/CDのプロセスごとに複数の実装パターンを切り分けて紹介したものだ。

NRIはオープンソースソフトウェアに対するサポートサービス、OpenStandiaやasleadなどを立ち上げて、オープンソースソフトウェアを用いたマネージドサービスを積極的に提案しているようで、今回のセッションもベースになっているのは自社が利用するGitLabのCI/CDサービスだ。

GitLabはオープンコアをビジネスモデルにしており、コードのコアの部分はオープンソースとして公開し、付加価値の部分を有償サービスとして提供する。GitLabのCI/CDについては、個人向けの無償のコースもあるが、CI/CD実行時間の制限や、すべての機能が提供されないなどの制約がある。NRIはGitLabの販売チャネルパートナーであり、このセッションがGitLabベースになっているのは当然の選択だろう。

セッションを行う土屋氏

GitLabの機能によるCI/CD

土屋氏はCI/CDについて解説するスライドを使ってセッションを始めた。このスライドではCI/CDの構成要素として、リポジトリなどのCI/CD基盤、CIとCDの内容、そしてアプリケーションの実行環境としてテスト環境、本番環境というステージングを挙げて説明を行った。このセッションは、CI/CDについてある程度の知識と経験を持っている人を対象にしているようで、実際、この後で解説される組織構成においてもアプリ開発チーム、インフラチーム、標準化／共通チームの存在が前提になっていた。

CI/CDに含まれる要素を解説

そしてGitLabによる実装を例に挙げて、具体的にどのような流れになるのかを説明した。

GitLabとSonarQube、Nexusなどを使った実装例を紹介

オープンソースのソース解析ツールであるSonarQubeやパッケージリポジトリのNexusなどが明記されている辺りに、実際に業務で使っている感が出ている。ただ、デプロイを行う先がテスト環境、本番環境などと簡素化されているのが気になるが、今回のトピックではあまりそこには触れないということだろう。

GitLabを使ったCI/CDの基本、Gitリポジトリにパイプラインを紐付けることが原則などを紹介した後で、今回のテーマの中心であるパイプラインについて解説を行った。

GitLab CI/CDのパイプラインとは？

パイプラインとはCIやCDを行うための一連のジョブを指しており、ステージは複数のジョブから構成され、ジョブは並列にも直列にも構成できるという認識で問題ないだろう。

土屋氏が経験したCI/CDを導入した事例

またパイプラインの対象となるアプリケーションも、仮想マシンが必要なものからコンテナやKubernetesをベースにしたもの、さらにサーバーレスのように非常に細かい粒度のアプリケーションまで存在するが、このスライドでは土屋氏が経験したアプリケーションを挙げているようだ。サーバーレスに関しては経験していないことを正直に告白しているのは良いが、できれば社内の事例をヒアリングして臨んで欲しかった。これらの経験を元に、CI/CDのパイプラインを構成する際のパターンを紹介するのが後半のコンテンツとなる。

その前にCI/CDを使う場合の組織について説明した。

NRIが考えるCI/CDを導入する組織の例

ここではビジネスが要求するアプリケーションを開発するチーム、アプリケーションが利用するインフラストラクチャーを提供するチームの他に、標準化を推進し共通の部品を提供するチームによって構成されていることがわかる。

また標準化／共通チームについては「システム開発において起こりうる問題の発生を、設計開発ルールの策定や開発環境を提供することで未然に防ぐ」役割であると定義している。

標準化／共通チームとは

この定義自体は妥当なものと言えるが、その特性を発揮するためには相当高いレベルのエンジニア集団であることが想定される。しかし現実には、開発チームと運用チームに分かれている場合が多く、共通チームは双方のチームのエンジニアが兼任という形で構成されることも多いと予想される。ここでは単に定義だけではなく、NRIが推奨する共通チームのエンジニアが持つべき知識と経験について指針を出して欲しかった。

CI/CD導入の課題

ここからは、プロジェクトチームのサイズに応じて求められる知識などを解説する段となった。

小規模なプロジェクトの場合の体制例

この例ではアプリケーション開発チームがイニシアティブを握ってアプリケーションコードの開発からインフラストラクチャーの実装、CI/CDを行うと説明されている。これも理想形の提示で留まっており、この場合に発生が予想される問題点などについても掘り下げた解説を聞いてみたかった。

CI/CDの導入の目的とは

このスライドでは「CI/CDが必要となる背景」が説明されており、「リリースを頻繁に行いたい」「新しい技術などについて試行錯誤したい」「俗人化したリリース作業を自動化したい」などが語られている。これをベースに実際にCI/CDを導入するのは企業や組織だが、新しい技術であるCI/CDを導入するには人材の確保が難しく、このスライドで挙げられている作業項目をこなすためにも、外部のリソースを活用して欲しいという意図が見える。もちろんこの場合の外部リソースはNRIというわけだ。

組織にCI/CDを入れるには外部の支援が必須？

そしてNRIの現状認識として、アプリケーションチームにも標準化／共通チームにも人材が不足していることを説明した。

CI/CDを開発できる人材がいないというNRIの現状認識

これは先に紹介した小規模プロジェクトにおけるCI/CDの例では、アプリケーション開発チームにCI/CDからDocker、Kubernetesなどの周辺知識まで習熟度が高いメンバーが存在するという理想形を自ら否定した形になってしまっている。

また土屋氏の経験したプロジェクトでのフィードバックなどから、学習コストを下げたい、アプリケーション開発チームとして設定や変更を少なくしたい、誰でも自由に変更できないように設定したい、CI/CD自体の保守運用を楽にしたいなどの要求があることを挙げた。

現場からの声を紹介

その上で、CI/CDシステムとしての変動要素をどうやって組み合わせると、これらの声を満足させることができるのか？ について、パターンを挙げて説明した。

CI/CDシステムの要素を組み合わせて要求を満足させるか？ がポイント

次に例としてあるタグが追加されたら、ジョブが実行されるというトリガーについて、個々の設定ファイルに記述するのではなく、条件判断の部分を外部に切り出して一本化するパターンを紹介した。

タグの処理を外部化する例を紹介

パイプラインのデザインパターン

CI/CDのパイプラインの設計については、要求仕様によってパターン化できるのでは？ という発想を受けて「デザインパターン」として整理しようというのがここからの説明の内容だ。

CI/CDのパイプラインをデザインパターン化したい

多くのパターンが紹介されているが、ここでは一例としてテンプレートと環境変数を使った例を紹介している。

テンプレートを使ったジョブの例

またCI/CDのジョブがエラーで失敗する場合に、その処理時間をセーブするためのコツとして予め環境変数などの存在をチェックするエラーチェックジョブをパイプラインの初期に実行することで、失敗を早期に発見するなどの例が紹介された。

エラーチェックジョブを組み込んでエラーを早期に発見

デザインパターン自体はパイプラインの組み方に多くのタイプが存在し、その他にはそれほど知見が存在しないように見えることや、GitLabに特化した内容となっていることは気になるところだ。またCI/CD自体のエラーではなく自動化されたロールアウトの結果、何かのトラブルによってロールバックが必要となるような場合の対処方法については完全に切り落とされている。正常系のプロセスだけが想定されているのも残念な部分だろう。時間の制限もあり仕方ないところだろうが、NRIの経験を活かした、より踏み込んだ解説を期待したい。