Ich habe vor kurzem eine Diskussion mit einem Kollegen über die Versionierung von Webanwendungen geführt.
Ich glaube, Sie brauchen es überhaupt nicht, und wenn Sie nur eine Überprüfung der Integrität durchführen möchten, um zu bestätigen, dass Ihre neueste Version live ist, ist ein Datum (JJMMTT) wahrscheinlich gut genug.
Bin ich nicht auf der Basis? Verpasse ich den Punkt? Sollte ich Versionsnummern von Webanwendungen verwenden?
Antworten:
Wenn Sie dieselbe Webanwendung an mehrere Kunden weiterverkaufen, sollten Sie sie unbedingt versionieren.
Wenn es sich um eine Website handelt, die nur an einem Ort installiert wurde, ist der Bedarf geringer, aber es kann wahrscheinlich trotzdem nicht schaden. Sie sind weniger anfällig für Zeitzonenprobleme und dergleichen. Die Diagnose eines Problems in einer Bibliotheksversion 1.0.2.25 ist viel besser, als den Bibliotheksaufbau am 3. November 2010 um 11:15 Uhr aufzuspüren
Wenn Sie die Versionsnummer der DLLs Ihrer Anwendung automatisieren können, kann dies nicht schaden. Es wird Ihnen helfen, den Überblick über die Versionen zu behalten.
Im Allgemeinen werden Web-Apps nur an einem Ort veröffentlicht, an dem Sie sie hosten. Daher ist dies nicht so wichtig wie beispielsweise eine Desktop-Anwendung. Dies kann bei Rollbacks, bei der Verfolgung von Fehlern (dh in welcher Version war dies der Fall) und gegebenenfalls bei der Verfolgung des Unterschieds zwischen Entwickler-, Staging- und Produktionsservern hilfreich sein.
Ich würde es gerne automatisieren - so etwas können Sie einmal einrichten und verwenden, wenn Sie es brauchen.
Ihre Benutzer interessieren sich nicht für Versionsnummern, da sie sowieso immer die neueste und beste Version haben, aber Sie sind es sich selbst (und Ihrem Team) schuldig, genau zu wissen, welche Version live ausgeführt wird. Irgendwann ist Ihre Entwicklungsquelle nicht mehr mit dem Live-Code synchron und Sie müssen es definitiv wissen. Kennzeichnen Sie also Ihre Veröffentlichungen in Ihrem SVN- / Git-Baum und markieren Sie die Web-App mit diesem Tag.
Zusätzlich zu dem, was die anderen gesagt haben, möchte ich hinzufügen, dass die Versionierung auch aus Marketing-Sicht wichtig ist. Eine neue Version ist etwas Neues, das an potenzielle oder bestehende Kunden vermarktet werden kann. Kunden werden darüber informiert, dass etwas 'neu' ist und dass sich die Dinge weiterentwickeln. Es bietet schöne Gruppierungen von neuen Funktionen. Und es sieht professioneller aus.
Ich sage, für alles andere als eine triviale Webanwendung sollten Sie sie versionieren. Hier gibt es zwei, leicht unterschiedliche Begriffe:
Unabhängig von der Situation glaube ich, dass Dateien individuelle Versions- (oder Revisions-) Nummern haben sollten. Idealerweise wird dies von Ihrem Versionskontrollsystem automatisch erledigt. Wie von anderen angegeben, ist es einfacher, auf die Versionsnummer einer Datei als auf Datum und Uhrzeit zu verweisen.
Wenn Sie mehr als eine Live-Installation der Anwendung haben (oder haben könnten), sollte diese als Ganzes versioniert werden. Dies ist auch eine gute Vorgehensweise, wenn Sie separate Entwicklungs- und Testumgebungen haben (wie Sie es wahrscheinlich sollten). Jede Versionsnummer einer Anwendung (oder eines Releases) bezieht sich auf eine Sammlung einzelner Dateien mit bestimmten Versionsnummern. Dies alles ist zwar eine zusätzliche Belastung, es ist jedoch einfacher, eine bestimmte Version auszuchecken, als einzelne Dateien mit bestimmten Versionsnummern.
Dies lässt mich an einen Begriff in der Linguistik denken. Es wird gesagt, dass man (in dieser Sprache) nicht darüber nachdenken kann, wenn man etwas in einer Sprache nicht ausdrücken kann. Ich denke an das deutsche Wort "Schadenfreude". Es ist viel einfacher, an diesen Begriff "Freude aufgrund des Unglücks eines anderen" zu denken (und zu sprechen), wenn man sich auf dieses Wort bezieht, als auf seine Definition. Aus diesem Grund hat sich das Wort in der englischen Sprache eingeschlichen.
In ähnlicher Weise erleichtern Versionsnummern das Sprechen (und Denken) Ihrer Anwendung und ihrer Dateien in bestimmten Status. Wenn Sie ein Ein-Personen-Team sind und an einer Anwendung arbeiten, hat dies wahrscheinlich keinen großen Unterschied. Mit zunehmender Kompliziertheit ist es jedoch besser, diese Etiketten zur Verfügung zu haben.
Sie sollten Ihre Webanwendung mit der Build-ID Ihres Build-Servers versionieren und diese ID in allen Fehlerberichten angeben.
Auf diese Weise können Sie die Zeit zurückverfolgen, falls Sie einen Fehler beheben müssen, der bei einer älteren Version gemeldet wurde, die derzeit nicht in der Produktion vorhanden ist.
Aus Ihrer Frage geht klar hervor, dass Sie eine einfache Webanwendung im Sinn haben
Zugriff nur über eine Web-GUI und nicht über eine Web (-service) -API . Wenn Sie Benutzer die Anwendung den Zugriff auf eine API Sie müssen auf die Version es. Wenn Sie die API ändern, trennen Sie Clients, sodass Sie gleichzeitig eine andere Version der API verwalten müssen.
Es wird immer nur eine Instanz ausgeführt . Selbst wenn Sie nur den Web-Typ haben, müssen Sie wissen, welcher Kunde welche Version ausführt, wenn Sie mehr Installationen haben.
Mit akzeptabler Ausfallzeit für das Upgrade der Live-Version. Möglicherweise liegt ein großes Problem in der Datenbank . Wichtige Änderungen mit neueren Versionen gehen mit Änderungen in der zugrunde liegenden Datenstruktur einher. Wenn zu diesem Zeitpunkt nur eine Version ausgeführt wird, müssen Sie wahrscheinlich die alte Version deaktivieren, die Datenbank aktualisieren und die neue Version aktivieren. Dies führt zu Ausfallzeiten der Anwendung. Dies kann je nach Anzahl und Art der Benutzer akzeptabel sein.
Wir haben nur die ersteren, verwenden Sie also nur die Versionsnummer für die Überprüfung nach der Veröffentlichung. Wir müssen nicht viele Versionen gleichzeitig verfolgen.
Wenn Ihre Webanwendung sowohl auf dem Client als auch auf dem Server aus mehreren Modulen besteht, sollte jedes Modul versioniert werden. Und jeder Kombination von Modulversionen auf Client und Server sollte eine eindeutige ID zugewiesen werden, eine ID, die in allen Protokollierungs- und Fehlermeldungen enthalten sein sollte.
Mit dieser Konvention ist es immer möglich, den Zustand der Web-App zu einem bestimmten Zeitpunkt wiederherzustellen.
Meiner Meinung nach sollte es keinen Grund geben, eine aktualisierte Web-App neu zu laden, es sei denn, der Benutzer startet den Browser neu oder lädt die Seite manuell neu.
Nur die aktualisierten Teile oder Module in der Web-App sollten erneut geladen werden, ohne den Gesamtzustand der Anwendung zu beeinträchtigen.
Warum fragst du dich vielleicht? Wenn Sie dies durchsetzen, wird die Web-App robuster, korrekter und wahrscheinlich einfacher zu warten sein. Wenn die Web-App immer ein gleichzeitiges Server- / Client-Update erfordert, ist es wahrscheinlich nicht richtig aufgebaut.
Ja, Sie sollten es versionieren! Und in Ihrem Revisionskontrollsystem sollte sich ein Tag befinden (wie Subversion, Git, Mercurial usw.), das mit der Versionsnummer übereinstimmt.
Mit dem Tag können Sie zurückgehen und eine Verzweigung erstellen. Beispiel: Die aktuelle Produktionsversion weist einen Fehler auf, den Sie jedoch nicht beheben können, da der Code auf Ihrem Computer nicht bereit ist, die Tür zu öffnen. Wenn Sie es jedoch in Ihrem RCS markiert haben, können Sie an diesem Tag verzweigen und den Fehler in der genauen Version des Codes beheben, der in der Produktion ausgeführt wird.
Persönlich denke ich, dass Sie sowieso versionieren sollten, aber ein großer Vorteil der Versionierung von Webanwendungen, die spezifisch für Websites sind, besteht darin, dass Änderungen an statischen Inhalten viel einfacher zu verwalten sind.
Nehmen wir zum Beispiel an, Sie haben eine mysite.css-Datei mit einem weit entfernten zukünftigen Ablaufdatum (was Sie normalerweise tun möchten, damit es im Browser auf jeder Seite zwischengespeichert wird). Wenn Sie dann einen Stil in dieser Datei ändern, wird dieser von niemandem angezeigt, der zuvor auf Ihrer Website war, es sei denn, er löscht diese Datei aus dem Cache.
Wenn Sie Ihre Site versionieren, können Sie alle CSS-Verweise in Ihrem Build in mysite.css? V = 1234 ändern, sodass Sie das weit entfernte Verfallsdatum beibehalten und sich nicht um zukünftige Änderungen sorgen müssen, wie beim nächsten Build ist mysite.css? v = 1235.
Ja du solltest. Aus Verteilungsgründen wird hier auf andere Antworten verwiesen.
Aber ich verstehe, warum du die Frage stellst. Der Ansatz von Web-Apps ist kostengetrieben. Dies steht im Gegensatz zum herkömmlichen Shrinkwrap-Ansatz, bei dem Kosten für physische Medien, Vertrieb, Installation, Hardcopy der Dokumentation, Schulung und technischen Support anfallen. Alles was ausgeschlossen werden kann, sollte ausgeschlossen werden.
Ich gehe davon aus, dass Sie von einer vom Benutzer sichtbaren Versionsnummer sprechen und die Versionskontrolle in der Entwicklung nicht aufgeben. (Wenn Sie der Meinung sind, dass Sie in der Entwicklung keine Versionskontrolle benötigen, dann liegen Sie falsch, Sie benötigen Versionskontrolle).
Für ein einzeln gehostetes Projekt ist dies nicht unbedingt erforderlich, da Sie bei Fragen immer den Host anschauen und überprüfen können, was wirklich läuft. Es ist ein bisschen nett, weil es ein oder zwei Mal nützlich sein kann. Es liegt wirklich an Ihnen, ob Sie glauben, dass es nützlich ist oder nicht.
Für ein Projekt mit mehreren Hosts ist dies nicht wirklich optional. Verschiedene Hosts werden letztendlich unterschiedliche Versionen haben und Sie müssen in der Lage sein, sie auf der Benutzerseite voneinander zu unterscheiden.