it-swarm.dev

Devez-vous versionner des applications Web?

J'ai récemment eu une discussion avec un collègue sur la gestion des versions des applications Web.

Je ne pense pas que vous en ayez besoin du tout, et si vous voulez juste un contrôle de santé mentale pour confirmer que votre dernière version est en ligne, je pense qu'une date (YYMMDD) est probablement assez bonne.

Suis-je hors de la base? Suis-je en train de manquer le point? Dois-je utiliser des numéros de version d'application Web

35
John MacIntyre

Si vous revendez la même application Web à plusieurs clients, vous devez absolument la version.

S'il s'agit d'un site Web qui n'est installé que dans un seul endroit, le besoin est moins criant, mais il ne pourrait probablement pas nuire. Vous seriez également moins sensible aux problèmes de fuseau horaire et autres. Diagnostiquer un problème dans une version de bibliothèque 1.0.2.25 est beaucoup plus agréable que de rechercher la version de bibliothèque le 3 novembre 2010 à 11 h 15.

32
Adam Lear

Si vous pouvez automatiser le numéro de version sur les DLL de votre application, cela ne pourrait pas faire de mal. Il vous aidera à garder une trace des versions.

Généralement, les applications Web ne sont publiées qu'à un seul endroit où vous l'hébergez, donc ce n'est pas aussi important que, par exemple, une application de bureau. Il peut vous aider avec les restaurations, le suivi des bogues (c'est-à-dire la version dans laquelle il se trouve) et le suivi de la différence entre les serveurs de développement, de transfert et de production, le cas échéant.

Je chercherais à l'automatiser - c'est le genre de chose que vous pouvez configurer une fois et l'utiliser si/quand vous en avez besoin.

12
Remus

Vos utilisateurs ne se soucient pas des numéros de version car ils ont toujours la dernière et la meilleure version de toute façon, mais vous vous devez (et à votre équipe) de savoir exactement quelle version fonctionne en direct. Finalement, votre source de développement se désynchronise avec le code en direct et vous certainement devez le savoir. Alors, étiquetez vos versions dans votre arborescence svn/git et marquez l'application web avec cette balise.

9
Martin Wickman

Si vous avez des instances de développement/test, il est très important que les membres de l'équipe de projet puissent voir quelle version/révision ils testent.

9
Jeremy

En plus de ce que les autres ont dit, j'ajouterais que la gestion des versions est également importante d'un point de vue marketing. Une nouvelle version est quelque chose de nouveau qui peut être commercialisé auprès de clients potentiels ou existants. Il permet aux clients de savoir que quelque chose est "nouveau" et de voir que les choses avancent. Il fournit de jolis regroupements de nouvelles fonctionnalités. Et ça a l'air plus professionnel.

4
GrandmasterB

Vous devez versionner votre application Web avec l'ID de build de votre serveur de build et avoir cet ID inclus dans tous les rapports de bogues.

Cela vous permettra de remonter le temps au cas où vous auriez à corriger un bug signalé sur une ancienne version non présente actuellement en production.

4
user1249

Je dis que pour tout sauf une application Web triviale, vous devez la version. Il y a deux notions, légèrement différentes, à l'œuvre ici:

  1. application dans son ensemble
  2. fichiers individuels

Quelle que soit la situation, je pense que les fichiers doivent avoir des numéros de version (ou de révision) individuels. Idéalement, cela serait géré automatiquement par votre système de contrôle de version. Comme cela a été dit par d'autres, il est plus facile de se référer au numéro de version d'un fichier qu'à sa date et heure.

Si vous avez (ou pouvez avoir) plus d'une installation en direct de l'application, elle doit être versionnée dans son ensemble. C'est également une bonne pratique si vous avez des environnements de développement et de test séparés (comme vous le devriez probablement). Chaque numéro de version d'application (ou de version) fait référence à une collection de fichiers individuels avec des numéros de version spécifiques. Bien que tout cela soit un fardeau supplémentaire, il est plus facile d'extraire une version spécifique que des fichiers individuels avec des numéros de révision spécifiques.


Cela me fait penser à une notion en linguistique. On dit que si vous ne pouvez pas exprimer quelque chose dans une langue, vous ne pouvez pas y penser (dans cette langue). Je pense au mot allemand "Schadenfreude". Il est beaucoup plus facile de penser (et de parler) à cette notion de "ressentir de la joie due au malheur de quelqu'un d'autre" en se référant à cette Parole qu'à sa définition. C'est la raison pour laquelle la Parole s'est glissée dans la langue anglaise.

De même, les numéros de version permettent de parler (et de penser) plus facilement de votre application et de ses fichiers à des états spécifiques. Si vous êtes une équipe composée d'une seule personne et que vous travaillez sur une seule application, cela ne fera probablement pas une grande différence. Cependant, à mesure que les choses se compliquent, il est préférable que ces étiquettes soient disponibles.

4
George Marian

