継続的インテグレーションで複数のブランチを処理する

Question 1

私は自分の会社でCIのスケーリングの問題に取り組んでいると同時に、CIと複数のブランチに関してどのアプローチを取るべきかを理解しようとしています。stackoverflow、複数の機能ブランチ、継続的インテグレーションにも同様の質問があります。私はより多くの議論を得て、質問のいくつかの分析を提供したいので、私は新しいものを始めました。

これまでのところ、私が取ることができる2つの主要なアプローチ（またはおそらく他のいくつかのアプローチ）があることがわかりました。

ブランチごとの複数のジョブセット（ここではJenkins / Hudsonについて説明しています）
- 余分な仕事を管理するためのツールを書く
  - ジョブを一括で作成/変更/削除する
  - ブランチごとの各ジョブのカスタム設定（SCM URL、部門管理リポジトリの複製）
  - シェルツール、Antスクリプト、JenkinsCLIを使用してこの問題に取り組んでいる人々の例。見る：
- CIクラスターにより多くの負荷がかかります
- 開発者のフィードバックサイクルが遅くなります（インフラストラクチャが新しい負荷を処理できない場合）
2つのブランチごとの複数のジョブセット（開発および安定）
- 2つのセットを手動で管理します（ジョブの設定を変更する場合は、必ず他のブランチで変更してください）
  - PITAですが、少なくとも管理するものはほとんどありません
- 他の追加のブランチは、開発にプッシュされる前に完全なテストスイートを取得しません
- 満足していない開発者。開発者がCIスケーリングの問題を気にする必要があるのはなぜですか。彼には簡単なリクエストがあります。ブランチするときに、コードをテストしたいと思います。シンプル。

したがって、開発者に独自のカスタムブランチ用のCIを提供したい場合は、Jenkins用の特別なツール（APIまたはシェルスクリプトなど）が必要であり、スケーリングを処理する必要があるようです。または、より頻繁にDEVにマージして、カスタムブランチでCIなしで動作するように指示することもできます。どちらを選びますか、それとも他の選択肢がありますか？

Question 2

CIのスケーリングについて話すときは、メインラインとともにすべての機能ブランチを処理するためのCIサーバーの使用のスケーリングについて実際に話します。ブランチの開発者は、CIジョブに含まれる自動テストのすべての利点を利用できるため、最初はこれは良いアプローチのように見えます。ただし、（発見したように）CIサーバージョブの管理で問題が発生し、さらに重要なことに、実際にはCIを実行していません。はい、CIサーバーを使用していますが、すべての開発者からのコードを継続的に統合しているわけではありません。

実際のCIを実行するということは、すべての開発者が定期的にメインラインにコミットしていることを意味します。言うのは簡単ですが、難しいのはアプリケーションを壊さずにそれを行うことです。継続的デリバリー、特に第13章：コンポーネントと依存関係の管理の「アプリケーションをリリース可能に保つ」セクションを確認することを強くお勧めします。主なポイントは次のとおりです。

完了するまで新しい機能を非表示にします（別名フィーチャートグル）。

すべての変更を一連の小さな変更として段階的に行います。各変更はリリース可能です。

抽象化による分岐を使用して、コードベースに大規模な変更を加えます。

コンポーネントを使用して、さまざまな速度で変化するアプリケーションの部分を切り離します。

それらは、抽象化による分岐を除いて、かなり自明です。これは、次の意味での単なる空想用語です。

変更する必要のあるシステムの部分に抽象化を作成します。

システムの残りの部分をリファクタリングして、抽象化レイヤーを使用します。

完了するまで本番コードパスの一部ではない新しい実装を作成します。

抽象化レイヤーを更新して、新しい実装に委任します。

古い実装を削除します。

適切でなくなった場合は、抽象化レイヤーを削除します。

第14章の「ブランチ、ストリーム、および継続的インテグレーション」セクションの次の段落：高度なバージョン管理は影響を要約しています。

