Comment abordez-vous la gestion des versions pour une application Web (SaaS)?

Question

Quelle est la meilleure approche pour publier une nouvelle version d’une application Web hébergée, et à quelle fréquence publiez-vous généralement? Choisissez-vous une date arbitraire, disons toutes les semaines, tous les mois, etc. pour déployer un ensemble de corrections accumulées (en utilisant peut-être une approche similaire à L'approche de Joel concernant les dates d'expédition )? Attendre beaucoup plus longtemps que cela semble faire échec à une partie du principal avantage d'une application hébergée. D'autre part, vous ne voudriez pas déployer constamment de nouvelles fonctionnalités qui pourraient dérouter l'utilisateur (c'est-à-dire, s'il y avait quelque chose de différent à chaque fois qu'il / elle était connecté).

Jusqu'à récemment, mon expérience portait principalement sur les applications installées sur serveur ou sur poste de travail. Je suis curieux de voir quel type de gestion de publication utilise avec une application hébergée.

Answer 1

L’approche de Google est probablement la meilleure pour l’utilisateur final, mais elle a un coût en complexité.

Ils déploient de nouvelles versions (et parfois juste des modifications individuelles) de manière relativement constante (aussi souvent que quotidiennement, en fonction du projet). Mais voici le kicker: seule une petite partie des utilisateurs reçoit la nouvelle version.

Google utilise un grand nombre d'utilisateurs pour ses gros produits, il est donc pratique de définir des règles telles que "5% des utilisateurs devraient voir cette fonctionnalité".

Ils peuvent ensuite analyser les résultats et planifier leur prochaine publication, éventuellement pour 15% de la population d'utilisateurs.

Answer 2

Même si les ingénieurs veulent définir une routine, elle dépendra en réalité des exigences métier du système. Cela dépend aussi vraiment de la nature des mises à jour, etc ...

Les mises à jour de contenu et HTML ne devraient pas être un gros problème à déployer. Les modifications apportées aux applications DEVRAIENT être une grosse affaire et passer par les routines de test établies sur un site de prévisualisation avant d’être mises en production.

Une chose est sûre, vous devez avoir un environnement très "propre". moyen de déployer (et annuler le déploiement) des modifications. Vous avez également besoin d'un programme "facile". manière de passer en revue et d’auditer les modifications avant leur mise en ligne.

Utilisation d'un mélange de " git " et " rsync " nous permet un contrôle total sur le processus. Toutes les modifications apportées à notre projet sont développées dans une branche qui était issue du groupe "Production". branche. Avant que des modifications ne puissent être mises en ligne, le message " Production " La branche doit être entièrement fusionnée. La mise en production consiste simplement à fusionner la branche appropriée dans "Production". et le resynchroniser sur les serveurs live. Git rend cela vraiment facile.

Cela garantit que les modifications en cours ne risquent pas d'entrer en conflit avec d'autres modifications en cours.

Depuis l'adoption de ce système, notre routine de déploiement a considérablement augmenté en efficacité et en clarté. Et au fait, nos déploiements vont de plusieurs fois par jour à une fois tous les plusieurs mois. Tout dépend. Je préférerais un ou deux cycles par semaine sur un projet actif.

Answer 3

Communiquer tôt et souvent est ce que je fais et ce que nous faisons où nous travaillons. Nous bloguons également sur nos mises à jour chaque fois que nous les faisons. C’est probablement plus facile pour vous d’incorporer toutes vos mises à jour en une mise à jour à la fois (pour le contrôle qualité, la restauration, etc.) du mieux que vous pouvez. Du point de vue de l'utilisateur, je ne pense pas qu'il y ait de problème avec beaucoup de mises à jour. Tant que ce ne sont pas de mauvaises mises à jour. Je pense qu'il y a un problème si vous attendez une année entière ou six mois et que toutes vos mises à jour soient intégrées dans une seule et même version. C'est ce qui a tué un projet sur lequel j'avais l'habitude de travailler (un lecteur de flux populaire dont vous avez probablement entendu parler). Les gens pensaient que nous étions morts et la perception est devenue réalité. Nous avons été abandonnés. Je suis donc tout à fait favorable aux calendriers de publication de firehose.

Answer 4

Toutes les deux semaines devraient suffire, mais cela dépend beaucoup de votre marché.

Answer 5

Chez Planbox (système SaaS de gestion de projet Agile basé sur le Web), nous publions tous les jours. Nous pouvons le faire car la plupart de notre logique d’application, ainsi que toute notre logique de présentation, sont au premier plan (Javascript). Même le HTML est généré via Javascript en utilisant un moteur de templates. Mais le backend (PHP) et son API REST changent rarement. Cela nous permet de proposer de nouvelles versions du client à tout moment sans rompre la compatibilité.

Si vous pouvez passer à une telle architecture, vous gagnerez beaucoup de temps et gagnerez en efficacité.