モノレポ

CodepenのDevOpsの練習：モノリシックコードベースの退行の利点（Monorepo）

私は大きなDevOpsの専門家ではありませんが、CodepenはMonorepoに移行しています。これは、少なくとも私たちにとっては、複数の小さなコードベースを持つシステムよりも多くの利点があります。あなたの課題と結論は完全に異なるかもしれません。

ベン・ナデルの「なぜ私はマイクロサービスを統合するのか、InvisionのMonolithic Architectureに戻るのか」を読んだ後、私はこれを考えました。私たちの結論は似ていますが、彼はまったく異なる問題に直面していると言えます。

マイクロサービスは、技術的および人事問題を解決します

技術的な問題は、アプリケーションの側面がインフラストラクチャにあまりにも大きな負担をかける場合、それがユーザーエクスペリエンスの低下（UX）につながる可能性がある場合です。たとえば、画像処理には大量のCPUが必要です。このCPUが過負荷になっている場合、アプリケーションの他の部分に処理リソースがないようになる可能性があります。これは、システムの遅延に影響する場合があります。そして、状況がシステムの可用性に影響を与えるほど深刻な場合。

一方、人事の問題は、アプリケーションとはほとんど関係ありませんが、チームの組織化方法とはほとんど関係ありません。アプリケーションの特定の部分で作業する人が多いほど、開発と展開が遅くなり、間違いを犯す可能性が高くなります。たとえば、30人のエンジニアが同じサービスを「継続的に展開」（CD）にスクランブルしている場合、多くのキューが得られます。これは、製品を提供していた多くのエンジニアが実際にターンの展開を待っていることを意味します。

モノレポの利点（モノレポ）

• 世界を統一します。コードベースgit pullだけで、他の人と完全に同期して、完全な開発環境に必要なものをすべて持つことができます。
• 秩序整然に。 GitHubの操作の場所は混乱を引き起こしません。モノリシックコードベースのプルリクエストを行います。モノリシックコードベースで問題を開きます。これにより、情報が失われるようになるように分散したアクティビティが回避されます。
• コード共有。コードを共有できます。コードベース全体でユーティリティまたはコンポーネントを共有することは特に便利です。他のコードベースで使用するために共有セクションをNPMに公開してみましたが、ワークフローはコードを1か所に持っているのと比較して不器用です。
• 統一されたメンテナンス。コードベースは1つだけで、古いコードベースや無視されたコードベースはありません。私たちの小さなチームにとって、数十のコードベースを持つことは、それらのいくつかに古い時代遅れの依存関係、古いバージョンのノード、コードスタイルのチェック、および他のコードベースと同期していないルールなどのフォーマットなどがあることを意味します。

モノレポの欠点（モノレポ）

• 展開の複雑さ。コードベースを最初に分割する主な理由は、これらのコードベースのコードを異なる場所に展開する必要があることだと思います。これらは、いくつかのラムダまたは他のサーバーで個別のサービスを表す場合があります。単一のコードベースは、CI/CDなど、そのサーバー/サービスに固有のコンポーネントに簡単に接続することを意味します。

はい、私はこれが議論の余地があることを知っています。

私は本当に気にしません。エアフライヤー愛好家やクロスフィット愛好家のように、私はそれについてあまり厳しくなりません。これは、モノリシックコードベースに対するマットクラインの強力な議論です。

私はちょうど言った：これは私たちにとって非常に便利です。他の会社が違うことがわかります。請負業者と協力している企業は、モノリシックコードベース全体よりも少ないものにアクセスを制限したい場合があることがわかります。 Git Codebaseの管理が大きくなり、困難になる可能性があることがわかります。現在、これらのどれもCodepenの問題ではないため、モノリシックコードベースには利点があります。

以上がモノレポの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。