Des mises à jour glitchy indiquent un problème plus profond


Windows 10 à Tokyo Présentation juillet 2015

Évidemment, la mise à jour Windows du 10 octobre 2018 n'a pas été la plus réussie. Des messages concernant la perte de fichiers sur les ordinateurs sont rapidement apparus et Microsoft a cessé de distribuer la mise à jour. Depuis lors, le bug a été corrigé , maintenant une nouvelle mise à jour est en cours de test avant sa réédition.

Ce n'est pas la première mise à jour de Windows à avoir des problèmes - dans les mises à jour précédentes, nous avons vu des choses comme des incompatibilités matérielles importantes - mais c'est clairement devenu pire. La plupart d'entre nous connaissent les sauvegardes, mais en réalité, de nombreuses données, en particulier sur les ordinateurs personnels, n'ont pas de sauvegarde, et leur disparition est très désagréable.

Windows en tant que service

Dans Windows 10, il était prévu de changer radicalement le processus de développement. Microsoft souhaitait mieux répondre aux besoins des clients et du marché - et proposer plus souvent de nouvelles fonctionnalités. Windows 10 a été présenté comme la «dernière» version de Windows. Comme, tous les nouveaux développements deviendront des mises à jour de Windows 10, livrées via le système de mise à jour plusieurs fois par an. Ce nouveau modèle de développement est appelé Windows as a Service. Et après un désordre initial, Microsoft a opté pour deux mises à jour fonctionnelles par an : en avril et en octobre.

Ces efforts ont été couronnés de succès. Microsoft publie de nouvelles fonctionnalités utiles pour le nouveau modèle, sans forcer les utilisateurs à attendre trois ans pour mettre à jour la version principale. Par exemple, une fonctionnalité pratique a été publiée pour le lancement invisible d'Edge dans une machine virtuelle , qui offre une meilleure protection contre les sites Web malveillants. Le sous-système Windows pour Linux (WSL), qui vous permet d'exécuter nativement des programmes Linux sur un système Windows, est devenu un outil pour les développeurs et les administrateurs. Les avantages pour les utilisateurs ordinaires sont un peu plus difficiles à remarquer, mais vous pouvez mentionner les fonctionnalités VR compatibles avec SteamVR , les performances de jeu améliorées et un thème sombre . Bien que les améliorations ne soient pas si importantes, en général, le Windows 10 actuel est certainement meilleur que celui qui est sorti il ​​y a trois ans.


À l'époque où Windows n'était mis à jour que tous les trois ans, il était difficile d'imaginer que WSL deviendrait un outil utile.

Tout cela est bien, et certaines choses auraient difficilement pu être faites (au moins avec autant de succès) sans l'introduction du modèle Windows en tant que service. Le développement WSL, par exemple, était basé sur les commentaires des utilisateurs. Les utilisateurs ont parlé des incompatibilités trouvées et ont aidé à prioriser le développement de nouvelles fonctionnalités. Je ne pense pas que le WSL recevrait un tel élan pour le développement sans une mise à jour régulière tous les six mois - personne ne voudrait attendre trois ans pour voir une correction mineure. Par exemple, pour qu'un package important pour eux commence à fonctionner correctement. Les mises à jour régulières récompensent les gens pour les messages d'erreur car tout le monde voit vraiment que les erreurs sont corrigées en temps opportun.

Le problème avec le modèle Windows as a Service est la qualité. Les problèmes précédents avec ce modèle et les mises à jour de sécurité ont déjà sapé la confiance dans la politique de mise à jour de Windows 10. Les utilisateurs expérimentés étaient d' avis que la qualité des mises à jour de sécurité mensuelles a diminué dans Windows 10, et l'installation de mises à jour semestrielles des fonctionnalités dès leur sortie est folle . Ces plaintes ont également une longue histoire. Les mauvaises mises à jour sont devenues un sujet de préoccupation peu après la sortie de Windows 10.

