Question

Il y a quelques instants Jeff Atwood a déclaré ce qui suit sur twitter :

  

Regardez, j'adore les nouvelles versions de logiciels rapides, mais la fréquence des rejets WordPress est tout simplement ridicule.

Ce qui me fait penser, À quelle fréquence devrais vous libérer des mises à jour logicielles?

  • Tous les jours?
  • hebdomadaire?
  • mensuel?
  • annuel?

Quelle est la meilleure stratégie de sortie?

Était-ce utile?

La solution

Je dirais que dans le cas particulier de WordPress, ils amalgament « les mises à jour de sécurité » et « fonctionnalité des mises à jour » . Ceci est mauvais.

Ce serait comme avoir à faire une, au lieu de télécharger simplement à chaque fois qu'un problème de sécurité a été trouvé réinstallation de Windows en place un petit patch chaque semaine.

WordPress a besoin d'avoir un mécanisme de correctif de sécurité qui est simple, rapide et facile pour les mises à jour de sécurité. Un processus qui est séparé du flux de mise à niveau normal de nouvelles versions.

Autres conseils

La fréquence des rejets Wordpress est si fréquent parce qu'ils se soucient de la sécurité et des mises à jour qui fixent la libération des vulnérabilités connues aussi rapidement que possible. mises à jour de fonctionnalités pour Wordpress se produisent beaucoup moins fréquemment, dans la gamme de 4 à 6 mois, je pense.

Je pense que c'est un bon modèle. Gardez vos clients heureux en libérant de nouvelles fonctionnalités régulièrement, mais si vous trouvez des failles de sécurité, version corrige immédiatement.

Je suggère ce qui suit:

UpdateTime (en secondes) - le temps moyen nécessaire pour l'utilisateur d'effectuer la mise à jour

releaseDelta (en jours) - le temps minimum entre les versions

releaseDelta = updateTime/((1/365)*(60*60*8))

Cette formule est basée sur ma théorie qu'un utilisateur devrait avoir à passer plus de 8 heures pour une année donnée en attente de mises à jour d'une application.

Cela permet également de fréquentes mises à jour aussi longtemps que les mises à jour sont effectuées de manière transparente sans perturber l'utilisateur final.

Je pense que cela dépend fortement de votre situation particulièrement. Cela étant dit, je pense que la libération de tous les jours pour toutes les applications d'affaires sérieux juste totalement ridicule. Si vous publiez tous les jours alors il y a probablement un sérieux problème à moins que vous êtes dans une situation très étrange où les règles d'affaires changent constamment ou quelque chose comme ça.

Moins fréquemment que les mises à jour iTunes.

J'essaie d'utiliser ce qui suit, je l'espère simple, guide en deux parties:

  1. S'il demande à l'utilisateur de télécharger et / ou installer quelque chose, ou modifier un code existant qu'ils maintiennent, alors les rejets doivent fournir le mérite important. Ceci est une version qui ajoute de nouvelles fonctionnalités importantes, fixe un montant significan des questions ou fixe un plus petit nombre de problèmes immédiats et urgents.
  2. Si elle ne nécessite pas l'utilisateur de télécharger et / ou installer les versions seront planifiées de se produire, comme dicté par itération. S'il y a un produit libérable à la fin de l'itération, il sera déployé. L'itération contiendra des besoins techniques et commerciaux tel que déterminé avant le coup d'envoi de l'itération.

Alors, pour nous, des choses comme des applications de bureau ou des services Web seraient généralement tomber sous la première règle, et des choses telles que notre site Web tomberaient sous le second. Nous courons assez bonnes itérations de taille - à environ quatre à six semaines de temps de développement actuellement, ce qui réduit à deux à quatre ans suivant. Ce fut notre « introduction » dans un Scrum hybride.

Notez qu'un produit ne doit pas toujours être en développement (ou en participant à une itération). Il est tout à fait possible qu'un produit siégera, rassis, jusqu'à ce que des changements sont nécessaires si la première règle est applicable.

Cela dépend de la clientèle approche de contrôle de configuration.

Ils ont un choix, vous savez. En fin de compte, ils peuvent choisir de ne pas utiliser votre produit.

Si le client vous acceptera de changer des choses tous les jours, et ils ne se soucient pas, et il n'a pas d'impact de la formation ou la gestion de la configuration; Mises à jour automatiques.

