J'ai récemment discuté avec un collègue de la gestion de versioning d'applications Web.
Je ne pense pas que vous en ayez besoin du tout, et si vous voulez juste un contrôle de cohérence pour confirmer que votre dernière version est en direct, je pense qu'une date (AAMMJJ) est probablement suffisante.
Suis-je en dehors de la base? Est-ce que je manque le point? Devrais-je utiliser les numéros de version d'applications Web
Réponses:
Si vous revendez la même application Web à plusieurs clients, vous devez absolument la mettre à niveau.
S'il s'agit d'un site Web qui n'est jamais installé qu'à un seul endroit, le besoin est moins pressant, mais cela ne risque probablement pas de nuire. Vous seriez moins susceptible aux problèmes de fuseau horaire et autres. Diagnostiquer un problème dans une bibliothèque version 1.0.2.25 est beaucoup plus agréable que de rechercher la bibliothèque créée le 3 novembre 2010 à 11h15.
Si vous pouvez automatiser le numéro de version sur les DLL de votre application, cela ne fait aucun mal. Cela vous aidera à garder une trace des versions.
En règle générale, les applications Web sont publiées uniquement à un endroit où vous les hébergez. Par conséquent, ce n'est pas aussi important qu'une application de bureau. Il peut vous aider avec les restaurations, le suivi des bogues (c.-à-d. Quelle version était celle-ci) et le suivi de la différence entre les serveurs de développement, de transfert et de production, le cas échéant.
J'essaierais de l'automatiser - c'est le genre de chose que vous pouvez configurer une fois et l'utiliser si / quand vous en avez besoin.
Vos utilisateurs ne s’intéressent pas aux numéros de version car ils ont toujours la dernière et meilleure version, mais vous vous devez (et à votre équipe) de savoir exactement quelle version est exécutée. Finalement, votre source de développement n'est plus synchronisée avec le code en direct et vous devez absolument le savoir. Alors, étiquetez vos versions dans votre arbre svn / git et marquez l'application Web avec cette balise.
Outre ce que les autres ont dit, j'ajouterais que la gestion des versions est également importante du point de vue du marketing. Une nouvelle version est une nouveauté qui peut être commercialisée auprès de clients potentiels ou existants. Cela permet aux clients de savoir que quelque chose est «nouveau» et de voir que les choses avancent. Il fournit de beaux regroupements de nouvelles fonctionnalités. Et ça a l'air plus professionnel.
Je dis que pour tout sauf une application Web triviale, vous devriez la version. Il y a deux notions, légèrement différentes, au travail ici:
Quelle que soit la situation, j'estime que les fichiers doivent avoir un numéro de version (ou de révision) individuel. Idéalement, cela serait géré automatiquement par votre système de contrôle de version. Comme d'autres l'ont déjà indiqué, 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, celle-ci doit être versionnée dans son ensemble. C'est également une bonne pratique si vous avez des environnements de développement et de test distincts (comme vous devriez le faire probablement). Chaque numéro de version d'application (ou de version) fait référence à une collection de fichiers individuels portant des numéros de version spécifiques. Bien que tout cela représente un fardeau supplémentaire, il est plus facile d'extraire une version spécifique que des fichiers individuels portant 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) de cette notion de "ressentir de la joie du fait du malheur de quelqu'un d'autre" en se référant à ce mot, plutôt qu'à sa définition. C’est la raison pour laquelle le mot s’est glissé dans la langue anglaise.
De même, les numéros de version facilitent la prise de parole (et la réflexion) de votre application et de ses fichiers dans des états spécifiques. Si vous travaillez avec une seule personne et que vous travaillez sur une seule application, cela ne fera probablement pas une énorme différence. Cependant, à mesure que les choses se compliquent, il est préférable que vous disposiez de ces étiquettes.
Vous devez créer une version de votre application Web avec l'identifiant de construction de votre serveur de build et l'insérer dans tous les rapports de bogues.
Cela vous permettra de remonter dans le temps au cas où vous auriez à corriger un bogue signalé sur une version plus ancienne non présente actuellement en production.
De votre question, il est clair que vous avez à l’esprit une application web simple
Uniquement accessible 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 devez la version. Si vous modifiez l'API, vous cassez des clients. Vous devez donc en conserver une version différente en même temps.
Une seule instance en cours d'exécution à la fois . Même si vous n’avez que le Web guy, si vous avez plus d’installations, vous devez savoir quel client exécute quelle version.
Avec des temps d' arrêt acceptables pour la mise à niveau de la version en direct. Il y a un problème potentiellement énorme qui est la base de données . Les changements importants apportés aux nouvelles versions entraînent des modifications de la structure sous-jacente des données. Si vous n'avez qu'une seule version en cours d'exécution à la fois, vous devrez probablement désactiver l'ancienne version, mettre à niveau la base de données et activer la nouvelle version. Ce qui entraîne des temps morts pour l'application. Cela peut être acceptable en fonction du nombre et du type d'utilisateurs.
Nous n’avons que le premier, aussi n’utilisez le numéro de version que pour la vérification de la conformité après publication. Nous n'avons pas à suivre plusieurs versions en même temps.
Si votre application Web est composée de plusieurs modules, à la fois client et serveur, chaque module doit être versionné. Et chaque combinaison de versions de module sur le client et le serveur doit se voir attribuer un identifiant unique, identifiant qui doit figurer dans tous les messages de consignation et d'erreur.
En utilisant cette convention, il sera toujours possible de recréer l'état dans lequel se trouvait l'application Web à un moment donné.
À mon avis, les applications Web étant de nos jours construites à l'aide de 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 relance le navigateur ou recharge manuellement la page.
Seuls les composants ou les modules mis à jour dans l'application Web doivent être rechargés sans affecter l'état général de l'application.
Pourquoi vous pourriez demander? En appliquant cela, l'application Web sera, de par sa conception, plus robuste, correcte et probablement plus facile à gérer. Si l'application Web nécessite toujours une mise à jour simultanée serveur / client, il est probable qu'elle ne soit pas correctement construite.
Oui, vous devriez le versionner! Et il devrait y avoir une étiquette 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 comporte un bogue, mais vous ne pouvez pas le corriger car le code de votre ordinateur n'est tout simplement pas prêt à être déployé. Cependant, si vous l'avez marqué dans votre RCS, vous pouvez vous connecter à cette balise et corriger le bogue dans la version exacte du code exécuté en production.
Personnellement, je pense que vous devriez quand même utiliser la version, mais l'un des principaux avantages des versions des applications Web spécifiques aux sites Web est qu'elles permettent de modifier beaucoup plus facilement le contenu statique.
Par exemple, supposons que vous disposiez d'un fichier mysite.css dont la date d'expiration est très éloignée (ce que vous souhaitez généralement faire pour qu'il soit mis en cache dans le navigateur de chaque page). Si vous modifiez ensuite un style dans ce fichier, personne qui a déjà visité votre site ne le verra sauf s'il fait quelque chose pour effacer ce fichier de son cache.
Si vous utilisez le versioning de votre site, vous pouvez changer toutes les références css de votre construction en quelque chose comme mysite.css? V = 1234, ce qui vous permettra de conserver la date d'expiration future et de ne pas vous inquiéter des modifications futures, comme dans la prochaine version. Sera mysite.css? v = 1235.
Oui tu devrais. Pour des raisons de distribution indiquées ici par d'autres réponses.
Mais je vois pourquoi vous posez la question. L'approche des applications Web est basée sur les coûts. Elle est à l’opposé de l’approche rétractable classique, où les coûts incluent le support physique, 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.
Soyons clairs, je suppose que vous parlez d’un numéro de version visible par l’utilisateur, sans abandonner le contrôle de version en développement. (Si vous pensez que vous n'avez pas besoin de contrôle de version en développement, vous avez tort, vous avez besoin d'un contrôle de version).
Pour un projet à hébergement unique, ce n'est pas strictement nécessaire, car si vous avez des questions, vous pouvez toujours consulter l'hôte et vérifier ce qui se passe réellement. C'est plutôt agréable, cependant, 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 optionnel. Différents hôtes finiront par se retrouver avec différentes versions et vous devrez être en mesure de les différencier du point de vue de l'utilisateur.