インクリメンタルアプローチでは、ブランチを作成してガンホーを再構築して新しい機能を開発するよりも、確かに多くの規律と注意、そして実際にはより多くの創造性が必要です。ただし、変更によってアプリケーションが破損するリスクが大幅に軽減され、マージ、破損の修正、およびアプリケーションをデプロイ可能な状態にするための時間を大幅に節約できます。

機能ブランチをあきらめるにはかなりのマインドシフトが必要であり、常に抵抗があります。私の経験では、この抵抗は、開発者がコードをメインラインに安全にコミットできないことに基づいており、これは合理的な懸念事項です。これは通常、上記の手法に関する知識、自信、または経験の欠如、および場合によっては自動テストに対する自信の欠如に起因します。前者は、トレーニングと開発者のサポートで解決できます。後者は対処するのがはるかに難しい問題ですが、分岐は特別な安全性を提供せず、開発者がコードに十分な自信を持てるようになるまで問題を延期するだけです。

Question 3

ブランチごとに別々のジョブを設定します。私は以前にこれを行ったことがありますが、Hudson / Jenkinsを正しく設定していれば、管理と設定は難しくありません。複数のジョブを作成する簡単な方法は、同様の要件を持つ既存のジョブからコピーし、必要に応じてそれらを変更することです。各開発者が自分のブランチ用に自分のジョブをセットアップできるようにするかどうかはわかりませんが、1人の人（つまりビルドマネージャー）が管理するのはそれほど手間がかかりません。カスタムブランチが安定したブランチにマージされると、対応するジョブは不要になったときに削除できます。

CIサーバーの負荷が心配な場合は、CIの個別のインスタンスを設定することも、個別のスレーブを設定して、複数のサーバー間で負荷を分散することもできます。Hudson / Jenkinsを実行しているサーバーが適切であることを確認してください。私はApacheTomcatを使用しましたが、ビルドキューを処理するのに十分なメモリと処理能力があることを確認する必要がありました。

CIを使用して何を達成したいのかを明確にしてから、手作業や重複をあまり行わずにCIを実装する方法を見つけることが重要です。ビルド管理プロセス全体を簡素化するのに役立つ、CIサーバーによって実行される他の外部ツールまたはスクリプトを使用しても問題はありません。

Question 4

dev + stableブランチを選択します。それでもカスタムブランチが必要で負荷が心配な場合は、これらのカスタムブランチをクラウドに移動して、開発者が自分で管理できるようにしてください。例：http：//cloudbees.com/dev.cb これはKohsukeが現在いる会社です。。Eclipse Toolingもあるので、Eclipseを使用している場合は、それをdevenvに緊密に統合することができます。

Question 5

実際に本当に問題なのは、機能ブランチを使用したビルドの分離です。私たちの会社には、より大きなディストリビューションの一部である一連の個別のMavenプロジェクトがあります。これらのプロジェクトは異なるチームによって維持されていますが、ディストリビューションごとにすべてのプロジェクトをリリースする必要があります。フィーチャーブランチがプロジェクト間でオーバーラップする可能性があり、ビルドの分離が困難になる場合があります。私たちが試したいくつかの解決策があります：

機能ブランチごとにネクサスに個別のスナップショットリポジトリを作成します
専用スレーブでローカルリポジトリを共有する
アップストリームリポジトリでrepository-server-pluginを使用する
1つのプライベートリポジトリですべてを1つのジョブ内に構築する

実際のところ、最後の解決策が最も有望です。他のすべてのソリューションには、何らかの形で欠けています。job-dslプラグインと一緒に使用すると、新しい機能ブランチを簡単にセットアップできます。groovyスクリプトをコピーして貼り付け、ブランチを調整して、シードジョブに新しいジョブを作成させるだけです。シードジョブが管理されていないジョブを削除することを確認してください。次に、さまざまなMavenプロジェクトの機能ブランチで簡単にスケーリングできます。

しかし、トムが上でよく言ったように、機能ブランチの必要性を克服し、開発者にクリーンに統合するように教える方が良いでしょうが、それはより長いプロセスであり、これ以上触れない多くのレガシーシステムパーツでは結果は明確ではありません。

私の2セント