フラグガバナンスと日々の管理を自動化する「フラグパイプライン」を発表

Harnessは、フィーチャーフラグのガバナンスと日々の管理を自動化する新しいコンセプト、Flag Pipelinesを発表し、パイプラインの使い方を拡張しています。

Harness Feature Flagsをリリースしたとき、私たちはHarnessプラットフォームの他の機能を活用し、その総和以上の価値を生み出すチャンスに興奮していました。最初に行ったことのひとつは、Feature Flagsにフィーチャーリリースパイプラインのサポートを追加し、リリースワークフローとポリシー施行の自動化を可能にしたことです。

今日、私たちは新しいコンセプトであるFlag Pipelinesを発表し、パイプラインの使用方法を拡張しています。パイプラインは、フィーチャーフラグを使ったリリースのための強力なワークフローと自動化を常に構築できます。また、フラグが変更されるたびにパイプラインを自動的に実行し、ガバナンスと管理を強化できるようになりました。フラグには、フラグの変更のたびに実行される個別のパイプラインを含むことができるのです。これは、フラグの日々の使用を自動化し、全ての変更が組織の標準に適合していることを確認する上で画期的なことです。

基本的に、フラグの状態が変更されるたびに、事前に定義されたワークフローを通過することが保証できるようになりました。これは、取り扱い注意の機能がトグルされるたびに承認を必要とするような、単純なものであってもかまいません。あるいは、承認を必要とし、JiraとServiceNowに更新を行い、カスタマーサポートと管理者に通知を送るというような、より複雑なものも可能です。

日常的なフラグのライフサイクルにおけるガバナンス

フラグパイプラインは、簡単なパイプラインを構築して、それをフラグに割り当てることができます。その時点から、フラグが変更されるたびに、どのように変更されても、そのパイプラインは自動的に実行されます。つまり、UIやAPIでフラグを変更しても、GitでYAMLを更新しても、このパイプラインが実行されるのです。

これは、あなたのチームが次のようなことをしたいときにピッタリです。

• 本番環境でフラグを変更する際、マネージャーやPMの承認が必要なとき
• フラグを変更するたびにSlackメッセージを送信するとき
• 機能開発のステップを追跡するために使用されているJiraチケットを更新するとき
• フラグが変更されるたびに、そのフラグに関連するカスタムスクリプトを実行するとき

フィーチャーフラグを見落とす手動プロセス

通常、フィーチャーフラグを持つパイプラインを使用して、23時間ごとに承認済みのオーディエンスの10%にフラグをインクリメントするなど、自動リリースワークフローを構築できます。１回限りのリリースや特別にモデル化されたリリースのシナリオでも、引き続きそれが可能です。フラグパイプラインは、特定の１回限りのシナリオがあるときだけでなく、毎回発生させたいことを自動化し、実施できます。

この機能強化により、チームや幅広い組織で、フィーチャーフラグをどのように処理し、日々管理するかについて、より幅広いレベルで制御できるようになります。以前は、フラグを変更する必要があるたびに、全てのユーザーが指定されたパイプラインを実行するような組織的なプロセスを作成する必要がありました。これには、いくつかの問題があります。

1. 各トグルに個別のパイプラインを作成する必要がある
2. フラグトグルの代わりにパイプラインを使用するよう、全員がトレーニングを受ける必要がある
3. UIの半分が使用できないため、ユーザーエクスペリエンスが混乱する
4. ユーザーが手動またはコードでフラグトグルを変更し、パイプラインをバイパスできてしまう

チームがこれらのことを正しい方法で行おうとしない、ということではありません。物事がずれたり、人やプロセスが変わったり、単純であるべきことに多数の余分な手順を踏むのは不便なことなのです。その代わり、ユーザーが実際のニーズにもっと近い方法でフラグを使うことができ、フラグの変更のためのリリースプロセスが自動的に行われるとしたらどうでしょう？スクリプトを反転させることで、開発者はスピードを落とさず、ビジネスも毎回正しい方法で行われるようになります。

フィーチャーフラグパイプラインの使用方法
 

フラグパイプラインを設定するには、任意のフラグを選択し、新しい「Flag Pipelines」タブを選択するだけです。そこから、使用するパイプラインを選択または作成できます。

フラグパイプラインは、毎回実行したいワークフローのサブセットのためにあるため、全てのパイプラインをフラグパイプラインとして使用できるわけではありません。フラグパイプラインは必ず：

• 継続的インテグレーション／継続的デリバリー（CI/CD）のステップを持たない
• フラグの変更は1回のみで、複数回の変更は不可
• フラグステップに実行時入力を設定する 

適切なパイプラインを用意し、フラグ内のFlag Pipelines設定でそれを選択すれば、準備は完了です。これで、フラグが変更されるたびに、そのパイプラインが自動的に実行されるようになります。

この仕組みの詳細はHarnessのドキュメントをご覧ください。

Harness Feature Flagsを使い始める

Flag Pipelinesは、フィーチャーフラグをソフトウェア配信プロセスの中核とすることを追求し続けます。フィーチャーフラグをより高度に制御できるようにすることで、ガバナンスを強化し、フィーチャーフラグの自動化を実現します。これは、フィーチャーフラグをソフトウェア配信の重要なビジネスプロセスに進化させるための大きな一歩です。

さあ、はじめましょう。デモをリクエストするか、永久無料にサインアップしてください。今後もこのストーリーを展開していきますので、どのように進化させたいか、ぜひご意見をお聞かせください。

それでは、素敵な開発を！

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