フィーチャーフラグでCI/CDをネイティブに統合する理由

CI/CDとフィーチャーフラッグ。私たちは過去に、なぜこの2つを組み合わせることが理にかなっているのかを書きました。ここでは、ネイティブの統合についてより深く見ていきます。

私たちHarnessは、CI/CDとFeature Flagsを一緒に持つことの価値について、よく話しています。というのも、私たちの目標は、Harnessのすべてのモジュールで、（その分野の競合他社に対して）単独で販売できるほど優れた製品を構築することだからです。

私たちは、単にバンドルするだけでなく、市場でベストとなるようにツールを構築します。しかし、共通のプラットフォーム上でツールを構築する場合、モジュールを一緒に使うことで最大限の効果を発揮する方法を常に探しています。フィーチャーフラグとCI/CDがネイティブに統合されたときのインパクトは、私たちが予想していたよりも大きく、やや異なるものでした。

はじめに 1本のパイプライン 

私たちがこの問題に取り組み始めたとき、ソフトウェアリリース全体を単一の統合パイプラインでエンドツーエンドにモデル化することが、CI/CDとFeature Flagsを一緒に使うキラーアプリケーションになるかもしれないという仮説がありました。

しかし、CI/CDとFeature Flagsを一緒にパイプラインに組み込むことは、企業にとって意味のあることですが、日常的な使用例ではないということがわかりました（詳細は後述します）。ほとんどのフラグ、そしてほとんどのデプロイメントにおいて、ユーザーは別々のパイプラインにすることを望んでいました。

このことは、私たちの理論が無価値であることを意味するものではありませんが、この理論が理にかなっている場合もありますし、この機能があることは素晴らしいことです。

面白いのは、この時点でHarness Feature Flagsについて積極的に顧客に話をし、社内でもCI/CDで使っていたので、一緒に使うのが良いということが分かっていたことです。私たちは、無理やり価値を実現しようと漁夫の利を狙ったわけではありません。ただ、なぜ、どのような場合に併用するのが良いのか、それを理解する必要があったのです。

フィーチャーフラグとCI/CDの組み合わせが理にかなっている理由 

理由1：UXの標準化

多くの場合、機能フラグのロールアウトとデプロイメントが同じパイプラインを共有することはないかもしれません。しかし、同じUX、同じ用語、同じオプションでこれらの動作を構築することは、CI/CDとフィーチャーフラグの両方において、管理、理解、チームメートの増強が容易になるという累積効果をもたらします。
 

上記の2つのシンプルなパイプラインの例を見てみましょう。1つはデプロイメントで、もう1つは機能フラグを使用して機能をロールアウトするものです。

理由2：チームとアクセスの管理に費やす時間を短縮できる

プロダクションに関わるすべてのシステムはリスクであり、すべての開発ツールは従業員のオンボーディングとオフボーディングの要件となります。本番環境へのアクセス、RBAC、チーム構成、プロジェクト構成、そして監査、ガバナンスルールの適用、監視などを管理することは、高いスキルを持つ人が雑務に追われ、時間的にも大きなコストがかかるだけでなく、何かを見落とす可能性もあります。実際、私たちは6ヶ月前の元社員がまだツールにアクセスできるような場所で働いたことがあります。

環境、チーム、プロジェクトなどの主要なコンフィグを共有することで、設定量、人の管理、リスクの機会など、一つのプラットフォームで計上することで大幅に改善されるのです。HarnessのProdは、CI/CD/FFにまたがっています。権限レベルを決めてチームに人を追加すれば、すべてのモジュールに適用できる。何度もやり直す必要はないのです。

理由3：何が起きているのか把握するため

昨日、prodで何が起こったのか？ほとんどのツールチェーンで、この情報を見つけるには、3つか4つのタブと、いくつかのデータエクスポートが必要です。同じ人がそのすべてにアクセスできるかもしれませんし、そうでないかもしれません。願わくば、ギャップがなく、異なるチーム間でデータがサイロ化されていないことを望みます。

Harnessでは、CI、CD、Feature Flagsの各ダッシュボードと、環境内のすべてのアクティビティに関する監査ログが統合されています。つまり、いつ、何が起こったのかを簡単に知ることができるのです。複数のツールにまたがって、データを調べたり、時系列やストーリーを結びつけたりする必要はもうないのです。

私たちの経験では、運用チーム、エンジニアリング管理者、カスタマーサポートチームは、これによって非常に気分が良くなります。通常、故障は継ぎ目で発生しますが、Harnessには継ぎ目がありません。例えば、運用チームは、機能フラグで制御された新しい設定を含むデプロイがいつ終了するか、どの環境で有効になっているか、誰がアクセスしているかなどを、すべて一つのプラットフォームから簡単に確認することができるのです。

理由4：パイプラインの統合（合理的な場合のみ）

CI/CDとFeature Flagsの活動を1つのパイプラインにまとめることは、常に意味があるわけではないと書きましたが、正しい文脈では、これは絶対的な天の恵みとなり得ます。

日々の小さな変更のデプロイは、おそらくこのような複合パイプラインに最適ではないでしょう。しかし、より重要で協調的な変更を行う場合もあります。例えば、デプロイの一環として大量のユーザーデータを新しいサブシステムに移行し、デプロイ後に新しいサブシステム上のユーザーを地域別にランプしたいとします。

このような場合、複合パイプラインは、この複雑なタスクを達成するための最もシンプルで、最も管理しやすく、観察可能な方法です。
 

機能フラグステージがシームレスに統合されたCI/CDパイプライン。

典型的でない調整を必要とする機能、慎重に計画されたトラフィックランプ、デプロイ後の観察窓など、より慎重で特注のリリースシナリオに最適な使用方法だと考えてください。

おそらく、すべてのデプロイメントでこれが必要になるわけではありませんが、必要なときには、ゲームチェンジャーであることに疑いの余地はありません。さらに、これらのパイプラインはグローバルに管理することができ、「過去5分間にデプロイが失敗した場合はプロッドフラグの変更を許可しない」といったポリシーを設定することができ、ツールチェーン全体を安全かつコンプライアンスに準拠したものにすることができます。

もう一度、繰り返そう。意味があるとき

CI/CDとFeature Flagsのネイティブな統合は、私たちHarnessにとって発見の旅となりました。その結果、ユニークなエンドツーエンドのパイプラインと同様に、認識負荷、組織管理、ガバナンスの改善、リスクの低減などのメリットがあることがわかりました。

パイプラインを一緒に構築する能力は、適切な状況で大きな影響を与えますが、これらのツールを一緒に持つことで、日常的な価値を得ることができるのです。

Feature Flagsを試して、これらのクールな機能で遊んでみたいですか？今すぐ無料トライアルにお申し込みください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。