テスト環境の分岐戦略

今月から新しいプロジェクトを開始します。プロジェクトは1年間で、本番環境への展開はプロジェクトの終わり頃にのみ行われます。

反復的な開発（反復ごとに1か月）を行うため、これは、QAテストの各反復の終わりに機能をテスト環境にドロップすることを意味します。

私たちの分岐戦略は：

1. トランク-すべての開発はトランクで行われます。
2. 機能の分岐-トランクから分岐すると、大きな機能を開発するために必要に応じて作成され、トランクで実行すると壊れる可能性があります。
3. QAリリースブランチ-各反復の最後に、トランクのブランチが作成されます。このブランチ（バージョン番号を含む）は、テスト環境にリリースされます。このバージョンで発見されたすべての重大なブロッキングバグはこのブランチで修正され、修正はトランクにマージする必要があります。新しいリリースブランチがトランクから作成される次の反復の終了後にQAリリースブランチが破棄されるため、重大ではない/重要でないバグはQAリリースブランチでは対処されず、トランクでのみ修正されます。
4. 本番ブランチ-これは、プロジェクト終了時の最新のQAリリースブランチになります。これはタグ付けされ、すべての製品バグ修正はこのブランチにあり、トランクにマージされます。

これは正しい分岐戦略ですか？他に検討し損なったことはありますか？

SVNを使用しています。

あなたの分岐戦略は私には本当によく見えます。私は過去に同じ戦略を実行しましたが、うまくいきます。ホワイトボードにそれを作成し、すべての開発者に理解してもらい、人々が適切なブランチで適切な作業を行えるようにします。全員にスイッチコマンドを教えて説明し、取り組んでいるブランチを全員に再確認してもらいます。（または、コードのサイズに応じて、リポジトリ全体を確認してください...）覚えておいてください... svn revertはあなたの親友です！

個人的には、すべてを確実に管理し、一貫性を保つために、1人の人を（マージ/ブランチ）人（予備として数人の予備の人がいる）にすることを好みます。その人をあなたのSVNの第一人者にしましょう。

他のいくつかの役立つヒント：

• 頻繁なSVN更新とSVNコミットを奨励します。毎日が望ましいです。
• ブランチ間マージも毎日、またはバグが修正されるたびに行う必要があります。早期に実施し、頻繁に実施してください！（あなたはそれで本当にすぐに上手くなるでしょう）。
• 良いdiffツールを入手してください-beyondcompareはエースです。標準のtortoiseSVNの1つ...あまり良くありません。
• コンパイル時に変更されるもの（出力ディレクトリなど）をチェックインしないでください。
• ブランチを開始する前に、リポジトリをクリーンアップしてください（バージョン管理下にある必要のないファイル（外部ライブラリなど）を削除してください）。レポが小さいほど良い
• ProductionブランチとQAブランチへの変更はできるだけ小さく、短くする必要があります。そこでコードのリファクタリングを開始せず、バグを修正してください。
• 必ずソリューションの最上位から分岐してください。DBがある場合は、すべてのDB要素（ストアドプロシージャやトリガーなど）をスクリプト化したことを願っています。

また、厳密に必要でない限り、フォルダを移動しないように指示してください。これはあなたのマージをはるかに簡単にします:)（私がしたことをしないでください、私たちのマージのすべてを台無しにしたトランクへの大きな変更の途中で大規模なディレクトリ再構築を開始してください...その後私はかなり人気がありました）。

うまくいかないかもしれないアイデアのように聞こえます。

たぶん、このリンクを見てインスピレーションを得てください：GitHub Flowこれは、githubがバージョンシステムを使用している方法です。彼らはsvnの代わりにgitを使用していますが、彼らの決定の背後にあるアイデアはそれでも成り立つと主張します。

バージョン管理に関するこのブログ投稿の（私見）最も重要な部分：

• マスター/トランクは展開可能、または-さらに良い-展開済み
• 開発はブランチでのみ発生します
• マージはレビュー後にのみ発生します（おそらくQAをここに配置できます）

これにより、安定性が得られます。その理由を説明させてください。分岐するための基地が必要です。このベースがあなたができる最善の方法ではなく、すべての究極のインスタンスである場合、そうすることは実際には意味がありません。他の人がトランクに取り組んでいるときにトランクから分岐すると、まだ発見または修正されていないバグが発生します。したがって、統合テスト（および上記のもの）は、原因ではなくても失敗する可能性があり、デバッグとフラストレーションの量が大幅に増加します。

さらに、3つのブランチ（トランク、QA、本番）の同期を維持するために多くの作業が必要になります。これはおそらく混乱を招きます。これを自動化で強制しないと、ある時点でトラックが失われることをほぼ保証できます。

GitHubが進んでいる方法をお勧めします。次に、QAに送信するバージョンにタグを付けて、通信時に参照できるようにします。上記のように、フィードバックループにQAをより緊密に統合することもできます。まだ使用を検討していない場合は、JenkinsなどのCIシステムを使用することを強くお勧めします。これにより、チェックインとフィードバックの間の往復時間を最小限に抑え、コーディングルールを適用したり、エラーチェックのために静的アナライザーを実行したりできます。

免責事項： gitフローは、新機能を導入せずにバグを修正したくない場合にのみ機能します。これを行いたい場合は、あなたのアプローチの方が適しているかもしれません。

あなたの分岐戦略はかなり合理的だと私に思わせます。私たちの会社でも同様の戦略を追求しており、それはうまく機能しました。