Le dernier problème avec la suppression de fichiers a poussé les experts à penser qu'il peut y avoir trop de deux mises à jour de fonctionnalités par an . Redmond devrait réduire leur nombre à un, et Microsoft devrait suspendre le développement de nouvelles fonctionnalités et simplement corriger les bugs . Certains craignent que l'entreprise ne soit dangereusement proche d'une grave perte de confiance dans les mises à jour, et pour certains utilisateurs de Windows, cette confiance est déjà perdue.

Ce ne sont pas les premiers appels à Microsoft pour ralentir les mises à jour des fonctionnalités - on craignait que tout cela soit difficile à digérer pour les services informatiques et les utilisateurs ordinaires, mais avec les problèmes évidents de la dernière mise à jour, ces appels deviennent particulièrement pertinents.

Ce n'est pas une question de fréquence, mais de COMMENT les mises à jour sont en cours de préparation

Mais ceux qui insistent sur une mise à jour par an au lieu de deux ratent le sujet. Le problème n'est pas la fréquence de sortie. Le problème est dans le processus de développement de Microsoft.

Pourquoi le problème n'est-il pas en termes? Nous pouvons regarder les calendriers de mise à jour des autres OS.

D'une part, macOS, iOS et Android sont mis à jour moins fréquemment, vous pouvez donc avoir l'impression que Microsoft est trop zélé. D'un autre côté, il existe des précédents pour des mises à jour réussies à une telle fréquence: pour Ubuntu, il y a deux versions par an, et ChromeOS de Google, comme son navigateur Chrome, reçoit des mises à jour toutes les six semaines. Si vous allez au-delà du système d'exploitation, le programme Microsoft Office Insider exécute un canal mensuel où de nouvelles fonctionnalités sont publiées pour les utilisateurs d'Office chaque mois - et les développeurs font le travail sans trop de plaintes et fournissent en même temps un flux constant de nouvelles fonctionnalités et correctifs. L'équipe de Visual Studio publie également souvent des mises à jour pour son environnement de développement et ses services interactifs. Évidemment, Microsoft dispose d'équipes qui se sont bien adaptées à la réalité, où leurs applications sont régulièrement mises à jour.

Nous dépasserons le cadre des logiciels locaux et examinerons les services réseau et cloud. Là, Microsoft et d'autres sociétés introduisent de plus en plus la livraison continue . Chaque mise à jour du système est automatiquement déployée sur les serveurs de production après avoir réussi un nombre suffisant de tests automatiques.

Bien sûr, aucun de ces projets ne peut être comparé en complexité avec Windows. Ubuntu peut avoir une gamme plus diversifiée de packages, mais dans tous les cas, beaucoup d'entre eux sont développés indépendamment. Le fait demeure: l'échelle de Windows est inhabituellement grande - et les composants sont intégrés sans précédent dans une base de code unique. À certains endroits, le code Windows est exceptionnellement ancien.

Bien sûr, ces facteurs compliquent le développement de Windows, mais est-il vraiment impossible de maîtriser deux mises à jour par an? Ce n'est pas du tout le point. Vous avez juste besoin du bon processus de développement.


Windows 10 au moment de la sortie en 2015 (où sont toutes mes icônes et le menu Démarrer?)

Un processus ancré dans l'histoire

Microsoft ne divulgue pas de détails spécifiques sur le processus de développement de Windows 10, mais il existe des caractéristiques observables de ce processus (comment les nouvelles fonctionnalités sont envoyées aux initiés, types d'erreurs dans les builds d'initiés), et il existe des informations au sein de l'entreprise. Tous ces faits indirects indiquent l'infériorité du processus de développement. Il a conservé certaines similitudes avec le processus de développement que la société a utilisé lors des versions triennales de Windows. Le timing est tombé, mais l'approche de base n'a pas changé.



Autrefois, entre deux et trois ans s'étaient écoulés entre les grosses versions, Microsoft est arrivé à un processus divisé en plusieurs étapes:

1. conception et planification;
2. développement de composants;
3. l'intégration;
4. stabilisation.

