作業中の開発環境で過去のプロジェクトを維持する効果的な方法は？
過去のプロジェクトを実行したいときはいつでも、それが見つかるまで、またすべてがセットアップされてから実行できるようになるまでには長い時間がかかります。
たとえば、python Linuxで作成したプロジェクトがあり、それはLinuxに簡単にインストールできるソフトウェアパッケージに依存していますが、LinuxはもうありませんVM =私が使用していました。他のいくつかのプロジェクトは、Webサーバー構成、PATH変数、SDK、IDE、OSバージョン、デバイスなどの他の変数に依存しています。
誰かがこの問題を効果的に処理する方法を持っていますか？現在のところ、ソースコードのバックアップを維持することにのみ関心があります作業中の開発環境を再確立することは難しく、作業中の開発環境を維持することも困難です。
過去に私が行ったことは、物理開発マシンをVMに変換するか、それがすでにVMである場合は、将来の使用のために保持することです。ディスクスペースの使用量としては効率的ではありませんが、スペースは安価です。また、このプロセスは、必要に応じて将来的に環境を再構成するよりも時間的にはるかに安価です。
私の現在のお気に入りの方法論は、プロジェクトに必要なすべての依存関係をインストールし、ソースをダウンロードし、すべてを接続するスクリプトを維持することです。一部のスクリプトには2つのモードがあります。1つは本番用で、通常は他のモードのサブセットです。開発です。
一部の環境では、スクリプトを使用してインストールするのに約5分しかかかりません。その場合、ローカルにVMを保持します。ターゲットOSの新規インストールを使用して、仕事に到着したときにプロジェクトスクリプトを展開します。午前中-そして、そのVMインスタンスでコーディング関連のすべての作業を行います。去る前に、gitを介してすべての変更を物理マシンまたは中央リポジトリにプッシュし、VMを終了します。
環境のセットアップに時間がかかる場合（インストールの実行に時間がかかる、ダウンロードする大きなファイルなど）、上記の手順を週に1回実行します。
利点は、新しいマシンや本番サーバーへの展開が非常に簡単で、すべてスクリプトに記載されており、スクリプトが頻繁に検証されることです。
説明している概念は構成管理です。これは、環境を識別、記録、バージョン/追跡、および報告する方法です。多くの場合、これはバージョン管理とビルド管理に強く関連するタスクですが、同じ概念と同じ処理およびストレージメカニズムを使用している場合でも、個別の戦略を必要とすることがよくあります。
構成管理は、作業環境を制御し続けるのに役立つだけでなく、ソフトウェアが使用されるさまざまな作業環境の記録を確立するのにも役立ちます（前述の開発に加えて、テスト/ QA、通常の顧客への展開、特別な考慮または特別な構成が必要な顧客への展開）。またはプロパティを構築するなど）。
私が言ったように、これはしばしばソースのバージョン管理と一致するタスクであり、多くの場合、構成管理データは、ドキュメントとソースリポジトリの両方でソースの隣にあります。必ずしもそうである必要はありませんが、多くの場合、利便性の問題です。
構成管理のいくつかの側面の自動化は、近年大幅に改善されました。いくつかの回答とコメントは、構成管理を促進する方法としてスクリプトを提案しました。スクリプトは再現可能な結果を達成するのに役立つ良い回答ですが、多くの場合、自分で作成したスクリプトは一貫性がなく、不完全です。これが改善されたそのような方法の1つは、自動プロビジョニングによるものです。 puppet または chef のようなシステムは、特定のユーザーまたはマシンまたは特定のタスクプロファイル用のソフトウェアコンポーネントとシステムを指定し、設定に手を加えないアプローチを可能にする「レシピ」を提供するのに役立ちます完全なマシンまたは環境をセットアップします。基本的に、ソフトウェア配布リポジトリの概念を採用し、システムに必要なソフトウェアのパッケージだけでなく、各パッケージに固有の構成プロファイルも提供するように拡張および一般化して、適切な方法で使用できるようにします。状況。
Vagrant は、これを少し異なる方向に導き、a VMで仮想ソフトウェアとハードウェアを自動的にプロビジョニングできるように、仮想マシン定義をすばやく起動する方法を提供します。また、ソフトウェアのユーザーが使用するハードウェア環境の特定の表現を再現するための便利な方法であることが証明できます。
各システム（およびバリエーション）のセットアップには少し時間がかかりますが、リロードと再構成のタスクが一般的なタスクであることがわかった場合、明確な価値があります。
Docker は適切なオプションです。 dockerfileを使用して、VM=のマニフェストとして機能することができます。イメージを保存する必要はありません。必要なイメージをダウンロードします。また、独自のイメージを使用できます。そのため、独自のベースイメージを作成し、環境に必要なコンポーネントを追加できます。
Dockerを使用すると、ワークフローの他の部分も改善できます。
- 作成された環境はプロジェクトと同じCVSに置くことができ、バージョン管理された環境を提供します（きちんと！）
- Dockerを使用してライブ環境をプロビジョニングすることで、プロジェクトを本番環境で立ち上げる際の問題を軽減できます。
- 他の人があなたと一緒に作業を始めた場合、必要なのは、その巨大な環境設定をロードするためのdockerfileだけです。
したがって、VMの使用に関するここでのアイデアは部分的に正しいだけです。HDDがどんどん大きくなっていることは知っていますが、すべてのスペースを使い果たすのは理由ではありません。また、a = VM環境は内部でより多くのHDDスペースを必要としますが、これは少しトリッキーであり、1つを再構築する必要がある可能性があります。ファイルサイズは問題ではないかもしれませんが、インターネット速度が依然としてボトルネックになります。通常のDSL接続で5Go以上を送信する必要があります。
ほとんどのシステム（言語、ランタイム、オペレーティングシステム）には、ソフトウェアと構成をインストールするための標準化された方法があるため、それらを使用してみてください。といった：
- MavenまたはGradle for Java
- Perl用CPAN
- redHat/Fedoraのrpm
- linuxの場合はdpkg/apt-get
- WindowsのMSIパッケージ
次に、インストールする必要があるもの/必要な手順を正確に説明するインストール手順を作成します。
- インストールすると想定しているもの（ベースOS、ベースランタイム、たとえばJava/Perl/Python ...）
- 必要なインストールを実行する短いスクリプトを作成します（理想的には、Mavenのようなツールを1回だけ呼び出す）。
- 新規インストール（VMなど）でこれをテストする
そうすれば、環境を再作成できるはずです。そしてothersもそうできるはずです（これが単独のプロジェクトでない場合は重要かもしれません）。
必要なインストールパッケージをどこかに保存する必要がある場合や、ダウンロードの手順を含めるだけの場合もあります（システムがapt-getやMavenなどを追跡しない限り）。それは、パッケージのプロバイダーをどれだけ信頼するかに依存します-おそらくコアDebianパッケージを保存する必要はありませんが、いくつかの小さなフリーソフトウェアプロジェクトでは、それは良い考えかもしれません。
VMソリューションも機能し、おそらく短期的にはあまり機能しません（VMを保持するだけです）。ただし、このソリューションは、たとえば環境を変更する場合などに、より柔軟性があると思います。