アジャイルウォーターフォールの統合と展開の遅延
私たちのビジネスチームは、展開と展開の間に長い期間が必要であり、ビルドがテストのためにステージングされたら、修正が必要でない限り更新しないでください。
これは、2週間のスプリントで機能し、変更を可能な限り推進したいという開発チームのアジャイルプロセスに反します。
ビルドを分離することにはビジネス上の正当性があります。それはコードであり、修正のために変更するだけです。
急速に変化するアジャイル精神を追求しながら、このビジネス要件を達成できるアジャイルアプローチはありますか？
もちろん、現時点では何かありますが、双方は基本的に次のように述べています。
a）企業はビルドを準備してテストしたいと考えています。必要な変更または修正は、進行中の他の作業とは別にする必要があります。
b）開発チームは、ビルド後の修正と他の個別の進行中の作業との間で発生した競合を解決しなければならないという頭痛の種を避けたいと考えています。
注：もちろん、アジャイルプロセスは非常に柔軟であることは理解していますが、この特定のニュアンスを以前に回避したことがあるかどうかを知りたいと思います。
1つの解決策は、Linuxおよびブラウザーのベンダーが使用する「LTS」（長期サポート）モデルを採用することです。
スプリントの最後に、リリースに適したバージョンがある場合は、リリースを作成します。バージョン番号を付け、git（または使用しているバージョン管理ですが、ここではgitを想定しています）でラベルを付け、ドキュメントなどを更新します。その後、そのリリースを内部でのみ効果的にデプロイします。
ビジネスで「テスト用にステージング」するために新しいバージョンをデプロイする必要がある場合は、最新のリリースを提供します。その時点で、そのリリースにも「LTS」というラベルを付けます。次に、スプリントと新しいリリースを続けます。
テスト中に問題が見つかった場合は、gitから提供したLTSバージョンから分岐し、修正を加え、ラベルを付け直して、再リリースします。また、該当する場合は、修正を最新バージョンに適用します。
それは完璧な解決策ではありません、そして彼らが新しいバージョンを望むとき、彼らはあなたがその間に追加した機能のいくつかだけを欲しがることに気付くかもしれません。すべての機能が（実行可能な限り）独自のブランチに保持される「機能ブランチ」を使用すると、それらの機能だけをマスターにマージしてリリースを作成するので役立ちます。
機能ブランチではなく、機能フラグを使用することをお勧めします。基本的に、これらはコードの特定の部分が実行されるかどうかを決定するコード内の単なる条件です。構成を通じて機能のステータスを制御します。構成は、Web.configのアプリ設定のように単純な場合もあれば、LaunchDarklyなどのサードパーティサービスのように複雑な場合もあり、どのユーザーがどの機能にアクセスできるかをきめ細かく制御できます。いつ。
フィーチャートグルの欠点の1つは、本質的に技術的負債であるということです。基本的に、コードベースで実行できないコードがあり、そのコードは時間とともに成長します。一部の企業は実際には抱擁これです。たとえば、Facebookは機能フラグを多用し、決してクリーンアップしません。個人的には少しおかしいと思いますが、彼らにとってはうまくいくと思います。残りの私たちにとって、一般的な推奨事項は、機能フラグが導入されたときに、それをクリーンアップするためにPBIも追加することです。次に、この機能を完全に展開したら（そして、大きな問題がないことを確認するためにしばらく時間をかけて）、技術的負債を取り除くためにPBIをスプリントに追加します。理想的ではありませんが、管理は容易です。
技術的負債はさておき、フィーチャートグルはあなたに大きな自由を与えることができます。実際にコードをマスターにマージすることはできますが、実際にはfeatureをデプロイしないことを選択してください。これにより、masterと数週間または数か月ずれているコードとのマージの処理について心配する必要はありませんが、実際の製品は変更されていません。
さらに良いことに、パッチを適用して機能を有効にすることができます。これは、完全なアップグレードよりもはるかに簡単です。たとえば、典型的なモノリシックリリースサイクルに従っているとしましょう。新機能のバッチ全体があり、その一部にはコア製品の根本的な変更が必要です。アップグレードプロセスでは、これらすべての新機能を有効にするために、多くのファイルにアクセスし、多くの変更を加える必要があります。次に、問題、大きな問題、クイックフィックスをプッシュするだけでは解決できない問題があります。ダウングレードを処理し、ユーザーを使用可能な状態に戻す方法を理解する必要があります。それは問題の獣です。
それでは、フィーチャートグルのアプローチを見てみましょう。これらの機能のすべてのコードはフラグの背後にあるためです。それらをオンにするリリースを実行するだけです。もちろん、実際に最後のリリースになかった場合は、コードをプッシュダウンする必要があります。これには、同じモノリシックアップグレードが必要になる場合があります。しかし、物事があなたのためにはるかに良くなるのは物事が爆発したときです。今回は、ユーザーをダウングレードして新しいモノリシックリリースを計画する必要はありません。代わりに、問題を引き起こす機能を無効にするパッチを発行するだけです。これで、アプリケーションは以前の状態に戻ります。問題を修正したら、製品全体を再リリースする代わりに、ロールフォワードして、修正のみをプッシュして機能をオンに戻すことができます。
私はこの答えがその中傷を持っていると確信していますが、何でも。あなたの質問への答えは、双方が説明されているように彼らが望むものを手に入れることは不可能であるということです。したがって、いくつかの選択肢があります。まず、ビジネスが本当に望んでいるものを見つけてください。彼らがビジネス上の理由を明確に表現できない場合、あなたは彼らをそのための仕事に連れて行くべきです。たとえば、開発プロセスを制御したいだけかもしれません。あるいは、彼らはプロジェクト管理とリリース計画についてのカーゴカルトの信念に従っていて、どこかで読んで、これがまさにそれが行われている方法であると考えているかもしれません。
正当なビジネス上の理由は、制御された環境で凍結されたコードベースのQAサイクルがより多くのバグをキャッチし、本番環境にリリースされる欠陥が少なくなると信じていることかもしれません。それが、私が考えることができる唯一の理由です。ただし、そのシナリオでは、中心的な質問は「本番環境での欠陥が少ない」ことです。
これを認定および定量化するように依頼します。彼らは欠陥が少なくなることをどうやって知っていますか？現在の不良率はどれくらいですか？アジャイルプロセスで同様の欠陥ドロップを達成することは可能ですか？彼らに彼らの仕事を見せてもらいなさい。
別のアプローチは、自動化されたユニットとの継続的インテグレーション、統合テスト、および機能がユーザーに表示されるタイミングを制御するための機能フラグ付けです。
この後者のアプローチの利点は重要であり、SCMの複雑さの軽減を超えています。その他のメリットとしては、製品化までの時間の短縮、特定のユーザーサブグループへの機能展開のステージング、リファクタリングの容易化、欠陥の減少、開発チームの自律性と満足度の向上、全体的な企業評価の向上などがあります。
私が見たものの1つは、基本的に定期的なスイープです。展開の準備ができているとマークされた場合、誰かが展開義務に割り当てられ、コードを確認し、展開の前後に実行する必要があること（特定のグラフの監視やデータベースの移行の実行など）を探してから展開します。
これは、リリースを持つことの他の回答で言及されているアイデアに似ています。安定版リリースブランチ（またはタグ）は、不安定版ブランチとは別に存在します。
このようにして、開発はアジャイルチームが望むだけ速く続行でき、リリースが実際に展開される時期に応じて、そのリリースの結果からのフィードバックが遅れます。チームがそのフィードバックに依存している場合、開発サイクルは遅くなります。その場合、製品の所有者や顧客をチームに参加させるか、スプリントを長くすることが理にかなっています。