Environ 4 à 6 mois de planification et de conception, 6 à 8 semaines de codage intensif, puis 4 mois d'intégration (chaque fonction est généralement développée dans sa propre branche, ils doivent donc tous être assemblés et combinés ensemble) et de stabilisation (test et correction des erreurs). Pendant le développement du produit, ce cycle est répété deux ou trois fois; Windows aura trois itérations, dont la première est un prototype, et les deux suivantes sont réelles. La durée des phases peut varier, mais la structure de base est largement utilisée dans l'entreprise.

Certaines choses ressortent clairement de ce processus. La chose la plus frappante est peut-être que, étonnamment, peu de temps est consacré directement au développement du nouveau code: pour la sortie de Windows, ce sont deux intervalles de 6-8 semaines tout au long de la période de trois ans. Il s'écoule beaucoup de temps entre la phase de planification / conception et le produit qui fonctionne réellement. C'est le principal facteur pour lequel ce processus ne peut pas être décrit comme un «développement flexible»: de nouvelles fonctions sont fermement intégrées dans le produit final, il est donc difficile de les modifier en réponse aux commentaires.

La séparation des développements et des corrections de bogues est également un problème: aux stades de développement et d'intégration, la fiabilité et la stabilité des logiciels sont très faibles. Les fonctions intégrées ne sont pas fondamentalement testées (car les tests ont lieu plus tard) et ne sont jamais utilisées les unes avec les autres (car elles ont toutes été développées séparément dans leurs propres branches avant la phase d'intégration). L'encombrement logiciel est ensuite amené à un niveau acceptable par le biais de tests, de rapports d'erreurs et de corrections d'erreurs pendant la longue phase de stabilisation. Dans ce processus, vous devez améliorer à plusieurs reprises la fiabilité du produit.


Nadella présente le monde à Windows 10 en 2015

Le nouveau monde n'est pas si nouveau

Dans le nouveau monde, nous voyons qu'il faut sept ou huit mois pour un cycle complet d'entreprise. Bien qu'il n'y ait que six mois entre les versions, le début du cycle suivant a lieu avant que le précédent ne soit terminé - pour les initiés, cela est évident depuis l'ouverture du groupe Skip Ahead.

En règle générale, chaque mise à jour commence par une période plutôt calme avec plusieurs modifications visibles, puis vient quelques mois avec l'introduction de modifications importantes - et un grand nombre de bogues. Environ un mois avant la mise à jour, nous constatons un net ralentissement du nombre de modifications apportées et un fort accent sur les corrections de bugs, et non sur les nouvelles fonctionnalités.

Comme les employés de Microsoft le décrivent eux-mêmes, les derniers mois de développement incluent la phase «tell», puis un mois de la phase «ask permission». À l'étape «notifier», la direction de Windows est informée des modifications apportées à la politique d'acceptation de ces modifications par défaut. Au stade de la «demande de permission», seuls les changements vraiment importants sont autorisés, en règle générale, seulement quelques changements par jour.

Par exemple, la première version de la mise à jour d'octobre (nom de code RS5) a été publiée aux initiés le 14 février, et la version stable de la mise à jour d'avril (RS4) a eu lieu deux mois plus tard, le 16 avril. RS5 n'a reçu aucune nouvelle fonctionnalité significative avant le 7 mars. De nombreuses fonctionnalités ont été ajoutées en mai, juin et juillet, puis seules de petites modifications ont été apportées en août et septembre. Plusieurs petites fonctionnalités ont même été supprimées en août, car il était difficile de préparer leur sortie en octobre.

Bien sûr, le processus a un peu changé. Par exemple, de nouvelles fonctionnalités apparaissent dans les pré-versions au cours de plusieurs mois. Cela indique que l'intégration de nouvelles fonctions semble se produire beaucoup plus tôt - à mesure que les fonctions sont développées, et non dans un grand package de fusion à la fin.

Baisse de qualité