わずかな違いの1つは、プレリリースQAの修正をトランクで行うことです。これにより、マージし直す必要がなくなり、欠陥を修正しながら新しい機能を開発するのに問題がありませんでした。これにより、テスト対象に関してQAの目標が少し変わります。そのため、これがどの程度機能するかは、QAが開発チームとどの程度緊密に統合されているかに依存します。私たちはかなり統合されたチームを持っているので、そして私たちは速い反復スケジュールにいるので、それは私たちにとってうまくいきます。トランク上に新しい機能を構築しながら本番環境にパッチを適用できるように、リリースごとに個別のブランチがありますが、QAを超えてリリースを開始するまで、それは必要ないようです。

私が行う追加の推奨事項がいくつかあります。

1. 頻繁なチェックインを奨励します。 これは、多くの人がトランクで開発している場合に特に便利です。開発者が他の人が行っていることと同期しなくなるのを防ぎ、競合の可能性を減らします。コミットしてもよい時期と、開発者がトランクから取得する頻度について明確なガイダンスがあることを確認してください。機能ブランチへの重大な変更を分離しようとしているのであれば、頻繁なコミットは問題になりません。
2. 継続的な統合プロセスを確立します。 これにより、イテレーションの最後に大きな統合の問題が発生しないようになり、何かが壊れた場合に通知を提供し、自動化された単体/受け入れテストと静的分析/コードの両方を通じてQAをさらに自動化しましょう検査ツール。CIは、構成管理プロセスへの投資として、優れた「コスト削減」を提供することがわかりました。 注意、ブランチは本質的にトランクをクリーンに保ち、CIでのテストに合格しますが、ブランチで競合/問題を作成するため、CIと機能ブランチの使用の間には緊張があります。ブランチにCIを実行してトランクから頻繁にプルする場合と同様に、トランクに頻繁にマージすることでこれを助けることができますが、ブランチの急増は、管理を複雑にするか、ブランチで単に無視することにより、CIプロセスを無効にし始めます。

あなたが述べることから：
あなたのコードはトランクに常駐します
主要な機能/拡張ごとに-トランクからブランチを切り離し、開発してQAに提供してテストします
すべての主要で重要なバグはこの「QAブランチ」で修正され
ますQA後のトランク'このブランチからトランクに戻るコード

これは、私にとって
定期的にブランチ、マージ、およびトランキングを行っているEclipseのsvnプラグインまたは亀を使用して、かなり問題のない戦略だと思い
ます。

それはうまく聞こえます、QAブランチの存続期間が比較的短いことを心配しています。そのブランチでそのリリースに関連するすべての修正を行い、見つかったトランクで修正するのではなく、1ゴーでトランクにマージします。 。

QAブランチの些細なバグを修正すると、テスターはそれらをすばやく確認してマークを付けることができます。私は、彼らがQAブランチから毎日/毎週ビルドを取得することを想定しているので、QAで行われたとしても、些細なバグはまったく時間を消費するべきではありません。（私は小さなバグの最も小さなものが他の場所で大きな悲しみを引き起こすノックオン効果を持つことができるという経験から話します）

私が言及できる潜在的な改善の1つは、ブランチで機能開発を行うことです。つまり、通常トランクで行う作業を代わりに専用ブランチに移動します。その後、トランクはマージされたマージのみを持ち、完了した変更の追跡に役立ちます。

あなたは、ぎこちなさを増し、プロジェクトの成功の可能性を減らす可能性が高いいくつかのことについて言及します。

プロジェクトは1年間で、本番環境への展開はプロジェクトの終わり頃にのみ行われます。

私は本当に、できる限り頻繁に、理想的には毎日、本番のような環境にデプロイすることをお勧めします。いわゆる「プロダクション」をプロジェクトの最後に残すと、通常、予期しない問題が発生します。 ここでのアンチパターンは、「後期統合」と「後期生産配備」です。

反復ごとに1か月

1か月は非常に長いイテレーションハートビートであり、イテレーションの開始時に何に取り組んでいたかを明確に思い出せる開発者はほとんどいません。2週間のイテレーションを行って、より小さなバッチで配信することをお勧めします。アンチパターン：「バッチサイズが大きい」、「サイクルタイムが長い」。

機能ブランチ

統合ブランチも使用しない限り、機能ブランチはおそらく避けてください。代わりに、機能の切り替えと抽象化による分岐を使用するのが理想的です。機能の分岐は、予期しない統合の問題につながる傾向があります。アンチパターン：「後期統合」。

SVNを使用しています。

Subversionでは、v1.5以降のマージ追跡機能を使用していても、マージは非常に困難です。Gitに切り替えることをお勧めします。振り返ることはありません。Gitとのマージは、Svnと比較して簡単です。私は長年Subversionを使用しており、当初はGitに懐疑的でしたが、現在は「販売」されています。SvnをGitで使用するのは、バイナリファイルの保存（本当に必要な場合のみ）と、リポジトリの完全な制御下にあるRANCIDのようなものだけです。ソースコード管理では、Gitは毎回Subversionに勝っています。

私は最近、「思考の糧」あなたにいくつかのさらなるを与える可能性がある、私はトランク/メインライン/マスターと機能ブランチを避けることから解放する上で行っている仕事について書いた： プラットフォームを残す-分岐し、独立したサブシステムのための解放します

また、ContinuousIntegration、FeatureBranch、BranchByAbstractionなど、Martin Fowlerのサイトのいくつかの投稿を読んでください。

最後に、Jez HumbleとDavid Farleyによる継続的デリバリーのコピーを購入し、推奨事項に取り組みます。これは非常に貴重な本であり、すべての開発者がコピーを所有する必要があります。目次ページを印刷して壁に貼って進行状況を追跡すると便利です。継続的に配信するつもりがない場合でも、この本の実践の多くは、ソフトウェアの配信を成功させるために非常に健全で不可欠です。今日。

お役に立てれば。

M