長時間実行されるリリースビルドを壊す望ましくないコミットに対処するにはどうすればよいですか？
最近仕事で不幸な状況に遭遇し、将来同様の問題を回避するために何ができるのか疑問に思っています。
組み込みシステムを作っています。 FPGAコードは1つのSVNリポジトリにあり、ファームウェアとソフトウェアコードは別のリポジトリにあります。ファームウェアをビルドするには、ビルドされたFPGAイメージが必要であるため、これらのバイナリファイルもファームウェア/ソフトウェアリポジトリに保存されます。 FPGAのビルドには2〜3時間かかる場合があり、ランダムに失敗する場合があります。私の理解では、これらの遅い障害はFPGAロジックの複雑なタイミングの問題が原因で発生します。構文の誤りなどの開発者エラーにより、ビルドは数分以内に失敗します。
ビルドには非常に時間がかかるため、FPGA開発者は通常、変更を加え、ビルドし、ファームウェア開発者に新しいイメージを提供してから、SVNにコミットします。数週間前、リリースの準備をしているときに、これにより多くの問題が発生しました。 1人のFPGA開発者が小さな変更を加え、ビルドを開始しました。別のFPGA開発者がコミットしました（変更をこのリリースに含める必要はなく、コミットするのを待つ必要があると言われた後）。このコミットの後、最初のビルドは失敗しました。次に、最初のFPGA開発者は、他の開発者の変更を元に戻し、変更をコミットし、SVNのコードを検査して、ファームウェアのビルドに必要なイメージのビルドに使用されたコードが反映されていることを確認するために、タグを付ける前にかなりの時間を費やす必要がありました。リリース。
Gitまたは別のDVCSを使用している場合、各FPGA開発者はビルド前にローカルでコミットし、ビルドが成功した後にサーバーにプッシュできるため、これは問題になりません。現在、バージョン管理を切り替えることはできません。現在、FPGAビルドが長いという問題でより多くのハードウェアを投入している最中であり、ビルドツールの設定を変更することでビルド時間を改善できるかどうかを調査しています。
プロセスを改善して、この状況を繰り返さないようにしたり、バージョン管理や競合に関する他の問題を発見したりするために他にできることはありますか？
1人のFPGA開発者が小さな変更を加え、ビルドを開始しました。別のFPGA開発者がコミットしました（変更をこのリリースに含める必要はなく、コミットするのを待つ必要があると言われた後）。このコミットの後、最初のビルドは失敗しました。次に、最初のFPGA開発者は、他の開発者の変更を元に戻し、変更をコミットし、SVNのコードを検査して、ファームウェアのビルドに必要なイメージのビルドに使用されたコードが反映されていることを確認するために、タグを付ける前にかなりの時間を費やす必要がありました。リリース。
問題は、競合する複数の目的に単一のブランチを使用していることです。同じブランチで、リリースパッケージ、低リスクの修正、およびの高リスクの修正を行っています。
コードをチェックインすることに根本的な問題はありません。適切な場所でチェックインする必要があるだけです。はい、DCVSはこれのいくつかの側面を容易にしますが、すべてのソリューションにとって正しい答えではありません。
トランクまたはメインライン（現在すべてをチェックインしている場所）を低リスクの修正および低リスクの開発スポットにすることを検討してください-他の人のために物事を壊さないでください。別のブランチをリリースブランチにします。リリースの準備ができたら、メインラインからのすべての変更をリリースブランチにマージし、そこからビルドします。メインラインからビルドすることもできますが、これは開発版/ナイトリーリリースであり、準備はできていません。
リリースビルドが失敗した場合は、コードを再度トランクにチェックインしてチェリーピックします（これがキーです。2番目の開発者のコードを元に戻す必要がないため）。これをリリースブランチに変更するか、リリースにチェックインします。ブランチし、それをメインラインにマージします。これらのどれが最良の実践であるかについて、人によって意見が異なります。
Advanced SCM Branching Strategies は、このトピックを読むのに適しています。
私が取り組んでいる環境には、リリース（リリース）用のブランチ、開発ビルド（トランク）用のブランチ、およびさまざまなリスクの高い変更用のブランチ（または必要に応じて2つまたは3つ）があります。これらの各ブランチには、ビルドサーバーにseparateビルドがあります。
ソース管理システムに加えて、コードレビューシステムを使用することをお勧めします。これにより、各コミットは、リポジトリに受け入れられる前に、チームの他のメンバーによってレビューおよび承認される必要があります。その他の利点には、知識の共有と開発プロセスの透明性の向上が含まれます。
編集：物事を遅くすることは心配ですが、適切なソフトウェアレビューツールを選択して正しく使用すれば、それは速くて非常に有益です。この方法で短期間に開発プロセスをわずかに遅くすると、何かがばかげたものを中央リポジトリに取得したときに長いデバッグ/修正セッションが不要になり、長期的には時間を節約できます。