作業中の開発環境で過去のプロジェクトを維持する効果的な方法は？

過去のプロジェクトを実行したいときはいつでも、それを見つけることができるようになり、実行できるようにすべてをセットアップするまでに時間がかかることがわかりました。

たとえば、Linuxで作成したpythonプロジェクトがあり、Linuxに簡単にインストールできるソフトウェアパッケージに依存していますが、使用しているLinux VMはもうありません。私の他のプロジェクトのいくつかは、Webサーバー構成、PATH変数、sdk、IDE、OSバージョン、デバイスなどの他の変数に依存しています。

誰かがこの問題を処理する効果的な方法を持っていますか？今のところ、ソースコードのバックアップを維持することだけに関心がありますが、動作中の開発環境を再構築することは難しく、動作中の開発環境を維持することも困難です。

過去に行ったことは、物理的な開発マシンをVMに変換するか、既にVMである場合は将来の使用のために保持することです。ディスク領域の使用量ほど効率的ではありませんが、領域は安価です。また、このプロセスは、必要に応じて将来環境を再構成しようとするよりも、時間的にはるかに安価です。

私の現在のお気に入りの方法論は、プロジェクトに必要なすべての依存関係をインストールし、ソースをダウンロードし、すべてを接続するスクリプトを維持することです。一部のスクリプトには2つのモードがあります。1つは実稼働用で、通常はもう1つのモードである開発のほとんどのサブセットです。

スクリプトを使用してインストールするのに約5分しかかからない環境もあります（その場合、午前中に職場に到着したときにプロジェクトスクリプトをデプロイするターゲットOSの新規インストールでローカルVMを保持し、すべてのコーディングを行います）そのVMインスタンスの関連作業。離れる前に、すべての変更をgit経由で物理マシンまたは中央リポジトリにプッシュし、VMを終了します。

環境のセットアップに時間がかかる場合（長時間のインストール、ダウンロードする大きなファイルなど）、私は上記の手順を週に1回実行します。

利点は、新しいマシンや実稼働サーバーへの展開が非常に簡単であり、すべてスクリプトに文書化され、スクリプトが頻繁に検証されることです。

説明している概念は構成管理です。これは、環境を特定、記録、バージョン/追跡、および報告する方法です。多くの場合、バージョン管理とビルド管理に強く関連するタスクですが、同じ概念と同じ処理およびストレージメカニズムを使用している場合でも、多くの場合、別個の戦略を必要とするほど明確です。

構成管理は、作業環境の制御を維持するのに役立つほか、ソフトウェアが使用されるさまざまな作業環境の記録を確立するのにも役立ちます（前述の開発に加えて、テスト/ QA、通常のお客様への展開、特別な考慮または特別な構成が必要なお客様への展開）またはプロパティの作成など）。

前述したように、これは多くの場合、ソースバージョン管理と一致するタスクであり、多くの場合、構成管理データはドキュメントとソースリポジトリの両方でソースの隣にあります。必ずしもそうである必要はありませんが、しばしば利便性の問題です。

構成管理のいくつかの側面の自動化は、近年大幅に改善されました。構成管理を促進する方法としてスクリプトが提案されたいくつかの回答とコメントがあり、スクリプトは再現可能な結果を​​達成するのに役立つ良い回答ですが、多くの場合、手作りのスクリプト自体は一貫性がなく不完全です。これが改善された1つの方法は、自動プロビジョニングを使用することです。パペットやシェフなどのシステム特定のユーザーまたはマシンまたは特定のタスクプロファイルのソフトウェアコンポーネントとシステムを指定し、完全なマシンまたは環境をセットアップするためのハンドオフアプローチを可能にする「レシピ」を提供します。基本的にはソフトウェア配布リポジトリの概念を取り入れ、システムに必要なソフトウェアのパッケージだけでなく、各パッケージに固有の構成プロファイルも提供するように拡張および一般化して、お客様に適した方法で使用できるようにします。状況。

Vagrantはこれをわずかに異なる方向に取り、仮想マシンの定義をすばやくスピンアップする方法を提供します。これにより、VMは仮想ソフトウェアとハ​​ードウェアを自動的にプロビジョニングでき、ハードウェアの特定の表現を再現する便利な方法であることが証明できますソフトウェアのユーザーが使用する環境。

各システム（およびバリエーション）のセットアップには少し時間がかかりますが、リロードと再構成のタスクが一般的なタスクであることがわかった場合、明確な価値があります。

Dockerは良い選択肢です。dockerfileを使用して、必要なVMのマニフェストとして機能できます。画像を保存する必要はありません。必要な画像がダウンロードされます。また、独自のイメージを使用できるため、独自のベースイメージを作成し、環境に必要なコンポーネントを追加できます。

dockerを使用すると、ワークフローの他の部分も改善できます。

• 作成された環境は、プロジェクトと同じCVSに配置できます。これにより、バージョン管理された環境が得られます（ニート！）
• Dockerを使用してライブ環境をプロビジョニングし、本番環境でプロジェクトを起動する際の頭痛を軽減できます。
• 他の人があなたと協力し始めたら、彼らが必要とするのは、その巨大な環境設定をロードするためのdockerfileだけです。

したがって、VMの使用に関するここでのアイデアは部分的にしか正しくありません。HDDがますます大きくなっていることは知っていますが、それがあなたが持っているすべてのスペースを使い果たす理由ではありません。また、VM環境が内部でより多くのHDDスペースを必要とする場合、これは少し難しい場合があり、再構築する必要がある可能性があります。ファイルサイズは問題ではないかもしれませんが、通常のDSL接続で5Goを介して送信する必要がある場合、インターネット速度が依然としてボトルネックになります。

ほとんどのシステム（言語、ランタイム、またはオペレーティングシステム）には、ソフトウェアと構成をインストールする標準化された方法があるため、それらを使用してみてください。といった：

• MavenまたはGradle for Java
• PerlのCPAN
• RedHat / Fedoraのrpm
• Linuxのdpkg / apt-get
• Windows用のMSIパッケージ

次に、インストールする必要があるもの/必要な手順を正確に説明するインストール手順を作成します。

• インストールすることを前提とする短い説明を提供します（ベースOS、Java / Perl / Pythonなどのベースランタイム...）
• 必要なインストールを実行する短いスクリプトを作成します（Mavenなどのツールの1回の呼び出しのみが理想的です）
• 新規インストール（VMなど）でこれをテストします

その後、環境を再作成できるはずです。また、他の人も環境を再作成できるはずです（これがソロプロジェクトでない場合は重要かもしれません）。

必要なインストールパッケージをどこかに保存する必要がある場合や、ダウンロード手順を含めるだけの場合もあります（システムがapt-getやMavenなどを追跡しない限り）。それはあなたがパッケージの提供者をどれだけ信頼しているかに依存します-おそらくDebianのコアパッケージを保存する必要はないでしょうが、いくつかの小さなフリーソフトウェアプロジェクトでは、それは良い考えかもしれません。

VMソリューションも動作しますが、おそらく短期的には動作が少なくなります（VMを保持するだけです）。ただし、環境を変更する場合など、このソリューションの方が柔軟性が高いと感じています。