Quelle est la meilleure approche pour publier une nouvelle version d'une application Web hébergée et à quelle fréquence la publiez-vous habituellement? Choisissez-vous une date arbitraire, par exemple chaque semaine, mois, etc. pour déployer un ensemble de correctifs accumulés (peut-être en utilisant une approche similaire à Joel's approach to ship dates)? Attendre beaucoup plus longtemps semble vaincre une partie de l'avantage majeur d'une application hébergée. D'un autre côté, vous ne voudriez pas déployer constamment de nouvelles fonctionnalités qui pourraient perturber l'utilisateur (c'est-à-dire s'il y avait quelque chose de différent chaque fois qu'il se connectait). Jusqu'à récemment, mon expérience concernait principalement les applications serveur ou de bureau installées. Je suis curieux de voir quel type de gestion des versions les gens utilisent avec une application hébergée.Comment abordez-vous la gestion des versions pour une application Web (SaaS)?
Répondre
L'approche de Google est probablement la meilleure pour l'utilisateur final, mais elle se fait au détriment de la complexité.
Ils déploient de nouvelles versions (et parfois seulement des changements individuels) sur une base assez constante (aussi souvent que tous les jours, selon le projet). Mais voici le kicker: seule une petite partie des utilisateurs reçoit la nouvelle version.
Google a un grand nombre d'utilisateurs pour leurs gros produits, il est donc pratique de mettre des règles comme "5% des utilisateurs devraient voir cette fonctionnalité". Ils peuvent ensuite analyser les résultats et planifier leur prochaine diffusion, peut-être 15% de la population d'utilisateurs.
Libérer 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 fabriquons. C'est probablement plus facile pour vous si vous mettez toutes vos mises à jour dans une seule mise à jour à la fois (pour le contrôle qualité, l'annulation, etc.) du mieux que vous le pouvez. Du point de vue de l'utilisateur, je ne pense pas qu'il y ait un problème avec beaucoup de mises à jour. Tant qu'ils 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 roulez toutes vos mises à jour dans une grande version. C'est ce qui a tué un projet sur lequel je travaillais (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. Donc, je suis tout pour les horaires de publication firehose.
Toutes les deux semaines devraient suffire, mais cela dépend beaucoup de votre marché.
Même si les ingénieurs veulent définir une routine à suivre, cela va vraiment être dicté par les exigences métier du système. Cela dépend aussi vraiment de la nature des mises à jour, etc ...
Les mises à jour de contenu et de HTML ne devraient pas être un gros problème à exclure. Les changements d'application DEVRAIENT être un gros problème, et passer par les routines de test établies sur un site de prévisualisation avant d'être poussé en direct. Une chose est sûre, c'est que vous devez avoir un moyen très "propre" de déployer (et de ne pas déployer) les changements. Vous avez également besoin d'un moyen "facile" d'examiner et de vérifier les modifications avant leur mise en ligne. L'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 dérivée de la branche "Production". Avant que les modifications ne puissent être mises en ligne, la branche "Production" doit être entièrement fusionnée. La tâche de mise en ligne consiste simplement à fusionner la branche appropriée en "Production" et à la synchroniser avec les serveurs actifs. Git rend cela vraiment facile.
Ceci garantit que les changements en cours ne peuvent pas entrer en conflit avec d'autres changements en cours.
Depuis l'adoption de ce système, notre routine de déploiement a considérablement augmenté en termes d'efficacité et de clarté.Et en passant, nos déploiements vont de plusieurs fois par jour à une fois tous les plusieurs mois. Tout dépend. Je préférerais un cycle de 1-2 par semaine sur un projet actif.
Connaissez-vous des outils qu'une équipe peut utiliser pour le déploiement (et le non-déploiement) de son application au lieu de simplement utiliser git et rsync? –
Chez Planbox (SaaS de gestion de projet Agile basée sur le Web), nous publions tous les jours. Nous pouvons faire cela parce que la plupart de notre logique d'application, et toute notre logique de présentation sont dans le frontal (Javascript). Même le HTML est généré via Javascript en utilisant un moteur de template. Mais le backend (PHP) et son API REST changent rarement. Cela nous permet de pousser de nouvelles versions du client à tout moment sans casser la compatibilité.
Si vous pouvez passer à une telle architecture, vous gagnerez du temps et gagnerez en efficacité.
J'ai une question postée ici - Comment s'assure-t-elle que leurs modifications ne sont disponibles que pour un petit sous-groupe d'utilisateurs? Http: //stackoverflow.com/questions/8129840/release-management-releasing-to-a-subset -des-utilisateurs-comment-voudrait-il-travailler-pour-un-pu. – ram