バージョン管理ソフトウェアのコードをチェックして、継続的な統合や夜間のビルドを実行する際に、通常どんなことをしていますか？ 1）最新のコードを取り出すか、2）テストする開発者の最新コードを表すタグ（つまり、機能的）を引きますか？継続的なインテグレーションをチェックしてください
私はこのことに対する答えは、人々が通常構成管理リポジトリをどのように使用しているかによって決まると思います。あなたはそれが "完全"なコードだけを格納するつもりですか？そのような場合、開発者が1週間ほどタスクを作業している場合、タスクが完全に完了するまで何かをチェックすることはできません。しかし、継続的インテグレーションサーバが最新のコードを引っ張るのではなく、よく知られたタグで引っ張られれば、開発者は進行中の作業の履歴を保存するために非常に頻繁にコードをチェックすることができます。その後、変更に慣れたら、新しいコードにFUNCTIONALタグを付けることができました。
ベストプラクティスを知りたいだけです。
おかげ
は、だから我々は通常、何をすべきかは、CIサーバーがオフ構築する「構築」の枝を持っています。私たちは夜間のビルドに含めるすべてのものをビルドブランチにマージし、そこにビルドします。
実際にビルドブランチに対して開発するわけではありません。テスト環境にリリースする準備ができていない変更を保存するために使用される開発ブランチがあります。私はCI（親指のルールのようなより）のために出したい
主な提言：
私の経験の一部： 私たちのCIは、HEAD/MASTERからコードを取得します。 ここでgitを使用するので、開発者がブランチで作業して同期させるのは非常に簡単ですが、HEAD/MASTERに安定したコードをコミットするだけです。
私は上記のほとんどの点に同意します - 1つの注意が考えられます - コミット単位で実行している場合、大規模なプロジェクトの複数のモジュールを同時に処理している複数のデベロッパーチームのメンバーです。コミットの頻度は、特に多くのテストがある場合は、CIサーバーを圧倒する傾向があります。この場合、特定のコミット数またはスケジュールの後に実行するようにビルドをバッチしようとします。 – Nikhil
正しい答えは、コードの編成方法に基づいています。
メインラインが常に安定していると思っているのであれば、そのメインラインは単に安定しているはずです。常にビルド可能な、常に「//
をお持ちの場合は
は、我々は枝の3種類がありますQAは、黄金//枝をリリース
（もちろんこれを行うには良いvcsが必要です。私たちはパーフォースを使用しています。これは素晴らしい分岐を持っています）。
私たちは、幹線から分岐しています。
HTH
あなたが開発者は、破損を引き起こすことなく仕事に取り組むことができないと仮定しているが、それは必ずしも真実ではない、それぞれがコミットする前に、彼らはユニットテストスイートを実行する場合は特に、とすることを避けますテストが失敗したときのコミット。 – bdsl