ドッカーのビルド中とその後のアプリケーションテストの実行の長所と短所は何ですか？

dockerfileはアプリケーション環境を作成します（例：env変数、apt-getを使用したライブラリーのインストールなど）。また、そのgitリポジトリからPythonアプリケーションコードをプルしてコピーします。

ただし、ビルドされたコンテナーでテストを実行するために、アプリケーションテスト（一部のユニット、一部の統合）をdocker RUNコマンド（例RUN /bin/bash -c "source activate cool_env; pytest"：）内に配置するか、CIスタック（例：Jenkins、Openshift）を使用してビルド後に配置するかについては、議論しています。

それぞれの長所と短所は何ですか？

ビルドとテストの段階ごとに個別のDockerファイルを作成するというJ.Doeの提案をサポートしています。このようなアプローチにより、次のことも可能になります。

• ビルドステージを再実行せずに、何らかの理由（既知の断続的な障害など）でテストステージを再実行します。
• 同じビルドを使用して複数の異なるテストステージを並行して実行します。たとえば、シリアル化されたテストで構成される単一の長いテストステージを実行する代わりに、パイプライン全体の速度を大幅に向上させることができます。

すべてを同じコンテナで実行すると...

PRO：インラインでテスト環境を構成するためのCasCの課題を解決しました

CON：コンテナが外部からの接続を受け入れないことを想像してください。痛い！

考えられる解決策：したがって、私はマルチステージのDockerベースの宣言型パイプラインを使用します。各ステージに1つのDocker環境があり、そこでアーティファクトがカスケードされます。