CI/CD ConferenceからAWSのアドボケイトによる「単一コードベース」を勧めるセッションを紹介

CI/CD Conference 2021から、AWSのシニアデベロッパーアドボケイトであるTori Hara氏によるセッションを紹介する。このセッションではCI/CDを実施する際に見落とされているソースコードの持ち方について、PaaSのオリジンであるHerokuの共同創始者であるAdam Wigginsが提唱した「12ファクターアプリケーション」の原則と現実の姿を照らし合わせて解説を行うもので、タイトルは「複数ブランチ運用は『単一コードベース』と言えるのか」である。

CI/CDのカンファレンスで、12ファクターアプリの原則を使ってソースコードの保持の仕方、そのコードベースからアプリケーションを開発環境や本番環境に配備（デプロイ）する際のポイントを解説している。CI/CDそのものではなく、CI/CDを本来の目的に即したモノにするための背景として、ブランチを複数持たずに単一のコードベースから各ステージング環境に配備することを解説しているのはユニークだろう。

セッションを行うTori氏

ちなみにここではTori氏というニックネームを使って紹介を行っていく。最初に、複数のデベロッパーがチャットを使って議論を行う例を挙げて説明を開始した。

チャットで「田中さんがマージしたコードがエラーを出して」から始まるホラーストーリー

ここではリリースと命名されたソースコードのブランチにマージされた田中さんのコードが、本番環境でエラーを出しているという設定だ。

意図したものと違うコードがマージされているがロールバックは……

新しいコードはデータを上書きしてしまう仕様になっていて、ロールバックを簡単に行えないという悪夢のような事態を紹介する。ここからソースコードを単一のブランチで持たずに、複数のブランチでそれぞれのステージごとにブランチが存在する際の背景を解説するスライドに移った。

複数のソースコードブランチを持つ理由は？

開発グループ内のある開発プロジェクトにおいて複数のソースコードを持つ背景として、緊急のバグ修正のために臨時にソースコードを分岐する場合、また機能開発のために分岐する必要があることを解説したが、Tori氏が問題視しているのはそのような緊急のバグ修正のためではなく、永続的に複数のソースブランチが存在する場合である。

ここではMain、Dev、Releaseなどの名称でソースコードが一元的に管理されるのではなく、複数のコードベースとして存在する場合を指している。

Tori氏はアプリケーションを開発する際に守るべき特性として12の要因をまとめた12ファクターアプリケーションについては特に説明せずに「Webの上で稼働するアプリケーション開発を行うなら当然知っているべきだし、守るべきルール」として自明のモノとして扱っているように思える。しかし、ここでは日本語による12ファクターアプリケーションの簡単な解説は必要だったかもしれない。

12ファクターアプリケーションの解説：The Twelve-Factor App（日本語訳）

この文章は「SaaSを作り上げるための方法論」として書かれているが、そもそも解説として「アプリケーション開発における理想的なプラクティスを見出すための三角測量である。特に、アプリケーションが時間と共に有機的に成長する力学、アプリケーションのコードベースに取り組む開発者間のコラボレーションの力学、そしてソフトウェア腐敗によるコストの回避に注目している」という非常に抽象的で難解な文章である。そのため、レガシーなアプリケーション開発しか行ってこなかった組織においては、12ファクターを守ることによって得られる効果が見えないということも理解しておくべきだろう。

抽象的な12ファクターアプリケーションのページの内容をわかりやすく言い換えるなら、デベロッパーが新しく開発チームに加わった時の立ち上がりを加速する、移植性を増やす、開発環境と本番環境の違いを最小化することでコードの変更を素早く行えるようにする、システムの規模を要求に従って増減することが可能になる、と言ったところだろうか。

しかし本番環境がオンプレミスだけで、移植も規模の拡大も予定にないようなレガシーなシステムの場合はピンと来ないというのは本音だろう。システム自体がクラウドネイティブを指向するような状況になって初めて「真剣にアプリケーション開発からリリース、実装を考えないといけない」ことになるのだろう。

言ってみれば各支店からのアクセスしか想定していなかった銀行の基幹システムが、インターネットバンキングに向けてスマートフォンやWebからのアクセスを考慮してシステムのあり方をゼロベースで考えるような状況になって、初めて、このルールの意味が理解されるということではないだろうか。

その立ち位置に立って初めて「これまでやっていたソフトウェア開発のソースコードの理想的な姿」を想定したうえで、次のスライドにある「なぜ複数の永続的なブランチが必要なのか？」を考えるべきだろう。

複数の永続的ソースコードブランチが必要になる背景とは？