Mais il existe des similitudes clés. Plus important encore, un code délibérément bogué est intégré dans une base de données commune, et la phase de test et de stabilisation est utilisée pour résoudre tout problème. Ce moment est même explicitement reconnu: annonçant un nouvel assemblage préliminaire , Microsoft prévient: «Comme d'habitude au début du cycle de développement, les assemblys peuvent contenir des bugs qui peuvent être douloureux. Si cela vous dérange, vous pouvez envisager de passer à un cycle de mise à jour lent (anneau lent). Là, les assemblages seront toujours de meilleure qualité. »

Nous voyons cela en pratique dans RS5. En octobre de l'année dernière, avec la mise à jour, ils ont introduit une nouvelle fonctionnalité pour OneDrive: les espaces réservés, qui affichent des fichiers dans le cloud qui ne sont pas téléchargés localement. Chaque fois qu'une application tente d'ouvrir un fichier, OneDrive extrait le fichier de manière transparente du stockage cloud et l'enregistre localement, et l'application ne sait même pas que le fichier n'était pas initialement accessible localement. La version RS5 a implémenté la fonction de nettoyage des fichiers cloud répliqués du stockage local si l'espace disque est épuisé.

Il s'agit d'une fonctionnalité vraiment intelligente et utile qui améliore l'intégration avec le stockage cloud. Ceci est un nouveau code; Il existe un pilote de noyau qui fournit un lien entre le code de synchronisation cloud (utilisé pour télécharger des fichiers et télécharger des modifications) et des icônes dans le système de fichiers. Il existe également une API (il semble que des tiers puissent également utiliser cette fonctionnalité pour leurs services de synchronisation).


Les pré-versions de Windows utilisent un "écran de mort" vert au lieu de bleu, donc elles sont faciles à distinguer

Il est raisonnable de supposer que Microsoft effectuera un ensemble de tests pour ce nouveau code: création d'un fichier, vérification de la synchronisation, suppression d'une copie locale avec enregistrement de l'icône, ouverture de l'icône avec le téléchargement du fichier réel, suppression complète du fichier, etc., etc. Il existe plusieurs opérations de base pour manipuler des fichiers et des répertoires, et dans tout processus de développement flexible, il existe des tests pour vérifier que toutes les opérations fonctionnent comme prévu, et l'API fait ce qu'elle doit faire.

De plus, il était raisonnable de supposer que tout changement de code qui rompt les tests serait rejeté et non autorisé à s'intégrer. Le code doit être corrigé, il doit passer ses tests avant d'arriver à la branche principale de Windows, et plus encore il va aux bêta-testeurs.

Néanmoins, il y avait un bug dans de nombreuses versions préliminaires: le système a raccroché lors de la suppression d'un répertoire synchronisé avec OneDrive. Ce bug n'a pas seulement été intégré au code Windows, mais a également été communiqué aux utilisateurs finaux.

Tester le logiciel avant sa sortie, pas après

Cela suggère certains des principes fondamentaux du développement de Windows. Soit il n'y a aucun test pour ce code (on m'a dit que oui, il est autorisé d'intégrer le code sans tests, bien que j'espère que ce n'est pas la norme), soit les échecs de test sont considérés comme des problèmes acceptables et non bloquants, et les développeurs sont autorisés à intégrer du code qui n'est évidemment pas fonctionne correctement. Dehors, nous ne pouvons pas dire exactement ce qui se passe exactement - peut-être même une combinaison des deux approches - mais aucune ne peut être qualifiée de bonne.

Pour les parties plus anciennes de Windows, cela peut être considéré comme plus excusable - après tout, elles ont été développées avant l'ère des tests automatisés, et il n'y a peut-être vraiment pas de tests. Mais les badges OneDrive ne sont pas une partie ancienne de Windows; c'est une fonctionnalité complètement nouvelle. Il n'y a aucune bonne raison pour laquelle il n'y a pas d'ensemble solide de tests pour tester la fonctionnalité de base du nouveau code. Et un code défectueux connu ne devrait certainement pas être inclus dans la base de code jusqu'à ce qu'il soit corrigé, sans parler de son envoi aux testeurs.

