本番環境に制御と速度を：CI/CDとフィーチャーフラグの併用

CI/CDとフィーチャーフラグは、バットマンとロビンのような関係です。単独でも強く、力を合わせれば向かうところ敵なしです。統合パイプラインの価値について見ていきましょう。

ソフトウェアをより速くより安全に提供する必要性は、当然の帰結です。エンジニアリングチームは、以前より速くソフトウェアを提供し、かつシステムにそれ以上のリスクをもたらさないよう常に努めています。

この進化の一環として、ソフトウェアデリバリーパイプラインが生まれました。特にCI/CDが有名です。しかし、チームがCI/CDの境界を押し広げるにつれて、プロセスの最後尾で新たな問題に遭遇することが分かってきました。古典的ですね。

このブログ記事では、この問題の最後尾であるデプロイメントについて探っていきます。フィーチャーフラグがどこに関係するかも見ていきましょう。

なぜソフトウェアデリバリーパイプラインなのか

パイプライン、プロセス、ライフサイクルなど、呼び方はさまざまですが、その考え方は同じです。常に変化と新機能が開発され、それらがお客様の手に渡る必要があります。

特に規模が大きくなると、ソフトウェアを提供するための標準的な方法、つまりパイプラインが必要になります。パイプラインは、あなたが出荷するものが一貫して合格することを保証し、またリスク（もちろん、手直しや障害シミュレーションの可能性）を最小限に抑えることができます。

より速く、より安全にソフトウェアを提供することが、チームがCI/CDを採用する理由です。そして今、チームはそのソフトウェアデリバリーパイプラインをさらに拡張するために、フィーチャーフラグも採用しつつあります。CIの最終結果であるアーティファクトがCDパイプラインで消費されるのと同じように、CDの最終結果であるデプロイは、次の段階に進むためにフィーチャーフラグシステムで消費されるのです。

しかし、なぜチームはフィーチャーフラグを採用する必要があるのでしょうか。コードが本番環境にデプロイされた後で良いのではないでしょうか。その通り！そこで問題になるのが、本番環境に移った後のことです。

CDの限界

まずは、当たり前の話から始めましょう。CDは、コードが本番環境にデプロイされた時点で終了します。デプロイメントが稼動した後にできる制御は、デプロイメント全体をロールバックすることに限定されます。デプロイの中身を制御することはできませんし、単一障害点を解決するにもデプロイメント全体を本番環境から引き離さなければなりません。大事なことなのでもう一度言います。本番環境に移行した瞬間に制御不能になるのです。本番稼働後に何か起きてしまったらと思うだけでひやっとしますね。
 

デプロイ後は無事でありますように。

しかし、現実には、多くのチームが日々このような状況に置かれています。本番環境に移行する前のスピードと制御は必要ですが、本番環境に移行した後の制御は限定的です。このため、デプロイメントの前後で興味深い問題が発生することがあります。

しかし、現実には、多くのチームが日々このような状況に置かれています。本番環境に移行する前のスピードと制御は必要ですが、本番環境に移行した後の制御は限定的です。このため、デプロイメントの前後で興味深い問題が発生することがあります。

導入前

• デプロイメントが大きくなり、リスクが増大し、デプロイプロセスに時間がかかり、ストレスが増す。
• デプロイメントが個々の変更によってボトルネックになり、準備が整わない。
• アプリの設定、DBフラグ、環境変数などを構築し、特定のユーザーセットへのリリース制御を可能にする必要がある。
• 顧客によって明確に異なる機能セットの要求に対して、複数の「バージョン」または長期間のソースコントロールブランチが存在する。

ここで重要なのは、このようなことがすべて終わった後でも、配備は信じられないほどストレスの多いものであり、ゴーサインを出すのは、映画で大きな赤いボタンを押すのと同じくらい劇的なことなのです。ここで最も重要なことは、何か問題が発生した場合、総出で対応しなければならないことです。これはDevOpsにとってストレスになるだけでなく、開発チームが手直しをしなければならないため、新機能の開発速度が遅くなります。

それ以上に、顧客プロファイル（無料ユーザーと有料ユーザーなど）に基づいた複数のエクスペリエンスを作成することは負担が大きく、常に期待通りに動作するとは限りません。しかし、その制御はデプロイ後、エンジニアリングチームだけでなく、プロダクト、セールス、カスタマーサクセスのチームにも必要なのです。

