最近、Webアプリケーションのバージョン管理について同僚と話し合いました。
私はあなたがそれを全く必要とは思わない、そしてあなたがあなたの最新リリースがライブであることを確認するために健全性チェックが欲しいだけなら、私はおそらく日付（YYMMDD）で十分だと思う。
私は基地を離れていますか？ポイントが足りませんか？Webアプリケーションのバージョン番号を使用する必要がありますか
最近、Webアプリケーションのバージョン管理について同僚と話し合いました。
私はあなたがそれを全く必要とは思わない、そしてあなたがあなたの最新リリースがライブであることを確認するために健全性チェックが欲しいだけなら、私はおそらく日付（YYMMDD）で十分だと思う。
私は基地を離れていますか？ポイントが足りませんか？Webアプリケーションのバージョン番号を使用する必要がありますか
回答:
同じWebアプリケーションを複数の顧客に再販する場合、絶対にバージョン管理する必要があります。
1つの場所にしかインストールされていないWebサイトであれば、その必要性はそれほど大きくありませんが、それでも問題はないでしょう。あなたもタイムゾーンの問題などの影響を受けにくくなります。ライブラリバージョン1.0.2.25での問題の診断は、2010年11月3日午前11時15分にライブラリのビルドを探すよりもはるかに優れています。
アプリケーションのDLLのバージョン番号を自動化できれば、問題はありません。バージョンを追跡するのに役立ちます。
一般に、Webアプリはホストしている1つの場所でのみリリースされるため、デスクトップアプリケーションほど重要ではありません。必要に応じて、ロールバック、バグ追跡（つまり、どのバージョンがこれに含まれていたのか）、開発者、ステージング、および運用サーバーの違いを追跡するのに役立ちます。
私はそれを自動化することを検討したい-それはあなたが一度セットアップし、必要なときにそれを使用できるようなものです。
ユーザーは常に最新で最高のリリースを使用しているため、バージョン番号は気にしませんが、実際に実行されているバージョンを正確に知ることは自分自身（およびチーム）に委ねられています。最終的に、開発ソースはライブコードと同期しなくなり、間違いなくなりなく知る必要があります。したがって、svn / gitツリーでリリースにラベルを付け、そのタグでWebアプリをマークします。
些細なWebアプリケーション以外の場合は、バージョン管理する必要があります。ここでは、わずかに異なる2つの概念が機能しています。
状況に関係なく、ファイルには個々のバージョン（またはリビジョン）番号が必要だと思います。理想的には、これはバージョン管理システムによって自動的に処理されます。他の人によって述べられているように、ファイルのバージョン番号は日時よりも簡単に参照できます。
アプリケーションの複数のライブインストールがある場合（またはある場合）、全体としてバージョン管理する必要があります。これは、開発環境とテスト環境が分離している場合（推奨される場合）にもお勧めします。各アプリケーション（またはリリース）バージョン番号は、特定のバージョン番号の個々のファイルの集合を指します。このすべてを処理することは余分な負担ですが、特定のリビジョン番号の個々のファイルよりも特定のリリースをチェックアウトする方が簡単です。
これは私に言語学の概念を考えさせます。言語で何かを表現できなければ、それを（その言語で）考えることはできないと言われています。ドイツ語の「Schadenfreude」を思い浮かべます。その言葉を参照することにより、その定義を定義するよりも、「他人の不幸による喜びを感じる」というこの概念を考える（そして話す）のがはるかに簡単です。それがこの言葉が英語で使われ始めた理由です。
同様に、バージョン番号を使用すると、特定の状態でアプリケーションとそのファイルについて話す（および考える）のが簡単になります。あなたが1人のチームで、1つのアプリケーションで作業している場合、大きな違いはありません。ただし、事態が複雑になるにつれて、これらのラベルを使用できるようにする方が適切です。
ビルドサーバーのビルドIDを使用してWebアプリケーションをバージョン管理し、そのIDをすべてのバグレポートに含める必要があります。
これにより、現在生産されていない古いバージョンで報告されたバグを修正する必要がある場合に、時間をさかのぼることができます。
あなたの質問から、単純な Webアプリケーションを念頭に置いていることが明らかです。
Web GUIからのみアクセスでき、Web（-service）APIからはアクセスできません。APIを使用してアプリケーションにアクセスするユーザーがいる場合は、バージョン管理する必要があります。APIを変更すると、クライアントが破損するため、異なるバージョンのAPIを同時に維持する必要があります。
一度に実行されるインスタンスは1つだけです。Web担当者しかいなくても、さらにインストールする場合は、どの顧客がどのバージョンを実行しているかを知る必要があります。
ライブバージョンのアップグレードのための許容可能なダウンタイム。データベースであるかもしれない巨大な問題があります。新しいバージョンでの重要な変更には、データの基本構造の変更が伴います。一度に実行しているバージョンが1つしかない場合は、おそらく古いバージョンをオフにし、データベースをアップグレードし、新しいバージョンをオンにする必要があります。その結果、アプリケーションのダウンタイムが発生します。これは、ユーザーの数と種類によっては許容される場合があります。
Webアプリケーションがクライアントとサーバーの両方で複数のモジュールで構成されている場合、各モジュールはバージョン管理される必要があります。また、クライアントとサーバーの両方のモジュールバージョンの各組み合わせには、すべてのログおよびエラーメッセージに存在する必要がある一意のIDを指定する必要があります。
その規則を使用することにより、特定の瞬間にWebアプリがあった状態を常に再作成することが可能になります。
私の意見では、最近のWebアプリはサーバーとクライアントの両方で動的言語を使用して構築されているため、ユーザーがブラウザーを再起動するか手動でページを再読み込みしない限り、更新されたWebアプリを再読み込みする理由はないはずです。
アプリケーションの全体的な状態に影響を与えずに、Webアプリ内の更新されたパーツまたはモジュールのみをリロードする必要があります。
なぜあなたは尋ねるかもしれませんか？まあ、それを強制することにより、Webアプリはその設計により、より頑強で、正確で、おそらく保守しやすくなります。Webアプリが常にサーバー/クライアントの同時更新を必要とする場合、おそらく正しい方法でビルドされていません。
はい、バージョン管理する必要があります！リビジョン管理システムには、バージョン番号に一致するタグ（subversion、git、mercurialなど）が必要です。
このタグを使用すると、戻ってブランチを作成できます。たとえば、現在の製品バージョンにはバグがありますが、マシンのコードが公開される準備が整っていないため、修正することはできません。ただし、RCSでタグ付けされている場合は、そのタグで分岐し、実稼働で実行されているコードの正確なバージョンのバグを修正できます。
個人的には、とにかくバージョン管理する必要があると思いますが、Webサイト固有のWebアプリケーションのバージョン管理の大きな利点の1つは、静的コンテンツの変更を管理しやすくすることです。
たとえば、将来の有効期限が設定されているmysite.cssファイルがあるとします（通常は、各ページのブラウザーにキャッシュされるようにしたい）。その後、そのファイルのスタイルを変更すると、そのファイルをキャッシュから消去するための操作を行わない限り、サイトに以前にアクセスしたユーザーは誰も表示されません。
サイトをバージョン管理している場合、ビルド内のすべてのcss参照をmysite.css？v = 1234のようなものに変更することができます。 'mysite.css？v = 1235になります。
はい、そうすべきです。配布の理由から、他の回答がここで指摘しています。
しかし、なぜあなたは質問をするのかわかります。Webアプリのアプローチはコスト主導です。物理的なメディア、配布、インストール、ドキュメントのハードコピー、トレーニング、技術サポートが含まれる従来のシュリンクラップアプローチとは反対です。除外できるものはすべて除外する必要があります。
明確にするために、ユーザーが目に見えるバージョン番号について話していると仮定し、開発中のバージョン管理をあきらめないことを前提としています。（開発中にバージョン管理が必要ないと思われる場合は、間違っています。バージョン管理が必要です）。
単一ホストプロジェクトの場合、厳密に必要ではありません。質問が発生した場合は、常にホストを見て、実際に実行されているものを確認できるからです。ただし、1〜2回は便利になることがあるので、ちょっといいです。役に立つと思うかどうかは、あなた次第です。
マルチホストプロジェクトの場合、実際にはオプションではありません。最終的に、異なるホストは異なるバージョンになり、ユーザー側でそれらを区別できるようにする必要があります。