既存の基幹業務アプリケーションの拡張に取り組んでいる場合、変更を頻度の低い大きなリリースにまとめるのが良いと思いますか、それとも小さなリリースで新しい機能を継続的に出荷するのが良いと思いますか？ハードウェアのアップグレードまたはデータベースのアップグレードがあると仮定して、これらの変更をリリースでも行いますか、それとも別々に保ちますか？
すべてを一緒にリリースすると、ビジネスの中断が少なくなり、時間外の作業が少なくなるという利点がありますが、後で発生する問題は、データベースのアップグレード、ハードウェア、またはソフトウェアの変更が原因である可能性があります。
リリースはほとんどなく、多くの場合、リリースに起因する問題の追跡が容易になりますが、より多くの混乱と回帰テストに費やされる時間が発生します。
どちらが良いですか？
各リリースが顧客にどのように影響するかを検討してください。頻繁な小さなリリースは、重大な問題をより早く解決するため、それらをより幸せにしますか？これはあなたの売り上げと評判を改善しますか？これらの利点が行われた余分な作業を上回るかどうかを慎重に見積もる場合は、そうでない場合は、より便利なパスをたどってください。
それは本当にあなたの環境に依存します。いくつかのシナリオ：
多くの顧客：可能な限り、すべての顧客に同じリリースを提供する必要があります。テストとロールアウトの調整には非常にコストがかかるため、年次、半年ごと、または四半期ごとの大きなリリースを作成する方がはるかに簡単です。この場合、dbの変更も含めます。
「大規模なインフラストラクチャ」：オペレーティングシステムとデータベース専用の担当者がいる大企業環境で作業する場合も、リリースの全体的なコストが大きいため、リリースの頻度が少ないほど優れています。
要するに、人的資源、ビジネスの中断、調整、テストのリリースのコストを計算し、それを各新機能またはバグ修正の利点と関連付けます。
私は通常、1年に1〜2回の大きなリリースがあり、その間にショーストッパーのバグ修正が行われる傾向があります。
最良の答えは、2つの混合物だと思います。
たとえば、アイキャンディーを追加したり、名前のテキストボックスをより「アジャクシー」にしたり、新しいタイプのレポートを追加したりした場合は、これを「小さな」リリースにします。できるだけ早くリリースし、頻繁にリリースします。
一方、ユーザー向けのプロセスを変更してユーザーを「再トレーニング」する必要がある場合、または大規模なインフラストラクチャの変更が必要な場合は、大規模なリリースに進み、これをできるだけ少なくします。
あなたが言ったように、中断がほとんどまたはまったくない場合は、できるだけ頻繁に実行してください。ユーザーはそれを喜ぶでしょう-そして、変更に関連するすべてをテストするだけでよいので、実際には回帰テストに費やす時間が少なくなりますあなたが作った。
個人的には、大きなリリースが好きです。
私は自宅にソフトウェアを持っており、週に複数回更新を提示します。自動更新機能がなく、通知が戻ってくるだけなので、面倒です。
この同様の質問を確認することをお勧めします：ソフトウェアアップデートをリリースする頻度
将来的に問題を修正する必要があるので、1つの大きなリリースにまとめてパッチを適用する方が良いと思います。
開発者は、システムを可能な限り堅牢にするために、システムで発生する可能性のある問題や障害を予測する必要があります。これは通常、事前に多くのテストを行うことを意味します。
また、エンドユーザーは製品の小さな増分にお金を払うことを望まないかもしれず、大きな更新を待つこともできることを考慮してください。この良い例は、Adobe Photoshopを入手したときです。彼らは毎年新しいバージョンをリリースしているようですので、ちょうどいいタイミングになるまで待っていました。
リリース数が少ないということは、すべてのバグを一度に見つけることができるということです。どのコード変更がどのバグを引き起こしたかを知ることは難しくなります。次に、カスケードバグに関する問題がさらに発生します。数か月前に行ったコード変更の1つでバグが発生しましたが、その間に、数か月前に導入したバグに依存する5つの変更を加えました。
小さくて高品質のリリースの方が優れています。リリースが小さいほど、高品質になりやすくなります。
実際、両方。
開発をDEVELブランチとRELEASEブランチに分割できますか？緊急の問題は、RELブランチでできるだけ早く実行し、修正プログラムとしてユーザーに送信する必要があります。RELブランチに修正プログラムを適用した後、パッチを適用する必要がDEVチームに送信されます（注：RELの問題を修正するには、簡単なコードを作成する必要がありますが、DEVブランチでは、提案された修正を再考するために時間をかける必要があります、DEVブランチの条件が変更された可能性があるため、DEVまたはRELブランチの同じ問題を修正するために、まったく異なるコードを作成するのが一般的です）。
新しいバージョンの開発が行われるときは、RELから移行された新しい機能とパッチをテストする必要があります。すべて問題がなければ、新しいビッグバージョンをデプロイし、現在のDEVをRELにアーカイブできますが、古いRELは封印されます。