D'après votre question, il est clair que vous avez en tête une application Web simple

  • Accessible uniquement par une interface graphique Web et non par une API Web (-service). Si des utilisateurs accèdent à l'application à l'aide d'une API, vous avez besoin de la version. Si vous modifiez l'API, vous cassez des clients, vous devez donc conserver une version différente de l'API en même temps.

  • Seulement ne instance en cours d'exécution à la fois. Même si vous n'avez que le web, si vous avez plus d'installation, vous devez savoir quel client exécute quelle version.

  • Avec un temps d'arrêt acceptable pour la mise à niveau de la version live. Il y a peut-être un énorme problème qui est le base de données. Les modifications importantes apportées aux versions plus récentes s'accompagnent de modifications de la structure sous-jacente des données. Si vous n'avez qu'une seule version en cours d'exécution, vous devrez probablement désactiver l'ancienne version, mettre à niveau la base de données et activer la nouvelle version. Ce qui entraîne un temps d'arrêt de l'application. Cela peut être acceptable en fonction du nombre et du type d'utilisateurs.

1
OGrandeDiEnne
  • Utilisation interne uniquement avec une base d'installation limitée?
  • Ou susceptible d'avoir plusieurs versions à l'état sauvage?

Nous n'avons que le premier, donc utilisez uniquement le numéro de version pour la vérification de la cohérence après la publication. Nous n'avons pas besoin de suivre plusieurs versions en même temps.

0
gbn

Si votre application Web se compose de plusieurs modules, à la fois sur le client et sur le serveur, chaque module doit être versionné. Et chaque combinaison de versions de module sur le client et le serveur doit recevoir un identifiant unique, un identifiant qui doit être présent dans tous les messages de journalisation et d'erreur.

En utilisant cette convention, il sera toujours possible de recréer l'état de l'application Web à un moment donné.

À mon avis, étant donné que les applications Web de nos jours sont construites en utilisant des langages dynamiques des deux côtés, serveur et client, il ne devrait y avoir aucune raison de recharger une application Web mise à jour à moins que l'utilisateur ne redémarre le navigateur ou ne recharge manuellement la page.

Seuls les composants ou modules mis à jour dans l'application Web doivent être rechargés sans affecter l'état général de l'application.

Pourquoi pourriez-vous demander? Eh bien, en appliquant cela, l'application web sera de par sa conception plus roboustique, correcte et probablement plus facile à maintenir. Si l'application Web nécessite toujours une mise à jour simultanée du serveur/client, elle n'est probablement pas conçue de la bonne façon.

0
Ernelli

Oui, vous devriez le versionner! Et il devrait y avoir une balise dans votre système de contrôle de révision (comme Subversion, git, Mercurial, etc.) qui correspond au numéro de version.

La balise vous permet de revenir en arrière et de créer une branche. Par exemple: la version de production actuelle a un bogue, mais vous ne pouvez pas le corriger car le code sur votre machine n'est tout simplement pas prêt à sortir. Si vous l'avez balisé dans votre RCS, vous pouvez vous embrancher sur cette balise et corriger le bogue dans la version exacte du code en cours de production.

0
Brad Cupit

Personnellement, je pense que vous devriez quand même versionner, mais l'un des grands avantages du versionnage des applications Web spécifiques aux sites Web est qu'il peut rendre les modifications du contenu statique beaucoup plus faciles à gérer.

Par exemple, disons que vous avez un fichier mysite.css qui a une date d'expiration très éloignée (ce que vous voulez généralement faire pour qu'il soit mis en cache dans le navigateur sur chaque page). Si vous modifiez ensuite un style dans ce fichier, personne qui a déjà visité votre site ne le verra à moins qu'il ne fasse quelque chose pour effacer ce fichier de son cache.

Si vous versionnez votre site, vous pouvez changer toutes les références css de votre build en quelque chose comme mysite.css? V = 1234, ce qui vous permettra de conserver la date d'expiration future et de ne pas vous soucier des changements futurs comme dans la prochaine build. 'sera mysite.css? v = 1235.

0
FinnNk

Oui tu devrais. Pour des raisons de distribution pointées ici par d'autres réponses.

Mais je vois pourquoi vous posez la question. L'approche des applications Web est axée sur les coûts. Son contraire à l'approche rétractable héritée, où les coûts incluent les supports physiques, la distribution, l'installation, la copie papier de la documentation, la formation et le support technique. Tout ce qui peut être exclu doit être exclu.

0
user7071

Juste pour être clair, je suppose que vous parlez d'un numéro de version visible par l'utilisateur, et que vous n'abandonnez pas le contrôle de version en cours de développement. (si vous pensez que vous n'avez pas besoin du contrôle de version en développement, alors vous vous trompez, vous avez besoin du contrôle de version).

Pour un projet hébergé individuellement, ce n'est pas strictement nécessaire, car si des questions se posent, vous pouvez toujours regarder l'hôte et confirmer ce qui fonctionne réellement. C'est plutôt sympa, car cela pourrait être utile une ou deux fois. C'est vraiment à vous de décider si vous pensez que cela sera utile ou non.

Pour un projet multi-hébergé, ce n'est pas vraiment facultatif. Différents hôtes finiront par se retrouver avec des versions différentes et vous devrez pouvoir les différencier du côté de l'utilisateur.

0
Michael Kohne