En conséquence, le développement de Windows 10 suit toujours les anciens principes. De nouvelles fonctionnalités sont ajoutées à la base de données avec la dégradation de la stabilité et de la fiabilité. Il est supposé que la base de code sera portée à un niveau acceptable au stade des tests et de la stabilisation.

Les tests automatisés inadéquats et / ou l'ignorance des erreurs de test, à leur tour, signifient que les développeurs Windows ne peuvent pas être sûrs que les modifications et les corrections n'entraîneront pas d'ondulations. C'est de là que vient la phase de développement «demander une autorisation»: à la fin de la mise à jour, le nombre de modifications doit être minimisé car Microsoft n'est pas sûr que la portée et l'impact de chaque modification soient isolés. Cette confiance ne vient qu'avec une infrastructure massive de tests disciplinés: vous savez que le changement est sûr car tous les tests réussissent. Quel que soit le type de test que la société effectue pour Windows, il ne suffit manifestement pas de gagner une telle confiance.

Mais à d'autres égards, Microsoft agit comme s'il avait cette certitude. L'entreprise a de nombreux tests; On m'a dit qu'un cycle de test complet pour Windows prend plusieurs semaines. Ce cycle complet est vraiment réalisé, mais pas sur les assemblages qui entrent réellement en production. Un exemple est la mise à jour d'octobre 2018: le code a été assemblé le 15 septembre, et le 2 octobre, l'assemblée est devenue publique. Quelle que soit la version RS5 qui a subi un cycle de test complet, ce n'est pas celui que nous avons réellement reçu, car un cycle de test complet prend trop de temps.

Il s'agit d'une position controversée. Si des modifications ultérieures du code sont apportées avec un haut degré de certitude qu'elles n'ont rien cassé, vous pouvez démarrer le cycle de test complet sur l'assembly précédent. Mais si Microsoft avait une telle confiance que ces changements ne briseraient rien, il n'aurait pas à les étrangler autant au stade de la «demande de permission».


Windows 10 peut vraiment fonctionner comme une machine fiable

Comment bien faire

Nous voyons une différence significative avec les vrais projets Agile. Par exemple, un processus de développement que Google utilise pour son serveur de diffusion d'annonces. Il s'agit d'un élément essentiel de l'infrastructure de l'entreprise, mais les nouveaux développeurs de l'entreprise décrivent qu'ils ont apporté des modifications pour corriger une petite erreur - et les changements sont entrés en production pendant la journée. Lorsqu'un correctif est soumis au référentiel, il est automatiquement reconstruit et soumis à une batterie de tests. Le responsable de cette section de code considère ensuite la modification, l'accepte et la combine avec la base de code principale, qui est à nouveau testée et déployée en production.

Bien sûr, il est un peu injuste de comparer cela avec Windows: après tout, il est beaucoup plus facile pour les services cloud d'annuler la modification lorsqu'une erreur est détectée. La modification de Windows avec un écran bleu au démarrage du système est beaucoup plus difficile à annuler et à restaurer. — Google, , , . , .

. , . Microsoft — « , », , .


Chrome , , —

, Agile . , Google Chrome. - Chrome , . , Chrome , . dev- Chrome — , , . : Chrome , , Windows.

Google . , Chrome , . , . Google , . , Google Chrome , .

Windows

Microsoft — . , , . Windows 10 , Microsoft , .

. , Windows . Windows 7 , . Windows, Service Pack 1. ? — , Service Pack 1 .

, Windows , , . Pas du tout. , , « Service Pack 1» . , Microsoft , — - . «» Service Pack 1.

, : Windows , . — , . , Service Pack .

— . . , Windows , , .

— . Microsoft , . 2014 . , , . Windows Insider — (). , - Windows.

, . , , . , Microsoft . . , , , , . , , .

Microsoft , . , , : .

. Insider — . , . . , Microsoft .

, , . . , : . .

Chrome Windows — . Windows , . , OneDrive, . .

, Windows — « », « , ». . Microsoft , . , — . . , . , .