継続的インテグレーションで複数のブランチを処理する
私は自分の会社でCIのスケーリングの問題に取り組んでいると同時に、CIと複数のブランチに関してどのアプローチを取るべきかを理解しようとしています。stackoverflow、複数の機能ブランチ、継続的インテグレーションにも同様の質問があります。私はより多くの議論を得て、質問のいくつかの分析を提供したいので、私は新しいものを始めました。 これまでのところ、私が取ることができる2つの主要なアプローチ（またはおそらく他のいくつかのアプローチ）があることがわかりました。 ブランチごとの複数のジョブセット（ここではJenkins / Hudsonについて説明しています） 余分な仕事を管理するためのツールを書く ジョブを一括で作成/変更/削除する ブランチごとの各ジョブのカスタム設定（SCM URL、部門管理リポジトリの複製） シェルツール、Antスクリプト、JenkinsCLIを使用してこの問題に取り組んでいる人々の例。見る： http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729。 html http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html ハドソンジョブを自動的に構成または作成する CIクラスターにより多くの負荷がかかります 開発者のフィードバックサイクルが遅くなります（インフラストラクチャが新しい負荷を処理できない場合） 2つのブランチごとの複数のジョブセット（開発および安定） 2つのセットを手動で管理します（ジョブの設定を変更する場合は、必ず他のブランチで変更してください） PITAですが、少なくとも管理するものはほとんどありません 他の追加のブランチは、開発にプッシュされる前に完全なテストスイートを取得しません 満足していない開発者。開発者がCIスケーリングの問題を気にする必要があるのはなぜですか。彼には簡単なリクエストがあります。ブランチするときに、コードをテストしたいと思います。シンプル。 したがって、開発者に独自のカスタムブランチ用のCIを提供したい場合は、Jenkins用の特別なツール（APIまたはシェルスクリプトなど）が必要であり、スケーリングを処理する必要があるようです。または、より頻繁にDEVにマージして、カスタムブランチでCIなしで動作するように指示することもできます。どちらを選びますか、それとも他の選択肢がありますか？