開発に統合された機能が管理者によって延期された場合はどうなりますか？
最近、私たちのwebapp（自動サインアップ）の機能が「冷たすぎ」であると感じたため、管理者によって延期されるという問題がありましたが、彼らは私たちが取り組んでいた他のすべての機能を稼働させることを望んでいました。
問題は、この機能が終了時に開発にマージされ、次のリリースでライブ配信する予定であった他のすべての機能と一緒になっていたため、通常のようにdev-> test-> masterをマージできなかったことです。
この問題をどのように回避できましたか？
1つのアプローチは、フラグを立てる機能です。これはコードベースで実行できますが、構成によって無効にすることができます。
もう1つのオプションは、機能のマージを元に戻すコミットを元に戻して、もう開発中でないようにすることです。元に戻すことを元に戻す新しいブランチを作成し、後でマージするために保留することができます。 Githubプルリクエストを使用している場合は、マージされたプルリクエストの[マージを元に戻す]ボタンを使用して、これを簡単に行うことができます。
この問題をどのように回避できましたか？
プロセスの観点から、次のことを理解します。
- この仕事を始める意思決定者は誰ですか？
- この機能をリリースする決定が変更されたのはなぜですか？
- 期待を逃した？
- 連絡ミス？
- ビジネスサポートが不十分ですか？
- お客様の関与はありませんか？
おそらく、途中でコミュニケーションの低下がありました。これが機能しない場合、開発プロセスはビジネス要件の誤った理解と間違った理解に基づいているため、これは重要です。
管理者の問題を少し忘れて、コードベースに深く統合された「自動サインアップ機能」が最新の製品リリースにすでにあったと想像してください。これで、「自動サインアップ」の「オフスイッチ」を追加するための新しい要件が得られます。これをGitワークフローでどのように処理しますか？
「構成による自動サインアップの無効化」は単に追加機能として宣言するだけだと思います（これは単なる Feature Toggle の形式です）。これにより、ワークフローにスムーズに統合できます。機能ブランチを使用したい場合（または、そのような問題に機能ブランチを使用しない場合）は、作業量を見積もることができます。そして、あなたは間違いなくあなたが説明した通常の "merge dev-> test-> master"フローを使うことができます。
そして、それが実際に現在の状況でこれを処理できる方法です。 gitワークフローの観点からは、変更要求がリリース1.0の管理からのものか、変更要求がリリース2.0の新しい顧客の希望であるかは関係ありません。
これは私がgitflowとGitHubフローで抱えている正確な問題であり、Webアプリケーションではこれが頻繁に発生するようです。この問題を遡及的に解決するか（前述）、または積極的に解決するか（以下の例）。
標準のgitflowブランチに加えて、「バンドルブランチ」を作成しました。バンドルは、uat/qaで使用できるすべての機能で構成されています。 uat/qa機能のリストが作成されます。これらは一時的なバンドルにマージされ、そのバンドルはuat/qaにデプロイされます。バグ修正は元の機能ブランチで行われ、それがバンドルに再度マージされてデプロイされます。これにより、次のリリースが分離されるだけでなく、それらの機能を一緒にテストしてから、開発ブランチへの道を見つけることができます。承認されたブランチは、gitflowプロセスに従ってプルリクエストを開発します。テスト対応機能は、一時的なバンドルブランチに追加または削除して、再デプロイできます。
- これにより、マスターは常にプロダクション準備状態を反映します（フックを使用して自動化できます）
- 開発は常に最新の配信済み（およびテスト済み）の次のリリース候補を反映します
短所には、バンドルリストの管理と別のブランチタイプの追加が含まれます。しかし、手遅れだと思うレトロな修正のほかに、これはより実行可能な解決策のようです。
GUIアドオンでは、自動化を念頭に置いて、バンドル展開ごとに機能ブランチをチェックするのが最適な場合があります。