ここで挙げられている例はレガシーなアプリケーション開発であれば良くある状況だし、その状況であれば特に問題はなかったのかもしれない。しかしそれで「スマートフォンを使ったインターネットバンキングのアプリケーションは作れますか？ ユーザーのニーズを満足できますか？」という問いを考えて欲しい。その上でTori氏が解説する12ファクターアプリケーションの最初のルール、「1つのコードベースと複数のデプロイ」についての解説に戻るべきだろう。

単一のコードベースと複数のデプロイを守ることが最初のルール

開発とステージング用と本番環境用のコードベースが分離されている例を挙げて「これが複数の永続的なコードベース」の実例であるとして、このような開発スタイルは止めるべきだと説明した。

複数のコードベースを使うスタイルは止めるべき

そしてどうして複数の永続的コードベースを止めるべきか？ について、12ファクターアプリケーションが1対N（1つのコードベースから複数のデプロイメントを行うこと）を推奨していることを説明した。

1つのコードベースから複数のデプロイメントを行う意味を解説

ここでのポイントは、開発環境と本番環境の違いを最小限にすることを前提として、それによって実行環境の移植性が高くなること、継続的デプロイメントによって小さな変更をすぐに反映することができる、つまりアジリティを高められることだ。また、手動オペレーションをなくせることと自動化も達成できることを効果として挙げている。

CI/CD Conferenceの別のセッションで、トレジャーデータの国分崇志氏が「継続的なソフトウェアデリバリを行う意味はリリースのリスクを最小化することである」というプレゼンテーションを行ったが、AWSのTori氏はあくまでもベンダーの視点からか、そこまでは踏み込まずにアプリケーションの移植性を最初に挙げていることは興味深い。

参考：CI/CD Conferenceレポート トレジャーデータのCI/CDのポイントはリリースリスクの最小化

またどうしても永続的な複数のコードベースが残ってしまう理由について、ヒアリングした内容を元に例を挙げて説明した。ここでは本当にその理由でコードベースを1つにまとめられないのですか？ と問うことで、できない理由を自問して欲しいという意図が見える。

複数のコードベースを続ける理由を再考して欲しいと訴える

そしてコンテナをベースにしたアプリケーションのデリバリの概要を示し、このスタイルでコンテナベースのアプリケーションがCI/CDされることを前提として解説した。そして、この後のどうしても開発環境だけに別のアプリケーションイメージが存在してしまう例外的なパターンの解説に移った。

コンテナベースアプリケーションの開発からデプロイまでの流れ

このフローはかなり簡略化されているが、デベロッパーがソースコードを書いてビルド～テストを経て実行イメージのアーティファクトリーに保存されたアプリケーションのイメージが複数の環境にデプロイされて行く流れを示している。これは、1ソースから複数の環境にデプロイされる理想的な姿である。

CIとCDの観点から理想的な流れを説明

しかしある特定の環境にのみ設定を変えたい場合があることも認識している。

開発環境にだけ機能を追加したい場合はよくある

例としてTori氏は、開発環境にだけ特別の設定をしたい場合があるケースを紹介した。このためにベースのソースコード自体は変更せずに任意のライブラリーなどを追加する形で対応できるという方法を解説した。

再度、どうしても複数の永続的コードベースを維持しなければいけない理由についてその回避方法を見せながら、デベロッパー、運用担当者に対して単一のコードベースに移行することを促した。

単一のコードベースに出来ない理由を再考して欲しいと訴えた

リリースのタイミングをコントロールしたい、リリースできる担当者を絞りたい、環境ごとに異なる設定を維持したい、などなど多くのデベロッパー、運用担当者が頷きそうな理由を挙げながら、それを変えるアイデアを提案するTori氏だが、多くのデベロッパーから相談を持ちかけられている姿が目に浮かんでくるようだ。

最後にまとめとして、12ファクターアプリケーションの最初に書かれているルール、コードベースの利点を例に挙げ、改善方法を挙げて説明を行った。12ファクターアプリケーションについては日本語訳を読むことをお勧めするが、すでにその更新版である「Beyond the twelve factor app」がVMwareから発表されている。

12ファクターアプリのコードベースの部分：I.コードベース

VMwareはPivotalを吸収して独自のブランド「VMware Tanzu」として展開しているが、これもそのブランディングの一部と言えるだろう。

Beyond the Twelve-Factor App

この更新版では「API First」がコードベースの次に追加されており、アプリケーションを分散化して疎結合にするための発想としてAPIに注目していることは特記すべきだろう。

これは、CNCFのWebinarでFireHydrantのCEO、Robert Ross氏が「アプリはAPIを作るところから始めるべきだ」と訴えていたこととも同期する内容だ。

Tori氏のセッションは、12ファクターアプリケーションの解説や背景などについては割愛していたために、それを知らないデベロッパー、運用担当者にとってはややとっつきにくかったかもしれない。しかし、実際のデベロッパーが考えているであろう「言い訳」に対してちゃんと具体的な回答を用意していたことは評価したい。