「ビルド/スラッグのサイズが大きい」とよく聞かれます(人々からだけでなく、有益なCLIからも)。これは特に、ビルドのサイズが0.5〜2 GBの場合に当てはまります。
なぜ(またはどのような状況で)ビルドサイズがこのような懸念事項なのですか?
注:私が尋ねる理由は、ストレージやコンピューティングなどのリソースが以前に比べて比較的安価であると考えているためです。したがって、どちらかと言えば、ビルドサイズは以前ほど問題にはならないと思います
「ビルド/スラッグのサイズが大きい」とよく聞かれます(人々からだけでなく、有益なCLIからも)。これは特に、ビルドのサイズが0.5〜2 GBの場合に当てはまります。
なぜ(またはどのような状況で)ビルドサイズがこのような懸念事項なのですか?
注:私が尋ねる理由は、ストレージやコンピューティングなどのリソースが以前に比べて比較的安価であると考えているためです。したがって、どちらかと言えば、ビルドサイズは以前ほど問題にはならないと思います
回答:
懸念としてビルドサイズの問題を提起した場合、通常は「サイズが大きいため、保存するのにコストがかかります」という問題ではありません。
大規模なビルドの主な問題は次のとおりです-
私は4つのdevopsメトリックをサブスクライブします。
通常、大きなアーティファクトはこれらの各メトリックに問題を引き起こし、これらのメトリックはどれも実際にはストレージのコストに実際には関係していません。それは安価であり、時間がかかるためです。
Evgenyの回答をさらにいくつかの例で補足します。
ビルドサイズの意味は少し重要かもしれません。
構築するアーティファクトのサイズ(個別に、またはそれらを組み合わせたサイズ)の場合-これらの操作にサイズ制限があり、それらを超えると、アーティファクトの格納または使用/展開操作で問題になる可能性があります。たとえば、Google App Engineアプリにはこのようなデプロイ制限があり、到達したデプロイが失敗する場合は、Google App Engineへのデプロイ時のエラーを参照してください。
ビルドを実行するワークスペースのサイズである場合、ワークスペース管理の観点から問題になる可能性があります。2Gでも重要な場合があります。たとえば、RAMが少ないマシンのRAMファイルシステムでビルドしている場合です。しかし、一部のビルドはもっと大きくなる可能性があります-(ほとんどのサーバーディスクが1T未満の場合)500G以上のワークスペースを処理する必要がありました。
ビルドがCI / CDパイプラインの一部である場合、ビルドサイズが大きいほど、パイプラインの実行時間は長くなります(実際のビルドを実行し、該当する場合は、アーカイブ、テストのためにデプロイ、失敗した場合の分析、クリーンアップ、等)-あなたの全体的な開発が遅い/リスクが高い/コストがかかるかもしれません。
ハードリミットに達した場合は、クリエイティブに対処する必要があります(常にシンプル/可能であるとは限りません)。それが単なるパフォーマンス/コストヒットの場合は、それを受け入れてそれと共存するか、部分的または段階的に対処するかを選択できます。
以下を区別することは価値があります。
実際に遭遇する非常に具体的な問題を追加します。これは、私たちが現在苦しんでいる悪いアーキテクチャの副作用です。
私たちのビルドは大きく、多くの依存関係をロードする必要があるため、単純にすべてを組み合わせるだけで非常に長い時間がかかります。1つの大きなモノリスではなく、マイクロサービスアーキテクチャへのアプローチとして、ビルドを多数の小さなビルドに分割して久しいはずです。
モノリスのすべてのテストの実行には約45分かかり、当面はCI環境をブロックします。
これは非常に負荷が大きく、時間がかかるため、現在、複数のビルドを互いに並行して実行することは不可能です。
したがって、私の前のポスターがすでにより理論的なレベルで述べているように、これは、大規模なビルドがハードドライブ上により多くのスペースを必要とする以外に、潜在的な(そしておそらく)副次的な影響を示すはずです。