展開後

• 50の変更をデプロイし、１つだけ問題がある場合、デプロイ全体をロールバックする必要がある。
• どの顧客が特定の機能にアクセスできるかを制御するのが面倒。通常、エンジニアリングチームが手動で行う必要がある。
• 特定の変更または新機能が期待値と比較してどのように機能しているかを理解するためにデータを使用するのは困難。
• 実世界のデータはしばしばある種の予期せぬ動作を引き起こし、手直しや、最悪の場合、デプロイメント全体のロールバックが必要になる。

最善を尽くしているつもりでも、本番環境では本当にひどい状態になってしまうことがよくあります。不便なカスタマーエクスペリエンスコントロールはしばしば壊れ、長期間の機能ブランチは奇妙なマージ問題を引き起こし、もし何かが壊れたら…ストレスと怒りを抱えたエンジニアのみなさん、よろしくお願いします。本番環境で何が起こるべきかは分かっていても、制御して本来の目標を達成することは非常に困難です。本番環境で制御可能かつこれらの障害をすべて取り除けるような適切なシステムを構築できなければ。

フィーチャーフラグの役割

CDの限界を解決するために必要なのは、フィーチャーフラグ管理システムだと言っても驚かれないでしょう。そして、それは理にかなっていると思いませんか？チームは既に、今あるツールでFeature Flagsを実装しようとしているのです。

フィーチャーフラグ＋CD＝ソフトウェアデリバリーの速度と制御

デプロイ後に制御できないのは恐ろしいことであり、リスクでもあります。開発者のストレスレベルが上がるだけでなく、本番環境で制御できないことは、特に何か問題が発生したときに、ビジネスへの具体的な影響が出ます！そして、これがフィーチャフラグの最初の役割です。

本番環境での制御

フィーチャーフラグシステムを導入している場合は、すぐに多くの価値を実感できます。 新しい変更や機能がデプロイされた後、それらの制御を失うことがないことを知っていることは、開発チームとDevOpsチームにとって大きな意味があります。 フィーチャーフラグを使用して本番環境で制御できるようにすることの利点をリストにしてみます。

• 防御の第一線となる。何か問題が発生しても、本番環境では機能レベルで対処することができます。もう、１つの機能の不具合で、モノリシックなデプロイメントをロールバックする必要はありません。これは、機能ごとに簡単にアクセスできるキルスイッチを作るようなものだと考えてください。このブログでは、このトピックについてより深く掘り下げています。
• 顧客の機能アクセス制御を簡素化する。実行時の設定の代わりに、どのユーザーが個々の機能にアクセスできるかをきめ細かく定義することができるのです。例えば、ベータ版とGA版、有料ユーザーと無料ユーザーといった使い分けができます。
• デプロイメントとリリースを切り離す。デプロイは、すべてのユーザーがデプロイのすべてにすぐにアクセスできることを意味する必要はありません。しかし、CDだけでは、そうなりがちです。フィーチャーフラグを使用すると、すべてをオフの状態でデプロイし、その機能をいつ顧客に提供するか、そして誰がそれにアクセスできるかを選択することができます。
• 非技術系チームに権限を与え、エンジニアリングの負担を軽減する。フィーチャーフラグがない世界では、残念ながらエンジニアが顧客ニーズのボトルネックとなり、機能や権限を手動でオン／オフする必要があります。本番稼動後は、フィーチャーフラグによって顧客対応チームにコントロールを委ね、彼らが顧客体験を管理できるようにし、エンジニアは本業に戻ることができます。
• 実稼働中のテストコード。プレプロダクションの環境では、多くのテストしかできません。実際のデータが流れ込んでくれば、ソリューションの良し悪しがわかるのです。フィーチャーフラグを使えば、複数のソリューションの実装（または１つだけでも）を特定のユーザー集団に展開し、顧客の問題を最もよく解決するのはどれか、あるいはその機能がゴールデンタイムに使えるかどうかを確認することができます。このブログでは、このトピックについてより深く掘り下げています。

ソフトウェアデリバリーにおける速度

一方、フィーチャーフラグは、ソフトウェアデリバリープロセスの速度を向上させることができます。まず、CDは速度を向上させますが、デプロイメントが大きくなるにつれ、１）リスクが増える、２）完成させる必要のある機能／変更が増える、という理由から、収穫が少なくなる傾向があることを思い出してください。では、フィーチャーフラグにはどのような効果があるのでしょうか。

