Les développeurs doivent craindre les mises à jour de leur pile logiciel / développement du poste de travail?

Question

Comme je l'ai découvert, de nombreux développeurs d'éviter toute mise à jour (automatique ou manuelle), parce qu'ils craignent qu'il pourrait faire des changements à leur machine, ils ne comprennent pas, et le logiciel qu'ils développent peuvent échouer à un moment donné, pour des raisons qu'ils ne sais pas.

Stratégie A.) LAISSER LE SYSTEME EN L'ETAT, TANT QUE POSSIBLE.

Je tiens personnellement à avoir mon système « à jour » possible (OS et application de), parce que généralement je me sens d'avoir moins de difficulté à travailler de cette façon.

stratégie

B.) TOUJOURS À JOUR

Quel type de développeur êtes-vous? Et pourquoi?

Answer 1

B. Absolument.

Si vous développez une plate-forme avec pedigrees de mise à jour incertaine (par exemple le monde réel), puis les machines virtuelles sont une arme importante, mais il vaut mieux être aussi à jour que possible lorsque vous relâchez.

Il est tellement plus facile de dire à vos utilisateurs « il suffit d'exécuter la mise à jour » que d'essayer de deviner ce que l'histoire correctif qu'ils pourraient avoir ce la cause du problème (ou du moins pour être en mesure de l'exclure).

Si vous développez pour un public purement interne, alors vous avez vraiment seulement obtenu une question:

• est-il un calendrier de mise à jour pour l'entreprise?
  • oui: alors vous devez vous assurer que votre logiciel fonctionne à la fois sur la production et sur tout ce qui est à venir
  • pas: sans doute mieux pour résoudre ce problème.

Answer 2

Non.

Voilà pourquoi Dieu a inventé des machines virtuelles.

Trier une vraie corvée si vous êtes un programmeur OS X, bien que, en raison de la protection contre la copie à base matérielle dans le système d'exploitation (vous devez exécuter sur le matériel béni Apple).

Answer 3

Gardez le système d'exploitation possible, ayant de préférence un patches de test admin sys mise à jour avant de les relâcher au reste de la société.

Appliquer les Service Packs dev environnement assez rapidement, mais il faut vérifier sur une machine virtuelle d'abord afin que vous puissiez voir si la construction fonctionne toujours, puis donner cette construction à un contrôle qualité pour les tests de fumée avant la mise à niveau des machines dev.

Modifier environnement dev (et / ou la plate-forme, par exemple la mise à niveau de Java 5 à Java 6) lorsque vous pouvez voir un réel avantage, mais permettre comme une tâche explicite avec le temps prévu au budget. Idéalement, le temps du projet de budget pour obtenir les développeurs à accélérer aussi bien afin qu'ils puissent tirer le meilleur parti de celui-ci. Ne pas faire cela tout moment à proximité d'une sortie.

Answer 4

Il arrive rarement que la machine cible pour le logiciel que vous écrivez est le même que votre machine de développement. Par conséquent, il ne fait pas beaucoup de sens de ne pas mettre à jour et de garder la machine tout statique.

Maintenant, la machine cible .. qui est une autre histoire. Là, je ne veux pas de changements aussi longtemps qu'ils ne sont pas absolument nécessaires.

Answer 5

Une fois mordu, deux fois timide.

Answer 6

Un bon exemple de ce qui est arrivé l'autre jour à mon travail. L'équipe informatique a déployé une mise à jour à notre serveur de développement qui semblait inoffensif au début. La machine avait une connexion sans surveillance qui devait rester connecté 24/7. La mise à jour pour Windows (je dois retirer le KB) effectivement déconnecte automatiquement ce type d'utilisateur. Les applications que nous courons sur le serveur ont besoin assisté à des connexions afin d'exécuter (oui, je sais stupide, mais c'est une autre histoire). Tout à coup, nos systèmes ont commencé détraqué et les plaintes roulées en ce que certains des systèmes logiciels utilisés ne fonctionnaient pas.

Nous avons suivi sur le problème et l'utilisateur connecté admin retour, mais il a fallu attendre environ trois déconnexions après causés par Windows que nous avons vraiment réalisé ce qui se passait. Heureusement dommage pas beaucoup a été fait, mais cela signifiait que certaines personnes ont dû faire des heures supplémentaires.

Les mises à jour doivent être vérifiés pour quel type d'effets environnementaux qu'ils peuvent avoir sur votre système d'exploitation avant d'être déployé, et même alors ils doivent être testés.

Answer 7

B, pour des raisons de sécurité.

Mais combien vous devriez se soucier que la rupture des choses dans votre application dépend beaucoup du type de développement que vous faites. Le cas habituel est presque comme une compilation croisée pour une cible différente, comme à peine les machines utilisateur sont configurés comme des machines de dev sont.

Si c'est une application web, votre « plate-forme » est le navigateur (s) et tout ce que vous utilisez côté serveur. Pour moi, ce rubis, des rails et des plugins ainsi que apache / mysql etc côté client, je ne contrôle pas. côté serveur, je veux appliquer au moins les correctifs de sécurité . (à part: plaidoyer pour les développeurs côté serveur, s'il vous plaît libérer les correctifs de sécurité sur un cycle différent aux changements de fonctionnalité) . Mais les mises à jour OS ont généralement peu d'effet sur la pile de serveur dev J'utilise, et en tout cas mon environnement de déploiement utilise un autre système d'exploitation (je développe sur Mac OS X et Ubuntu et Debian et déployer sur Solaris).

S'il est une application de bureau, il dépend comment vous êtes étroitement intégré avec votre plate-forme et si vous avez le contrôle dans l'environnement cible. Comme je l'utilise généralement Java, je vois que la plate-forme non le système d'exploitation, mais il n'a pas besoin des tests sur les différentes saveurs OS et les versions Java. Si certains patch pour le système d'exploitation Java casse, alors c'est une question distincte.

Si vous êtes très étroitement couplé au système d'exploitation, puis mettre à jour les dépendances sont très difficiles à tester et il est presque impossible sans une utilisation intensive des machines virtuelles, plus instantanés, etc. Aussi, si vous êtes fragile que par rapport à OS change votre application échouera probablement si votre machine cible a une charge logicielle différente ou configuration différente de toute façon -. encore une fois très difficile à tester

Answer 8

OS. À jour (bien que je ne suis pas fanatique à ce sujet)

petites applications: Pas tellement. Je me méfie des mises à jour et ne mise à niveau moins qu'il y ait une valeur ajoutée pour moi.

Answer 9

Faire une mise à jour, mais pas au cours d'une période critique dans le cycle de développement. Utilisez une distribution du système d'exploitation connu pour être aussi stable que possible, et connu pour être conservateur dans quelle fréquence ils libèrent des mises à jour.

Forcer vos développeurs de tester leur code chaque fois qu'ils sont sur le point de faire un chèque. Assurez-vous que tous les tests passent avant de faire une mise à niveau. Cela leur assure une certaine idée de ce qui se briser.

Answer 10

Il y a un certain nombre de choses à regarder (je vous écris de l'expérience linux / unix, mais les choses devraient s'appliquer à d'autres systèmes d'exploitation ainsi):

• Soyez au courant des mises à jour cassés. mises à jour cassés se produisent et il est prudent de laisser les autres subir la rupture. Soyez particulièrement conscient des composants de base tels que la bibliothèque c (Y compris les interfaces du système d'exploitation en général comprises), éditeur de liens, compilateur, etc.
• Bibliothèques de composants de mise à jour pour votre produit doit être fait avec prudence (ou sur un test système / vm premier). bibliothèques très utilisés tels que la bibliothèque C sont normalement ok, mais moins ceux utilisés peuvent contenir des sauts API ou des changements sémantiques dans l'API.
• Écrivez votre logiciel pour être tolérant de son environnement:
  • De préférence utiliser divers systèmes configurés différemment pour écrire
  • Ecrire sans assumer les attributs de l'environnement
  • Mise à jour du système en cas de besoin, si quelque chose se brise rendre à la cause racine et éliminer cela.
  • Soyez particulièrement prudent des systèmes de construction dépendant du système complexe (dont ils ont besoin beaucoup plus d'entretien que les plus simples (ou automatisés)) en plus des coûts de rigidité.

Je suis conscient du fait que basés sur Unix ont plus d'une tradition d'être indépendant que les systèmes Windows. Cela ne change pas le bien-fondé de l'ingénierie de l'indépendance de prise en charge OS. Donc, je vous conseille de mettre à jour assez rapidement après une nouvelle mise à jour est disponible (normalement le premier jour), mais assurez-vous qu'il peut facilement être annulée si les choses vraiment briser. Si les pauses du projet, la plupart des développeurs rouleraient en arrière, où une petite équipe travaille sur le fixer.

Answer 11

Il y a le vieux dicton. « Ne jamais changer un système en cours d'exécution ». Je suppose que les histoires d'horreur sur les mises à jour misérables sont légion. Je ne peux dire de mon expérience. Si vous vous basez sur le logiciel « bien membré » des composants pour les likeliness la rupture est bien moindre que les choses sous un rythme de changement rapide. Quelques exemples: Notre IDE est basé sur l'API Win et fonctionne presque inchangé depuis Windows 3.1 (où il a été développé), nous avons ajouté quelques nicecities au fil des ans, donc je parie que le paquet a besoin d'au moins Windows 2000 pour exécuter. Mais je peux vous assurer qu'il survivec beaucoup de mises à jour OS de XP sur Windwos NT, Windows 2000, Windows 2003, Windows XP, Windows 2003-64 et le "oh-so-brillant" Vista.

Par contre, je ne pouvais pas tenir à jour avec le port à base de Gtk sur Linux. Les modifications de l'API sont extrêmes. Voilà donc ce que je déteste le plus au sujet des partisans open-source, vous êtes obligé de refaire votre travail encore et encore juste pour rester réelle.

Un autre exemple qui m'a pris demande au moins une bonne semaine de travail wan mise à jour d'un des rails très faible de la version 1.1.6 à 2.2. (Et en seulement deux ans). Je craignais que ce serait pire, mais été un peu positivly suprised.

Cordialement