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

Question

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

これまでのところ、私がとることができる主なアプローチは2つあることがわかりました（または他の方法もありますか？）。

ブランチごとの複数のジョブセット（ここではJenkins/Hudsonについて話しています）
- 余分なジョブを管理するツールを作成します
  - ジョブの一括作成/変更/削除
  - ブランチごとの各ジョブのカスタム設定（SCM url、dep management repos duplications）
  - シェルツール、Antスクリプト、およびJenkins CLIでこの問題に取り組む人々の例。見る：
- CIクラスターの負荷が増加します
- 開発者のフィードバックサイクルが遅くなります（インフラストラクチャが新しい負荷を処理できない場合）
2つのブランチごとに複数のジョブセット（開発および安定）
- 2つのセットを手動で管理します（ジョブのconfを変更した場合は、もう一方のブランチでも必ず変更してください）
  - PITA、しかし少なくとも管理することは少ない
- 他の余分なブランチは、devにプッシュされる前に完全なテストスイートを取得できません。
- 満足していない開発者。開発者がCIスケーリングの問題に注意する必要があるのはなぜですか。彼は単純なリクエストを持っています。私がブランチをするとき、コードをテストしたいと思います。シンプル。

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

Tom Howard · Accepted Answer

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

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

終了するまで新機能を非表示にします（A.K.A Feature Toggles ）。

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

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

コンポーネントを使用して、異なるレートで変化するアプリケーションの部分を分離します。

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

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

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

新しい実装を作成します。これは、完了するまで製品コードパスの一部ではありません。

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

古い実装を削除します。

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

Chapter 14：Advanced Version ControlのBranches、Streams、Continuous Integrationセクションの次の段落は、影響をまとめたものです。

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

機能ブランチを放棄するにはかなりの心の転換が必要であり、常に抵抗を受けます。私の経験では、この抵抗は、開発者がメインラインでコードをコミットしても安全だと感じていないことに基づいています。これは合理的な懸念事項です。これは通常、上記の技術に関する知識、自信、または経験の不足に起因するものであり、自動テストに自信がない可能性もあります。前者は、トレーニングと開発者のサポートで解決できます。後者は対処するのがはるかに難しい問題ですが、分岐は追加の本当の安全性を提供しません。開発者がコードに十分に自信を持つまで問題を延期します。

Bernard · Answer

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

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

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

Anton Safonov · Answer

Dev + stableブランチを選択します。まだカスタムブランチが必要で、負荷を恐れている場合は、これらのカスタムブランチをクラウドに移動して、開発者が自分で管理できるようにしてください。 http://cloudbees.com/dev.cb これは、コースケが現在いる会社です。 Eclipse Toolingもあります。したがって、Eclipseを使用している場合は、dev envに緊密に統合されます。

prosailor · Answer

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

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

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

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

私の2セント