• リリースせずに展開する。フラグを立てることで未完成のコードを本番環境に投入し、全ユーザーにロールアウトする前に小規模なユーザー集団で機能をテストすることができます。フラグを立てさえすれば、デプロイメントを計画通り、予定通りに実行することができます。
• 小さな塊でデプロイする。これは一見直感に反するように思えますが、よく考えてみると、より頻繁に、より小さな塊でデプロイすることで、より速く、より少ないリスク集中でデリバリーできるのではないでしょうか。フィーチャーフラグを使えば、準備が整ったものから出荷することができ、最終的にはエンジニアが自分のペース（最も遅いリリースや最も大きいリリースのペースではなく）で動けるようになります。
• エンジニアリングのボトルネックを解消する。フィーチャーフラグは、これまで顧客のために手作業で変更していたエンジニアリングの帯域を解放します。顧客にとっては、要望をより早く解決し、新機能をより早く手に入れることができる、二重の喜びです。
• フィードバック、フィードバック、フィードバック。ユーザーにとって最適なソリューションを構築できたかどうか、どうすればわかるのでしょうか。答えは常にフィードバックです。しかし、どうすればより多くのフィードバックを、より早く得られるのでしょうか？３カ月のプロセスを１カ月にすることは可能でしょうか？フィーチャーフラグを使用することで、チームはより良い方法でこれを開始することができるようになります。フィードバックポイントを増やすとプロセスが遅くなるように思われるかもしれませんが、実際には速くなることが分かっています。

CDフラグとフィーチャーフラグを分けるのは無意味

フィーチャーフラグはCDにとって、CIにとってのCDのような関係性です。CI/CDではなく、CI/CD/FFとなるのは自然な流れです。CIを適切に行うにはCDが必要であり、CDを適切に行うにはFFが必要なのです。実際、CDとFFを一緒にやらない理由は何でしょうか？

バットマンとロビンのように、この２つの組み合わせこそが、ソフトウェアデリバリーの速度と制御という目標にふさわしいものなのです。CDは可能な限り速く出荷することですが、その速度は、出荷する製品の信頼性と品質によって制限されます。

フィーチャーフラグは、一貫して出荷を安全にすることでこの上限をなくし、エンジニアはソフトウェアデリバリーのストレスではなく、最も重要なことに集中できるようにします。

実際、フィーチャーフラグを使用したチームは、DORAの指標においてCDのみを使用したチームよりも常に高いパフォーマンスを示しています。

• 展開頻度が80%増加
• コミットからデプロイまでの時間を66％短縮
• 90％のインシデントが１日以内に解決

チームは、真の速度と真の制御を求め、途中で行き詰まることを望んでいません。リスクとストレスを最小化し、新機能の質と量を最大化したいのです。フィーチャーフラグやCDは、それ自体でチームをそのビジョンに近づけるものですが、バットマンとロビンが一緒に働くことによって、この未来が本当に実現されるのです。

Harnessによる真の継続的デリバリー

しかし、ほとんどのフィーチャーフラグを実装すると、CDとの接続が切れ、不必要なリスクが発生し、管理と可視性が断片化されます - これは、ミッションクリティカルなシステムにとって望ましいものではありません。また、メトリクス、監査ログ、ガバナンス、セキュリティの面でも問題があります。

そこで、Harnessの出番です。Harness CDとHarness Feature Flagsは、あらゆる形態の継続的デリバリーを完成させるために必要な、企業共通の要件を満たします。もちろん、両方を導入する必要はありません。しかし、バットマンとロビンが一緒にいることは、完璧な意味を持ちます。

最終的な感想

この時点で、CDとフィーチャーフラグを独立させておくことの大まかな意味と、なぜそうすることに意味がないのかについて、かなり理解できたと思われます。はっきり言って、CDとフィーチャーフラグを一緒に使うことを考えなければ、CDやフィーチャーフラグソリューションの価値を十分に発揮できないことになります。そして実際、どちらか一方を使用して、もう一方を使用しないのは、より多くの頭痛の種を作り出していることになるでしょう。

Harnessは、CDやフィーチャーフラグなどの製品を揃え、ソフトウェアデリバリーライフサイクルの各段階でお客様に対応します。私たちのビジネスを確認したい場合は、永久無料のサインアップをするか、正式なデモをご依頼ください。

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