[解決済み] 継続的インテグレーションにおける複数ブランチの扱い

質問

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

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

• ブランチごとに複数のジョブ (ここでは Jenkins/Hudson について) を設定する。
  • 追加ジョブを管理するためのツールを書く
    • ジョブの一括作成/変更/削除
    • ブランチごとのジョブのカスタム設定（SCMのURL、デプ管理レポの重複など）
    • シェルツール、Antスクリプト、Jenkins CLIを使ってこの問題に取り組んでいる人の例もあります。参照してください。
      1. http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
      2. 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
      3. http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html
      4. hudsonジョブを自動的に設定または作成する
  • CIクラスタに負荷をかけることになる
  • 開発者へのフィードバックサイクルが遅くなる (インフラが新しい負荷を処理できない場合)
• 2 つのブランチごとに複数のジョブセット (開発 & 安定版)
  • 2つのセットを手動で管理 (ジョブの conf を変更したら、もう一方のブランチでも必ず変更する)
    • 面倒だが、少なくとも管理する数は少ない
  • 他の余分なブランチは、開発チームにプッシュされる前に完全なテストスイートを得ることができません。
  • 不満足な開発者たち。なぜ開発者がCIのスケーリング問題を気にする必要があるのか。彼は単純な要求を持っています、私がブランチするとき、私のコードをテストしたいのです。単純なことです。

開発者にカスタムブランチのCIを提供するには、Jenkins用の特別なツール(APIやシェルスクリプトなど？)とスケーリングが必要なようですね。あるいは、DEVへのマージを頻繁に行い、カスタムブランチではCIを使用しないようにすることもできます。あなたはどちらを取るか、または他のオプションがありますか？

どのように解決するのですか？

CIを拡張するということは、メインラインと一緒にすべての機能ブランチを処理するためにCIサーバの使用を拡張するということです。ブランチ内の開発者は、CIジョブが含む自動テストのすべての利点を得られるので、当初はこれは良いアプローチに見えます。しかし、CIサーバーのジョブを管理する上で問題に直面します（あなたが発見したように）。確かにCIサーバを使用していますが、すべての開発者のコードを継続的に統合しているわけではありません。

本当のCIを行うとは、すべての開発者がメインラインに定期的にコミットしていることを意味します。言うのは簡単ですが、難しいのは、アプリケーションを破壊することなくそれを行うことです。私は、以下を見ることを強くお勧めします。 継続的デリバリー を、特に アプリケーションをリリース可能な状態に保つ のセクションを参照してください。 第13章: コンポーネントと依存関係の管理 . 主なポイントは以下の通りです。

• 新しい機能は完成するまで隠す（A.K.A 機能トグル ).
• すべての変更を一連の小さな変更として段階的に行い、それぞれをリリース可能にします。
• コードベースへの大規模な変更を行うために、抽象化によるブランチを使用します。
• コンポーネントを使用して、異なる速度で変化するアプリケーションの部分を切り離します。

これらは、抽象化によるブランチを除けば、かなり自明なことです。これは単なる空想上の用語です。

1. 変更する必要があるシステムの部分に対する抽象化を作成します。
2. 抽象化レイヤーを使用するために、システムの残りの部分をリファクタリングします。
3. 新しい実装を作成します。これは、完成するまで本番のコードパスの一部ではありません。
4. 新しい実装にデリゲートするために、抽象化レイヤーを更新します。
5. 古い実装を削除します。
6. 抽象化レイヤーが適切でなくなった場合、削除します。

の次の段落は ブランチ、ストリーム、継続的インテグレーション セクションの 第14章: 高度なバージョン管理 で、その影響をまとめています。

インクリメンタルなアプローチは、ブランチを作成し、リアーキテクチャや新しい機能の開発に勢いよく飛び込むよりも、確かに多くの規律と注意、そして実際により創造性を必要とします。しかし、それは、変更がアプリケーションを破壊するリスクを大幅に削減し、あなたとあなたのチームのマージ、破壊の修正、およびアプリケーションをデプロイ可能な状態にする時間を大幅に節約します。

機能ブランチを放棄するにはかなりのマインドシフトが必要で、常に抵抗を受けるでしょう。私の経験では、この抵抗は、開発者がメインラインにコードをコミットすることを安全だと感じないことに基づいており、これは妥当な懸念事項です。このような抵抗は、上記のテクニックに関する知識、自信、経験の不足、そして自動テストに対する自信のなさから来るものです。前者は、トレーニングや開発者のサポートで解決できます。後者は対処するのがはるかに難しい問題ですが、ブランチは実際の安全性を高めるものではなく、開発者が自分のコードに十分な自信を持つまで問題を先延ばしにするだけです。