Les clients avec SOE (environnements d'exploitation standard) mises à jour de haine.

Se rendre compte que certains clients ne vont pas accepter le logiciel « appeler à la maison ». Ils voudront héberger leurs propres mises à jour. Les personnes informatiques devront participer. Ceci est plus de travail pour eux.

Certains clients veulent / besoin de faire leur propre AQ; dépend du client et le type de logiciel.

Si le client a besoin de faire des tests / travail à accepter / déployer le logiciel, relâchez un multiple de la longueur du test / déploiement cycle. À moins que les clients sont d'accord avec Déployez entrelacée et test. C'est là qu'ils sont toujours tester une nouvelle version, et le rouleau dehors.

Par exemple:. 2 semaines pour tester, pas plus que la libération toutes les 8 semaines

En résultat des logiciels critiques, les tests de libération peut prendre un mois à la clientèle. Ils parient leurs affaires sur les résultats et sont à juste titre prudent. Donc, tous les communiqués sont les 6 mois.

Dans la sécurité des logiciels critiques, il peut prendre des mois beaucoup. Annuelles, soit environ tous les 18 mois n'est pas rare. Encore moins est souvent tout à fait normal.

Il n'y a pas de bonne réponse, cela dépend vraiment du produit.

Je dis par mois au plus. Quotidien / hebdomadaire est trop souvent, à moins bien sûr les mises à jour d'application sont effectuées de manière automatisée et transparente, par exemple Le système de mise à jour de Firefox

Vous pouvez les libérer aussi souvent que vous le souhaitez. Ce qui frustre les utilisateurs est de ne pas savoir si elles ont besoin de votre nouvelle version ou non. Cela signifie que vous devez être très clair sur les nouvelles fonctionnalités que vous avez mis en place, les bugs que vous avez fixé, et si oui ou non vous avez résolu des problèmes de sécurité. Plus important encore, vos utilisateurs veulent être en mesure de faire confiance que s'ils installer une nouvelle version, rien ne se est cassé.

Je pense que s'il est possible vous devriez avoir votre mise à jour de logiciel automatiquement quand il doit, de façon à maintenir le processus de mise à jour lisse et invisible à l'utilisateur que possible.

Pour la région où je travaille, les contrôles industriels, très rarement. Nous faisons généralement une version majeure très 2 ans. Des modifications mineures peut-être tous les 3 à 6 mois. patch Bug sont bien sûr une autre histoire, ils sont libérés au besoin. Même alors peu de clients existants de mise à niveau des systèmes. Bien sûr, dans d'autres domaines, les mises à jour sont plus acceptées.

Certes, lorsque vous avez de nouvelles fonctionnalités / corrections de bugs vaut libérer ?? Pourquoi sur un calendrier?

Je n'ai pas d'objection à des bugs de sécurité se fixe dès qu'ils sont trouvés - bien que je voudrais qu'ils écrire du code plus robuste en premier lieu. Ce que j'objecte (au moins aussi loin que Wordpress va) est presse d'amélioration qui pourraient briser les plug-ins qui se passent trop vite. Combien de temps at-il fallu pour aller de 2,5 à 2,6? Et 2,7 sort très peu de temps aussi bien.

Une mise à niveau automatique ou semi-automatique atténuerait une partie de ce problème, mais seulement si les auteurs du plugin de mise à niveau aussi bien, ou s'ils séparés des correctifs de sécurité des changements de fonctionnalité afin que je puisse, par exemple, le bâton avec 2,5 mais toujours à jour avec les correctifs de sécurité jusqu'à ce que j'étais sûr tous les plugins que j'utilise le travail avec 2.6 ou 2.7 ou (à ce moment) 4.0.

Chaque fois qu'ils sont nécessaires. Gardez à l'esprit que certains utilisateurs se sentent plus sûrs à obtenir des mises à jour régulièrement, alors que certains se sentent simplement ennuyé d'avoir un chaque jour pop-up « Il y a 129 nouvelles mises à jour pour installer cliquez ici attendre 20 minutes pour télécharger, puis un autre 10 pour les installer! » ... vous voyez mon point.

Cela dépend de la nature de la mise à niveau et la quantité d'intervention de l'utilisateur nécessaire pour l'accomplir.

Si c'est un site web, vous pouvez mettre à jour tous les jours, aussi longtemps que vous ne cassez rien.

Si c'est une mise à jour de sécurité gratuit, le plus tôt possible est toujours apprécié.

Une mise à niveau bugfix libre, si elle doit être installée par l'utilisateur, ne doit pas être plus de tous les deux mois.

Tout ce qui doit être payé ne peut être plus fréquente qu'une fois par an, ou les gens vont commencer à se sentir mis à profit. Encore plus pour certaines catégories de logiciels, tels que les systèmes d'exploitation.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top