最近行われたブランチ戦略に関するかなり良い議論の中で、jgifford25の回答には、Subversion の開発者の 1 人が「アジャイル リリース戦略」と呼んでいるものへのリンクが含まれていました。トランクではなく、リリース ブランチにマージします。私はそれが良い考えだとは思いませんでしたし、これも良い考えだとは思いません。また、どちらの場合も、アイデアが SCM 開発者によって推し進められているのは偶然ではないと思います。彼らには「すべてが釘のように見える」ケースがあると思います。プロセスの問題は、より多くの方法で修正できると思います。そしてより大きなSCM。
では、なぜこの考えが悪いのでしょうか。プラスチックの連中の主張に従いましょう。このプロセスは、「メインラインを元の状態に保つ」という 1 つの中心的なアイデアに基づいて構築されています。ここまでは順調ですね。次に、次のような三段論法を進めます。
- 壊れたコードをトランクにチェックインすると、ビルドが壊れます
- 壊れたビルドは悪い
- したがって、コードをトランクにチェックインしないでください
これの問題は、壊れたビルドが悪い理由を完全に誤解していることです。壊れたビルド自体は悪くありませんが (開発を停止させるので役に立ちませんが)、誰かが壊れたコードをチェックインしたことを意味するので悪いです。本当の問題は壊れたコードであり、壊れたビルドではありません - 実際に損傷を引き起こす可能性があるのは壊れたコードです (ユーザー データの損失、宇宙探査機の紛失、地球規模の熱核戦争など)。
彼らの解決策は、壊れたコードを別の場所でチェックしてもらい、ビルドが壊れないようにすることです。これは明らかに、壊れたコードの実際の問題に対処するものではありません。まったく逆に、これは壊れたコードを隠す方法です。確かに、どの時点で破損が検出されるかは明確ではありません-タスクブランチがファイナライズされ、リリースブランチにマージされるとき? これは、難しい作業をリリース サイクルの後半に延期する優れた方法のように思えますが、これは非常にまずい考えです。
むしろ、本当の解決策は、壊れたコードをまったくチェックインしないことです。その目標を追求する上で、壊れたビルドは実際には良いものです。なぜなら、壊れたコードがあることがわかり、それを修正できるからです。実際、これが継続的インテグレーションの考え方の転換点です。実際にリリースされるもののプロトタイプである単一のトランクに早期にマージすることが多いため、リリースしようとしているものの問題をできるだけ早く検出します。可能。それには、「不安定なトランク」モデル、またはそれに同形のモデルが絶対に必要です。
Orangepips の回答がリンクしているブログ投稿では、このアイデアの原動力としてのプロセスに関する Ubuntu のアイデアについて言及しています。しかし、シャトルワースが実際に言ったことを見てください。
- トランクをきれいに保つ
- 機能の流れを維持する
- オンデマンドでリリース
これが私が強調する最後の点ですが、これが Shuttleworth の最終目標です。彼はいつでもリリースをカットできるようにしたいと考えています。プラモデルのようにマージとテストをリリース プロセスに先延ばしするプロセスでは、これを実行することはできません。
むしろ、それを実行できるプロセスがどのようなものかを確認したい場合は、無駄のない人たちが何をしているかを見てください: 1 つのコードライン、継続的インテグレーション (数日または数週間ではなく数時間または数分のスケールで)、壊れたコードはありません.
結論として、これをしないでください。1 つのコードラインを用意し、できるだけ頻繁に作業コードをそれにチェックインします。単純。
PS では、リリース ブランチを作成して、実際のリリースを安定させ、バグ修正することをお勧めします。理想的にはそうしませんが、そうする必要があるかもしれません。
PPS また、チェックインする前に実行するには遅すぎる CI テスト スイートがある場合 (たとえば、1 時間かかる機能テスト)、DVCS でできることは、2 つのリポジトリを用意することです。クリーン リポジトリは、ダーティ リポジトリの変更を監視し、新しいバージョンをビルドしてテストし、合格した場合はクリーン リポジトリにプッシュするスクリプトによってプッシュされます。その後、クリーン リポジトリからオンデマンド リリース (QA など) を実行できます。開発者はクリーン リポジトリから更新して、開発中に最新の状態を維持できます。ただし、マージの直前にダーティ リポジトリから更新する必要があることは明らかです。