Webアプリケーションをバージョン管理する必要がありますか？
最近、Webアプリケーションのバージョン管理について同僚と話し合いました。
まったく必要ないと思いますし、サニティチェックで最新のリリースが公開されていることを確認したいだけの場合は、日付（YYMMDD）で十分でしょう。
私は基地外ですか？ポイントを逃していますか？ Webアプリケーションのバージョン番号を使用する必要がありますか
同じWebアプリケーションを複数の顧客に再販する場合は、絶対にバージョン管理する必要があります。
1か所にしかインストールされていないWebサイトであれば、ニーズはそれほど深刻ではありませんが、それでもおそらく害はありません。また、タイムゾーンの問題などの影響を受けにくくなります。ライブラリバージョン1.0.2.25の問題の診断は、2010年11月3日午前11時15分にライブラリビルドを追跡するよりもはるかに優れています。
アプリケーションのDLLのバージョン番号を自動化できれば、害はありません。バージョンの追跡に役立ちます。
一般に、ウェブアプリはホストしている1か所でのみリリースされるため、デスクトップアプリほど重要ではありません。これは、ロールバック、バグ追跡（つまり、どのバージョンであったか）、および該当する場合は、開発サーバー、ステージングサーバー、および運用サーバーの違いを追跡するのに役立ちます。
私はそれを自動化することを検討します-それは、一度セットアップして、必要なときに/それを使用できるようなものです。
とにかく常に最新で最高のリリースを持っているので、ユーザーはバージョン番号を気にしませんが、どのバージョンがライブで実行されているかを正確に知るのは自分自身（およびチーム）の責任です。結局、開発ソースがライブコードと同期しなくなり、それから間違いなくは知っておく必要があります。そのため、svn/gitツリーでリリースにラベルを付け、そのタグでWebアプリをマークします。
開発/テストインスタンスがある場合、プロジェクトチームのメンバーがテストしているビルド/リビジョンを確認できることは非常に重要です。
他の人が言ったことに加えて、バージョン管理はマーケティングの観点からも重要だと付け加えます。新しいバージョンは、潜在的または既存の顧客に販売できる新しいものです。何かが「新しい」ことを顧客に知らせ、物事が前進していることを確認できます。新機能のニースグループを提供します。そして、それはよりプロフェッショナルに見えます。
ビルドサーバーからのビルドIDを使用してWebアプリケーションをバージョン管理し、そのIDをすべてのバグレポートに含める必要があります。
これにより、現在稼働していない古いバージョンで報告されたバグを修正する必要がある場合に、過去にさかのぼることができます。
些細なWebアプリケーション以外の場合は、バージョン管理する必要があると私は言います。ここでは、わずかに異なる2つの概念が機能しています。
- アプリケーション全体
- 個々のファイル
状況に関係なく、ファイルには個別のバージョン（またはリビジョン）番号を付ける必要があると思います。理想的には、これはバージョン管理システムによって自動的に処理されます。他の人が述べているように、日時よりもファイルのバージョン番号を参照する方が簡単です。
アプリケーションのライブインストールが複数ある（または複数ある可能性がある）場合は、全体としてバージョン管理する必要があります。これは、（必要に応じて）開発環境とテスト環境を分離している場合にも適しています。各アプリケーション（またはリリース）のバージョン番号は、特定のバージョン番号の個々のファイルのコレクションを指します。これをすべて処理することは余分な負担ですが、特定のリビジョン番号の個々のファイルよりも特定のリリースをチェックアウトする方が簡単です。
これは私に言語学の概念を思い起こさせます。言語で何かを表現できないと、その言語でそれを考えることはできないと言われています。ドイツ語の「Schadenfreude」を思い浮かべます。この「他の人の不幸による喜びを感じる」というこの概念は、その定義よりも、そのWordを参照する方が、考える（話す）のがはるかに簡単です。それが、Wordが英語で使われるようになった理由です。
同様に、バージョン番号を使用すると、特定の状態にあるアプリケーションとそのファイルについて簡単に話す（および考える）ことができます。あなたが1人のチームで1つのアプリケーションに取り組んでいる場合、大きな違いはありません。ただし、状況が複雑になるにつれて、これらのラベルを使用できるようにすることをお勧めします。
あなたの質問から、あなたが単純なウェブアプリケーションを念頭に置いていることは明らかです
Web GUIでのみアクセスでき、Web（-service）APIではアクセスできません。 APIを使用してアプリケーションにアクセスするユーザーがいる場合は、バージョンを付ける必要があります。 APIを変更するとクライアントが壊れるため、異なるバージョンのAPIを同時に維持する必要があります。
一度に実行される1つのインスタンスのみ。 Web担当者しかいない場合でも、インストール数が多い場合は、どの顧客がどのバージョンを実行しているかを知る必要があります。
ライブバージョンのアップグレードに許容可能なdown-timeを使用します。 データベースである可能性のある巨大な問題があります。新しいバージョンでの重要な変更には、データの基本構造の変更が伴います。一度に実行しているバージョンが1つだけの場合は、おそらく古いバージョンをオフにし、データベースをアップグレードしてから、新しいバージョンをオンにする必要があります。その結果、アプリケーションのダウンタイムが発生します。これは、ユーザーの数と種類によっては許容できる場合があります。
- 限られたインストールベースでの内部使用のみ？
- または、実際に複数のバージョンが存在する可能性がありますか？
前者しか存在しないため、リリース後の健全性チェックにはバージョン番号のみを使用します。使用中の多くのバージョンを同時に追跡する必要はありません。
Webアプリケーションがクライアントとサーバーの両方の複数のモジュールで構成されている場合は、各モジュールのバージョンを設定する必要があります。また、クライアントとサーバーの両方のモジュールバージョンの各組み合わせには、一意のIDを指定する必要があります。この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度重宝するかもしれないので、それは一種のニースです。それが役に立つかどうかは、あなた次第です。
マルチホストプロジェクトの場合、これは実際にはオプションではありません。異なるホストは最終的に異なるバージョンになり、ユーザー側でそれらを区別できるようにする必要があります。