コース受講生向けに用意された記事の翻訳 「DevOps の実践とツール」 OTUS教育プロジェクトで。

モノリポジトリを選択する必要があります。モノリポジトリがチーム内で促進する行動は、特にチームが成長するにつれて透明性と責任の共有となるためです。 いずれにせよ、ツールに投資する必要がありますが、デフォルトの動作がコマンドで必要な動作である方が常に良いです。

なぜこのことについて話しているのでしょうか?

マット・クラインが記事を書きました 「モノレポス：やめてください！」  (翻訳者注: ハブレに関する翻訳 「モノリポジトリ：やめてください」）。 私はマットが好きです。彼はとても賢いので、彼の視点を読むべきだと思います。 彼は最初にツイッターにアンケートを投稿した。

翻訳：
今年の元旦、私はモノリポジトリがいかにばかげているかについて議論するつもりです。 2019年は静かに始まりました。 この精神に基づいて、私はあなたにアンケートを提案します。 大のファンは誰ですか？ サポーター:
- モノレポ
- さび
- 不正な世論調査 / 両方

私の答えは、「私は文字通りその両方です」でした。 Rust がいかに麻薬であるかについて話す代わりに、モノリポジトリについて彼が間違っていると私が考える理由を見てみましょう。 あなた自身について少し。 私は Chef Software の CTO です。 当社には約 100 人のエンジニアがおり、約 11 ～ 12 年前のコード ベースと 4 つの主要製品があります。 このコードの一部はポリリポジトリ (私の開始位置) にあり、一部はモノリポジトリ (私の現在の位置) にあります。

始める前に: ここでの議論はすべて、両方の種類のリポジトリに当てはまります。 私の意見では、あるタイプのリポジトリを別のタイプのリポジトリではなく選択する必要がある技術的な理由はありません。 どのようなアプローチでも機能させることができます。 それについて喜んで話しますが、一方が他方より優れているという人為的な技術的理由には興味がありません。

私はマットの指摘の最初の部分に同意します。

なぜなら、大規模な場合、モノリポジトリはポリリポジトリが解決するのと同じ問題をすべて解決しますが、同時にコードを密結合することを強いられ、バージョン管理システムのスケーラビリティを高めるために信じられないほどの努力が必要になるからです。

モノリポジトリを選択するかポリリポジトリを選択するかに関係なく、同じ問題を解決する必要があります。 リリースはどうやってリリースするのですか？ アップデートに対するあなたのアプローチは何ですか? 下位互換性はありますか? プロジェクト間の依存関係はありますか? どのような建築様式が許容されますか? ビルドとテストのインフラストラクチャをどのように管理していますか? リストは無限にあります。 そして成長するにつれてそれらすべてを解決していきます。 無料のチーズはありません。

Matt の議論は、私が尊敬する多くのエンジニア (およびマネージャー) が共有する見解と似ていると思います。 これは、コンポーネントに取り組んでいるエンジニア、またはコンポーネントに取り組んでいるチームの観点から行われます。 次のようなことが聞こえます。

• コードベースはかさばります。これだけのジャンクは必要ありません。
• 必要のないジャンクをすべてテストしなければならないので、テストはさらに難しくなります。
• 外部依存関係を扱うのはさらに困難です。
• 独自の仮想バージョン管理システムが必要です。

もちろん、これらの点はすべて正当化されます。 これはどちらの場合でも起こります。ポリリポジトリには、ビルドに必要なものに加えて、私自身のジャンクがあります...他のジャンクも必要になる場合があります。 そこで私はプロジェクト全体をチェックするツールを「単純に」作成します。 または、サブモジュールを含む偽のモノリポジトリを作成します。 ここを一日中歩き回ることができます。 しかし、Matt の議論は主な理由を見逃していると思います。私はそれをかなりひっくり返してモノリポジトリを支持しました。

コミュニケーションを促し、問題を明らかにする

リポジトリを分離すると、調整と透明性という事実上の問題が生じます。 これは、チームについての私たちの考え方 (特に個々のメンバーのチームについての考え方) に対応しています。つまり、私たちは特定のコンポーネントに対して責任を負っています。 私たちは比較的孤立して仕事をしています。 私のチームと私たちが取り組んでいるコンポーネントの境界は固定されています。

アーキテクチャが複雑になるにつれて、XNUMX つのチームだけでは管理できなくなります。 システム全体を頭の中に理解しているエンジニアはほとんどいません。 チーム B、C、D が使用する共有コンポーネント A を管理しているとします。チーム A はリファクタリング、API の改善、および内部実装の変更を行っています。 その結果、変更には下位互換性がありません。 どのようなアドバイスがありますか?

• 古い API が使用されている場所をすべて検索します。
• 新しいAPIが使えない場所はありますか？
• 他のコンポーネントを修正してテストして、壊れないことを確認できますか?
• これらのチームはあなたの変更を今すぐテストできますか?

これらの質問はリポジトリの種類とは無関係であることに注意してください。 チーム B、C、D を見つける必要があります。彼らと話し、時間を調べ、優先順位を理解する必要があります。 少なくとも私たちはそう願っています。

誰も本当にこれをやりたくありません。 これは、ただ API を修正するよりもはるかに面白くありません。 それはすべて人間的で厄介です。 ポリリポジトリでは、単に変更を加えて、そのコンポーネントに取り組んでいる人 (おそらく B、C、D ではない) に変更を渡してレビューしてもらい、次に進むことができます。 チーム B、C、D は今のところ現在のバージョンをそのまま使用できます。 あなたの才能に気づいたとき、彼らは新たになるでしょう！

モノリポジトリでは、デフォルトで責任が移されます。 チーム A はコンポーネントを変更し、注意しないとすぐに B、C、D を破壊します。これにより、B、C、D が A の玄関に現れ、なぜチーム A がアセンブリを破壊したのか疑問に思います。 これにより、A は上記のリストをスキップできないことを学びます。 彼らはこれから何をするのかについて話し合わなければなりません。 B、C、Dは移動できますか？ B と C は可能だが、D が古いアルゴリズムの動作の副作用と密接に関係していた場合はどうなるでしょうか?

次に、この状況からどうやって抜け出すかについて話し合う必要があります。

1. 複数の内部 API をサポートし、D が使用を停止できるまで古いアルゴリズムを非推奨としてマークします。
2. 複数のリリース バージョン (XNUMX つは古いインターフェイス、もう XNUMX つは新しいインターフェイス) をサポートします。
3. B、C、D が同時にそれを受け入れることができるまで、A の変更のリリースを遅らせます。

1 つ、複数の API を選択したとします。 この場合、コードは XNUMX つあります。 古くて新しい。 状況によっては非常に便利です。 古いコードをチェックインして戻し、非推奨としてマークし、D チームと削除スケジュールに同意します。ポリ リポジトリとモノ リポジトリで基本的に同じです。

複数のバージョンをリリースするには、ブランチが必要です。 これで、A1 と A2 という 2 つのコンポーネントができました。 チーム B と C は A1 を使用し、D は A1 を使用します。 D を進める前にセキュリティ更新やその他のバグ修正が必要になる可能性があるため、すべてのコンポーネントをリリースの準備ができている必要があります。 ポリリポジトリでは、これを有効期間の長いブランチに隠すことができ、快適です。 モノリポジトリでは、コードが新しいモジュールで作成されるように強制します。 チーム D は引き続き「古い」コンポーネントに変更を加える必要があります。 ここで私たちが支払っているコストは誰でもわかります。コードの量は 2 倍になり、AXNUMX と AXNUMX に適用されるバグ修正は両方に適用する必要があります。 ポリリポジトリでの分岐アプローチでは、これはチェリーピックの背後に隠れます。 重複がないのでコストが安くなると考えています。 実際的な観点から見ると、コストは同じです。どちらか XNUMX つを削除できるまで、ほぼ同一の XNUMX つのコードベースを構築、リリース、保守することになります。 違いは、モノリポジトリでは、この問題が直接的で目に見えることです。 これはさらに悪いことですが、それは良いことです。

ついにXNUMXつ目のポイントに到達しました。 発売遅延。 A が行った変更により、チーム A の生活が改善される可能性があります。重要ではありますが、緊急ではありません。 ただ遅らせることはできますか？ ポリリポジトリでは、これをプッシュしてアーティファクトを固定します。 もちろん、このことはチーム D に伝えています。追いつくまでは古いバージョンを使い続けてください。 これにより、あなたは臆病者を演じるようになります。 チーム A は、チーム D が使用しているバージョンがどんどん古くなっているという事実を無視して、コンポーネントの作業を続けます (それはチーム D の問題であり、彼らは愚かです)。 一方、チーム D は、コードの安定性に対するチーム A の不注意な態度について、たとえそれについて話すとしても、あまり良くありません。 月日が経ちます。 最後に、チーム D は更新の可能性を検討することにしましたが、A にはさらなる変更しかありませんでした。 チーム A は、いつ、どのように D を壊したのかほとんど覚えていません。アップグレードはさらに苦痛であり、さらに時間がかかります。 これにより、優先順位スタックの下位に送信されます。 A でセキュリティ上の問題が発生し、ブランチを作成せざるを得なくなる日まで。 チーム A は時間を遡って、D が安定していた時点を見つけ、そこで問題を修正し、リリースの準備を整えなければなりません。 これは人々が行う事実上の選択であり、これまでで最悪の選択です。 チームAもチームDもお互い無視できれば良さそうです。

モノリポジトリでは、XNUMX 番目は実際にはオプションではありません。 XNUMX つの方法のいずれかで状況に対処する必要があります。 XNUMX つのリリース ブランチを持つ場合のコストを確認する必要があります。 下位互換性を損なうアップデートから身を守る方法を学びましょう。 しかし最も重要なことは: 難しい会話を避けることはできません。

私の経験では、チームが大きくなると、システム全体を念頭に置くことができなくなりますが、それが最も重要な部分です。 システム内での不和の可視性を改善する必要があります。 チームが自分たちのコンポーネントから目をそらし、他のチームや消費者の仕事に目を向けるように積極的に取り組む必要があります。

はい、ポリリポジトリの問題を解決しようとするツールを作成できます。 しかし、大企業で継続的デリバリと自動化を教えてきた私の経験から、追加のツールを使用しないデフォルトの動作が期待される動作であることがわかります。 ポリリポジトリのデフォルトの動作は分離であり、それが重要です。 モノリポジトリのデフォルトの動作は責任の共有と透明性であり、それが重要です。 どちらの場合も、粗いエッジを滑らかにするツールを作成します。 リーダーとして私は毎回モノリポジトリを選択します。ツールは私が望む文化を強化する必要があり、文化は小さな意思決定とチームの日々の仕事から生まれるからです。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

最大の熱狂者は誰ですか? サポーター:

• モノレポ

• さび

• 不正な世論調査 / 両方

33 人のユーザーが投票しました。 13名のユーザーが棄権した。

出所： habr.com