資材管理と切り戻しについて考える

それって本当に切り戻してる？

DevOps の普及により CI/CD パイプラインは当たり前の様に整備されてきています。
よくあるパイプラインとしては下図の様なイメージではないでしょうか。

コードをマージしたら環境に自動的にデプロイされる
という非常に便利な仕組みを手に入れた訳ですが、デプロイを伴う商用リリース作業は、時に失敗することがあります。

そして失敗した場合は「切り戻し」作業を行うことがほとんどでしょう。

この時、本当に正しく「切り戻させている」のでしょうか？その点について記載してみようと思います。

前にしか進めないパイプライン

私が従事したいくつかの PJ で最初に構築されていたデプロイ用のパイプラインは「前にしか進めない」パイプラインでした。
つまり、新しいマージをきっかけに動作するパイプラインということです。過去のコミットはデプロイできません。

しかし開発チームはその様な状態でも「切り戻し可能」なパイプラインとして運用していました。

要は切り戻しが必要となった場合、マージしたコミットをリバートし、それをマージすることでパイプラインを動かしていた訳です。

つまり、ソースコード的には「切り戻し」てはいますが、デプロイされる資材としては「中身は切り戻っているけど、新しいもの」である状態です。

果たして、これは本当に「切り戻し」ているのでしょうか？

ビルド番号と資材管理

上記の方式を「正しい切り戻しだ！」と考える人はそれで良いと思いますが、私はより安全な切り戻しを実現するために、「前にしか進めない」パイプラインを「好きなビルドをデプロイできる」パイプラインに改善しました。

そこで重要となるのが「ビルド番号」です。

ビルド番号の定義は何でも良いと思いますが、例えば 1.0.0.1234 や 1.0.0-build1234 とかでしょうか。または日付を付与するパターンもあるかと思います。
重要なのは、「この資材とあの資材、どっちが新しいの？」をすぐに判別できることが望ましいでしょう。
（そのため Git のコミット番号を利用する派の方々には申し訳ないですが、それには反対しています）

CI パイプラインでソースコードをビルドし、何らかのファイル、イメージなどを生成すると思います。これらをアーティファクトと呼びます。
その時、このアーティファクトにビルド番号を付与します。
jar であれば sample-api.1.0.0.1234.jar などでしょうか。

そしてこのアーティファクトを「ビルド番号ごと」に保存します。
jar であれば Sonatype Nexus などで Maven リポジトリを利用しても良いでしょうし、Docker イメージであればバージョン番号としてビルド番号を付与することができると思います。

こうすることで、CI パイプラインによりビルドされた資材は、まるで本棚に時系列的に整理整頓された様に格納できる様になった訳です。

好きなビルドをデプロイ

ここまで来れば、あとは CD パイプラインを拡張し、好きなビルドをデプロイ可能にすれば良いのです。
実際の方法としては、GitOps などの技術が利用できると思います。k8s の場合は ArgoCD など利用すれば良いでしょうし、もう少し大きな単位(VMイメージなど)で資材を管理している場合は、AWS なら CloudFormation などが利用できると思います。

いずれにせよ、本棚から好きなビルドを取り出してデプロイする様な状態になれば完璧と思います。

本当の切り戻しの実現

好きなビルドをデプロイできる様になったので、切り戻し方式も変わってきます。
今までの様にソースコードをリバートする必要はなく、既に存在するアーティファクト一覧の中から、切り戻すべきビルド番号を指定してデプロイすれば良いのです。

これで確かに「以前の状態に戻った＝切り戻した」と胸を張って言える状態になったのではないでしょうか。

補足:本当の CD について

DevOps に関連するワードとして CI と CD がありますが、CD は２つの意味が混在しているケースがあります。

• Continuous Deploy（継続的デプロイ）
• Continuous Delivery（継続的デリバリー）

細かい違いは割愛しますが、Continuous Delivery(継続的デリバリー) とは、顧客に継続的に価値をデリバリーすることです。
そして重要なのが、このContinuous Deliveryをコントロールするのは「開発担当者」ではなく「ビジネス担当者」であるべきということです。

新たなフィーチャーをどのタイミングで提供すべきかを見極められるのはビジネス担当者なので、ビジネス担当者が「特定のビルドをいつでも簡単にデリバリーできる」状態が、真の Continuous Delivery です。

しかし、実際にボタンクリックの様な簡単な操作でアプリケーションやシステムをデプロイするまでの道のりは長いと思います。
ただ、それが可能になったらサービスの価値は継続的に上昇し続けると思いますので、まずは「ビルド番号による資材管理」から始めてみてはいかがでしょうか。