ウェブサイトのバージョン管理：dev / productionフロントエンドファイル

私は私たちのウェブサイトプロジェクトをバージョン管理するためのより良い方法を考えています。私はフロントエンドの開発者にすぎないので、VCSに関する深い知識はありません。

ワークフローは変化しており、過去のバージョン管理の習慣は時代遅れになっています。主な問題は、各Webサイトにフロントエンドファイルの2つの配列があることです。

開発環境（少ないファイル、非圧縮のjs、イメージなど）。「不正な」ビルド環境（すべて圧縮され、人間が読み取れないもの）。

ただし、ソースファイルを含むWebサイトを販売することはできません。まあ、それは完全に正しくないと感じています。

2つのリポジトリを持つソリューションがあります。1つはビルド、1つは開発で、gulpがビルドファイルをビルドディレクトリに送信します。しかし、それを維持するのは面倒であり、小さな会社では、それはそれほど素晴らしいとは思いません。それは多くのレポを作成し、人々はいくつかのレポで、時には1つのsvnレポでさえも管理しなければならず、問題が発生します。

したがって、同じsvn内のソースファイルとprodファイルの1つのリポジトリを持つソリューションもあります。ただし、Webサイトがローカルの開発サーバーから本番サーバーに移動するときに、ソースファイルを削除する必要があります（そのため、単一のリポジトリには、その場所、開発または本番に基づいて異なるファイルがあります）。私が聞いたことから、それは良くありません

バージョン管理システムに関して、不適切なフロントエンドワークフローを管理する正しい方法は何ですか？

ソース管理の基本的なルールの1つは、手動で作成したアーティファクトをリポジトリ（元のソースファイル）に配置するだけでよいということです。冗長性が生じるため、「コンパイル」または「生成」できるすべてのものをそこに格納する必要はありません。 。一つはでき（任意選択）手順は、それらが完全に自動化されない、またはビルドステップが再現する場合、目的をキャッシュするための出力が遅い再生する場合、レポに（時にはも呼ばれるアーチファクト）を中間出力/ビルドプロセスの一部を格納します。

したがって、devソースファイルから本番ファイルを生成する完全に自動化されたプロセスがある場合、（本番ファイルを作成するためのスクリプトと共に）devファイルをソース管理に置くだけで済みます。そうでない場合は、そのようなプロセスを確立します。ソースから生成された後、手動で本番ファイルをいじる必要がないことを確認してください。VCSから「直接」デプロイする場合は、devソースファイルをソース管理から引き出し、「誤解」を引き起こし、結果のファイルを1つのステップで本番環境に転送するデプロイスクリプトがあることを確認してください。

もちろん、ソース管理を「貧弱なバックアップ」または本番ファイルのキャッシュとしても使用したい場合は、この目的のために2番目のリポジトリを設定し、生成後に本番ファイル構造のコピーを配置できます。このリポジトリは開発に役立ちません。また、設定した後は、手動でメンテナンスする必要はありません。したがって、この「製品リポジトリ」にバックアップを作成するための手動の手順がないことを確認してください。バックアップを自動的に作成するデプロイスクリプトに必要な手順を含めてください。展開後の運用環境への手動変更を禁止できない場合は、個別のバックアップスクリプトを追加することを検討してください。このようにして、リソースが限られている場合でも、プロセスを保守可能な状態に保つことができます。

そして、はい、これは厳密に分離された2番目のリポジトリである必要があります。これは、開発リポジトリとは完全に異なる目的と異なるライフサイクルを持っているためです。別のプロセスであるソース管理ではなく、バックアップにのみ使用します。