本番環境で使用しない場合に、ソフトウェア開発プロセスでdockerを使用する理由は何ですか？
Docker は、ソフトウェア開発者の大規模なチーム（100）で私の職場の問題を解決する可能性がたくさんあり、私の職場の問題を解決するために使用されます。これも：
- ジョブを実行できる Dockerホストのクラスター がある
- CIエージェントはDockerイメージとして実行されます 必要に応じて水平方向にスケールアップできます（すべてのビルドが完全にクリーンで一貫していることを保証します）。
- Android、JS、およびJavaビルド用のさまざまなエージェントを専門化する
- 実行中 JUnitテストを並行して 複数のコンテナーに分散
- Sonar や [〜＃〜] npmjs [〜＃〜]running indocker （専用ホストで）バージョン管理チェックインを使用してCIパイプラインで簡単にアップグレードできます
フィードバックは私に戻ってきました：
これがうまく機能しているのは素晴らしいことですが、Dockerエコシステムを理解する 一部の人にとっては精神的な飛躍です 。 dockerを本番環境で実行しないことはすでに確立されているため、このツールで人材をスキルアップすることに投資する理由はないと思います。
私の質問は次のとおりです：製品開発でdockerを使用していない場合、ソフトウェア開発プロセスでdockerを使用する理由は何ですか？
ソフトウェア開発プロセスの一部としてdockerを使用する理由をいくつか示します（まだ本番環境では使用していません）。
- 一貫性のあるバージョン管理されたローカル展開環境-Dockerビルドをバージョン管理にチェックインし、スタックで共同作業できます。スタックを停止して開始することで、完全にクリーンな環境を得ることができます。
- チームメイトへの環境の配布のしやすさ-最近では、メンテナンスを開始する必要のある、まったく新しいソフトウェアスタックがありました。多数のソフトウェアをインストールするためのツールやプロセスを文書化する代わりに、Dockerでスタックを1回作成してチーム間で配布するだけで済みました。多くの場合、ドキュメントは忘れられ、新しいメンバーがチームに参加したときにのみテストされます。多くの場合、指示は機能しなくなります。
- CIビルドと自動テストで使用-ソフトウェアのローカルでのデプロイとテストに使用しているのと同じイメージが、CIでソフトウェアのビルドとテストに使用されます。これにより、誰かのローカル環境の癖に固有のバグが発生する可能性が低くなります。
- 仮想マシンよりも管理、変更、構築、配布が簡単です。
- 既存のイメージを拡張できるため、イメージを最初から構築する必要がありません。通常、一般的なソフトウェアパッケージで利用できるオープンソースのイメージがあります。