クラウド ベースのソリューションを想像してみてください。デプロイされたコードのかなりの部分が社内で開発されています。私の質問は、いつでもソース コードから直接任意のバージョンをビルドできる内部コードにアーティファクト リポジトリを使用するポイントは何ですか?
つまり、Nexus のようなアーティファクト リポジトリを追加してビルド アーティファクトをデプロイメントにフィードするよりも、コードから目的のアーティファクト バージョンを簡単にビルドできるように、ビルド サーバーに時間を費やす方が理にかなっているのではないでしょうか?
理論的にはそうです、あなたが確信できるなら
EDIT 実際には、Mark O'Connerが指摘しているように、通常、2つのビルドは前者に応じてタイムスタンプとチェックサムが含まれているため、通常は同一ではありません。ビルド中に何らかの方法で手動で修正するか、ビルド コンピューターで時間とタイミングを正確に再現する必要があります。
そうしないと、特定の成果物を (正確に) 再構築できないという状況に直面する可能性があります。安全な場所に保管するために、すべてを公開することを好みます。
Continuous Deliveryの本では、バイナリを複数回ビルドすることをアンチパターンと呼んでいます。
このアンチパターンは、2 つの重要な原則に違反しています。1 つ目は、デプロイ パイプラインの効率を維持して、チームができるだけ早くフィードバックを得られるようにすることです。特に大規模なシステムでは時間がかかるため、再コンパイルはこの原則に違反します。2 番目の原則は、健全であることがわかっている基盤の上に常に構築することです。本番環境にデプロイされるバイナリは、受け入れテスト プロセスを経たものとまったく同じである必要があります。実際、多くのパイプラインの実装では、作成時にバイナリのハッシュを保存し、バイナリは、プロセスの後続のすべての段階で同一です。
厳重に規制されたドメインでは、ハッシュによるバイナリ等価チェックも監査目的で重要になる場合があります。