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についてある程度の知識と経験を持っている人を対象にしているようで、実際、この後で解説される組織構成においてもアプリ開発チーム、インフラチーム、標準化/共通チームの存在が前提になっていた。
そしてGitLabによる実装を例に挙げて、具体的にどのような流れになるのかを説明した。
オープンソースのソース解析ツールであるSonarQubeやパッケージリポジトリのNexusなどが明記されている辺りに、実際に業務で使っている感が出ている。ただ、デプロイを行う先がテスト環境、本番環境などと簡素化されているのが気になるが、今回のトピックではあまりそこには触れないということだろう。
GitLabを使ったCI/CDの基本、Gitリポジトリにパイプラインを紐付けることが原則などを紹介した後で、今回のテーマの中心であるパイプラインについて解説を行った。
パイプラインとはCIやCDを行うための一連のジョブを指しており、ステージは複数のジョブから構成され、ジョブは並列にも直列にも構成できるという認識で問題ないだろう。
またパイプラインの対象となるアプリケーションも、仮想マシンが必要なものからコンテナやKubernetesをベースにしたもの、さらにサーバーレスのように非常に細かい粒度のアプリケーションまで存在するが、このスライドでは土屋氏が経験したアプリケーションを挙げているようだ。サーバーレスに関しては経験していないことを正直に告白しているのは良いが、できれば社内の事例をヒアリングして臨んで欲しかった。これらの経験を元に、CI/CDのパイプラインを構成する際のパターンを紹介するのが後半のコンテンツとなる。
その前にCI/CDを使う場合の組織について説明した。
ここではビジネスが要求するアプリケーションを開発するチーム、アプリケーションが利用するインフラストラクチャーを提供するチームの他に、標準化を推進し共通の部品を提供するチームによって構成されていることがわかる。
また標準化/共通チームについては「システム開発において起こりうる問題の発生を、設計開発ルールの策定や開発環境を提供することで未然に防ぐ」役割であると定義している。
この定義自体は妥当なものと言えるが、その特性を発揮するためには相当高いレベルのエンジニア集団であることが想定される。しかし現実には、開発チームと運用チームに分かれている場合が多く、共通チームは双方のチームのエンジニアが兼任という形で構成されることも多いと予想される。ここでは単に定義だけではなく、NRIが推奨する共通チームのエンジニアが持つべき知識と経験について指針を出して欲しかった。
CI/CD導入の課題
ここからは、プロジェクトチームのサイズに応じて求められる知識などを解説する段となった。
この例ではアプリケーション開発チームがイニシアティブを握ってアプリケーションコードの開発からインフラストラクチャーの実装、CI/CDを行うと説明されている。これも理想形の提示で留まっており、この場合に発生が予想される問題点などについても掘り下げた解説を聞いてみたかった。
このスライドでは「CI/CDが必要となる背景」が説明されており、「リリースを頻繁に行いたい」「新しい技術などについて試行錯誤したい」「俗人化したリリース作業を自動化したい」などが語られている。これをベースに実際にCI/CDを導入するのは企業や組織だが、新しい技術であるCI/CDを導入するには人材の確保が難しく、このスライドで挙げられている作業項目をこなすためにも、外部のリソースを活用して欲しいという意図が見える。もちろんこの場合の外部リソースはNRIというわけだ。
そしてNRIの現状認識として、アプリケーションチームにも標準化/共通チームにも人材が不足していることを説明した。
これは先に紹介した小規模プロジェクトにおけるCI/CDの例では、アプリケーション開発チームにCI/CDからDocker、Kubernetesなどの周辺知識まで習熟度が高いメンバーが存在するという理想形を自ら否定した形になってしまっている。
また土屋氏の経験したプロジェクトでのフィードバックなどから、学習コストを下げたい、アプリケーション開発チームとして設定や変更を少なくしたい、誰でも自由に変更できないように設定したい、CI/CD自体の保守運用を楽にしたいなどの要求があることを挙げた。
その上で、CI/CDシステムとしての変動要素をどうやって組み合わせると、これらの声を満足させることができるのか? について、パターンを挙げて説明した。
次に例としてあるタグが追加されたら、ジョブが実行されるというトリガーについて、個々の設定ファイルに記述するのではなく、条件判断の部分を外部に切り出して一本化するパターンを紹介した。
パイプラインのデザインパターン
CI/CDのパイプラインの設計については、要求仕様によってパターン化できるのでは? という発想を受けて「デザインパターン」として整理しようというのがここからの説明の内容だ。
多くのパターンが紹介されているが、ここでは一例としてテンプレートと環境変数を使った例を紹介している。
またCI/CDのジョブがエラーで失敗する場合に、その処理時間をセーブするためのコツとして予め環境変数などの存在をチェックするエラーチェックジョブをパイプラインの初期に実行することで、失敗を早期に発見するなどの例が紹介された。
デザインパターン自体はパイプラインの組み方に多くのタイプが存在し、その他にはそれほど知見が存在しないように見えることや、GitLabに特化した内容となっていることは気になるところだ。またCI/CD自体のエラーではなく自動化されたロールアウトの結果、何かのトラブルによってロールバックが必要となるような場合の対処方法については完全に切り落とされている。正常系のプロセスだけが想定されているのも残念な部分だろう。時間の制限もあり仕方ないところだろうが、NRIの経験を活かした、より踏み込んだ解説を期待したい。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- CI/CD Conference開催、CI/CDをツールではなく原則の面から解説したセッションを紹介
- CI/CD ConferenceからサイバーエージェントのCI/CDツール開発のセッションを紹介
- CI/CD Conference 2023から、HashiCorpのエンジニアがCI/CDにおけるシークレット管理のコツを解説
- CI/CD ConferenceからAWSのアドボケイトによる「単一コードベース」を勧めるセッションを紹介
- CI/CD Conference 2023から、Kubernetesの構成をテストする事例を解説したセッションを紹介
- Observability Conference 2022、TVerによるNew Relic One導入事例を紹介
- CNDT 2022、ArgoCDとGitHub Actionsの導入でリリース時間を1/4に削減した事例を紹介
- CI/CD Conference 2023から、アルファドライブ/ニューズピックスのSREがAWS CDKを活用したCI/CD改善を解説
- Intelが主導する新しいAIフレームワーク、BigDLとは?
- CNSC 2022、日立のエンジニアがNISTの仕様をベースにIstioのセキュアな設定を解説