Las actualizaciones con fallas indican un problema más profundo


Presentación de Windows 10 en Tokio, julio de 2015

Obviamente, la actualización de Windows del 10 de octubre de 2018 no fue la más exitosa. Los mensajes sobre la pérdida de archivos en las computadoras aparecieron rápidamente, y Microsoft dejó de distribuir la actualización. Desde entonces, el error se ha solucionado , ahora se está probando una nueva actualización antes de su relanzamiento.

Esta no es la primera actualización de Windows que tiene problemas, en actualizaciones anteriores vimos cosas como incompatibilidades significativas de hardware , pero claramente ha empeorado. La mayoría de nosotros conocemos las copias de seguridad, pero en realidad, muchos datos, especialmente en las computadoras domésticas, no tienen una copia de seguridad, y su desaparición es muy desagradable.

Windows como servicio

En Windows 10, se planeó cambiar radicalmente el proceso de desarrollo. Microsoft quería responder mejor a las necesidades de los clientes y el mercado, y más a menudo lanzar nuevas funciones. Windows 10 se presentó como la "última" versión de Windows. Al igual, todos los nuevos desarrollos se convertirán en actualizaciones de Windows 10, entregadas a través del sistema de actualización varias veces al año. Este nuevo modelo de desarrollo se llama Windows as a Service. Y después de un desastre inicial, Microsoft decidió dos actualizaciones funcionales por año : en abril y en octubre.

Estos esfuerzos han sido exitosos. Microsoft está lanzando nuevas funciones útiles para el nuevo modelo, sin obligar a los usuarios a esperar tres años para actualizar la versión principal. Por ejemplo, se ha lanzado una característica conveniente para el lanzamiento invisible de Edge en una máquina virtual , que proporciona una mayor protección contra sitios web maliciosos. El Subsistema de Windows para Linux (WSL), que le permite ejecutar programas de Linux de forma nativa en un sistema Windows, se ha convertido en una herramienta para desarrolladores y administradores. Los beneficios para los usuarios comunes son un poco más difíciles de notar, pero puedes mencionar las funciones de realidad virtual compatibles con SteamVR , el rendimiento mejorado del juego y un tema oscuro . Aunque las mejoras no son tan significativas, en general, el Windows 10 actual es ciertamente mejor que el que salió hace tres años.


En los días en que Windows se actualizaba solo cada tres años, era difícil imaginar que WSL se convertiría en una herramienta útil.

Todo esto es bueno, y algunas cosas difícilmente podrían haberse hecho (al menos con tanto éxito) sin la introducción del modelo de Windows como servicio. El desarrollo de WSL, por ejemplo, se basó en los comentarios de los usuarios. Los usuarios hablaron sobre las incompatibilidades encontradas y ayudaron a priorizar el desarrollo de nuevas características. No creo que el WSL reciba un impulso tan grande para el desarrollo sin un progreso constante de actualización cada seis meses; nadie querría esperar tres años para ver una corrección menor. Por ejemplo, para que un paquete importante para ellos comience a funcionar correctamente. Las actualizaciones periódicas recompensan a las personas por los mensajes de error porque todos realmente ven que los errores se corrigen de manera oportuna.

El problema con el modelo de Windows como servicio es la calidad. Los problemas anteriores con este modelo y las actualizaciones de seguridad ya han socavado la confianza en la política de actualización de Windows 10. Los usuarios experimentados opinaron que la calidad de las actualizaciones de seguridad mensuales ha disminuido en Windows 10, e instalar actualizaciones de características semestrales tan pronto como salgan es una locura . Estas quejas también tienen una larga historia. Las malas actualizaciones se convirtieron en motivo de preocupación poco después del lanzamiento de Windows 10.

El último problema con la eliminación de archivos hizo que los expertos razonaran que puede haber demasiadas actualizaciones de dos funciones por año . Redmond debería reducir su número a uno, y Microsoft debería suspender el desarrollo de nuevas funciones y simplemente corregir errores . A algunos les preocupa que la compañía esté peligrosamente cerca de una pérdida grave de confianza en las actualizaciones, y para algunos usuarios de Windows esta confianza ya está perdida.

Estas no son las primeras llamadas a Microsoft para ralentizar las actualizaciones de funciones; existía el temor de que todo esto sea difícil de digerir tanto para los departamentos de TI como para los usuarios comunes, pero con los problemas obvios de la última actualización, estas llamadas se vuelven especialmente relevantes.

No es una cuestión de frecuencia, sino de CÓMO se están preparando las actualizaciones.

Pero aquellos que insisten en una actualización por año en lugar de dos pierden el punto. El problema no es la frecuencia de salida. El problema está en el proceso de desarrollo de Microsoft.

¿Por qué el problema no está en términos? Podemos ver los horarios de actualización de otros sistemas operativos.

Por un lado, macOS, iOS y Android se actualizan con menos frecuencia, por lo que puede tener la impresión de que Microsoft es demasiado celoso. Por otro lado, existen precedentes para actualizaciones exitosas con tal frecuencia: para Ubuntu, hay dos versiones por año, y ChromeOS de Google, como su navegador Chrome, recibe actualizaciones cada seis semanas. Si va más allá del sistema operativo, el programa Microsoft Office Insider ejecuta un canal mensual donde se lanzan nuevas características para los usuarios de Office cada mes, y los desarrolladores hacen el trabajo sin causar demasiadas quejas y al mismo tiempo proporcionan un flujo constante de nuevas características y correcciones. El equipo de Visual Studio también suele publicar actualizaciones para su entorno de desarrollo y servicios interactivos. Obviamente, Microsoft tiene equipos que se han adaptado bien a la realidad, donde sus aplicaciones se actualizan regularmente.

Iremos más allá del alcance del software local y analizaremos los servicios de red y en la nube. Allí, Microsoft y otras compañías están introduciendo cada vez más la entrega continua . Cada actualización en el sistema se implementa automáticamente en los servidores de producción después de pasar un número suficiente de pruebas automáticas.

Por supuesto, ninguno de estos proyectos se puede comparar en complejidad con Windows. Ubuntu puede tener una variedad más diversa de paquetes, pero en cualquier caso, muchos de ellos se desarrollan de forma independiente. El hecho sigue siendo: la escala de Windows es inusualmente grande, y los componentes se integran sin precedentes en una sola base de código. En algunos lugares, el código de Windows es excepcionalmente antiguo.

Por supuesto, estos factores complican el desarrollo de Windows, pero ¿es realmente imposible dominar dos actualizaciones al año? Este no es el punto en absoluto. Solo necesita el proceso de desarrollo correcto.


Windows 10 en el momento del lanzamiento en 2015 (¿Dónde están todos mis íconos y el menú Inicio?)

Un proceso arraigado en la historia.

Microsoft no revela detalles específicos del proceso de desarrollo de Windows 10, pero hay características observables de este proceso (cómo se envían las nuevas características a los de adentro, los tipos de errores en las compilaciones de información privilegiada), y hay cierta información dentro de la compañía. Todos estos hechos indirectos indican la inferioridad del proceso de desarrollo. Conservó algunas similitudes con el proceso de desarrollo que la compañía utilizó durante los lanzamientos de tres años de Windows. El tiempo ha caído, pero el enfoque básico no ha cambiado.



En los viejos tiempos, cuando pasaron entre dos y tres años entre los grandes lanzamientos, Microsoft llegó a un proceso dividido en varias etapas:

1. diseño y planificación;
2. desarrollo de componentes;
3. integración;
4. estabilización

Aproximadamente de 4 a 6 meses de planificación y diseño, de 6 a 8 semanas de codificación intensiva y luego de 4 meses de integración (cada función generalmente se desarrolla en su propia rama, por lo que todas deben recopilarse y combinarse juntas) y estabilización (prueba y corrección de errores). Durante el desarrollo del producto, este ciclo se repite dos o tres veces; Windows tendrá tres iteraciones, la primera de las cuales es un prototipo, y las dos siguientes son reales. La duración de las fases puede variar, pero la estructura básica se usa ampliamente en la empresa.

Algunas cosas son obvias de este proceso. Quizás lo más sorprendente es que sorprendentemente se dedica poco tiempo directamente al desarrollo de un nuevo código: para el lanzamiento de Windows, estos son dos intervalos de 6 a 8 semanas durante todo el período de tres años. Pasa mucho tiempo entre la etapa de planificación / diseño y el producto que realmente funciona. Este es el factor principal por el que este proceso no puede describirse como "desarrollo flexible": las nuevas funciones están firmemente integradas en el producto final, por lo que es difícil cambiarlas en respuesta a los comentarios.

La separación del desarrollo y las correcciones de errores entre sí también es un problema: en las etapas de desarrollo e integración, la fiabilidad y la estabilidad del software es muy lamentable. Las funciones integradas no se prueban fundamentalmente (porque las pruebas se realizan más tarde) y nunca se usan entre sí (porque todas se desarrollaron por separado en sus propias ramas antes de la fase de integración). El desorden del software se lleva a un nivel aceptable mediante pruebas, informes de errores y corrección de errores durante la larga fase de estabilización. En este proceso, debe mejorar repetidamente la confiabilidad del producto.


Nadella presenta el mundo a Windows 10 en 2015

El nuevo mundo no es tan nuevo.

En el nuevo mundo, vemos que se necesitan siete u ocho meses para un ciclo completo de la empresa. Aunque solo hay seis meses entre lanzamientos, el comienzo del siguiente ciclo tiene lugar antes de que se complete el anterior; para los iniciados esto es evidente desde la apertura del grupo Skip Ahead.

Como regla general, cada actualización comienza con un período bastante tranquilo con varios cambios visibles, y luego viene unos meses con la introducción de grandes cambios, y una gran cantidad de errores. Aproximadamente un mes antes de la actualización, vemos una fuerte desaceleración en la cantidad de cambios realizados y un fuerte énfasis en la corrección de errores, y no en las nuevas características.

Como los propios empleados de Microsoft describen, los últimos meses de desarrollo incluyen la fase de "decir", luego un mes de la fase de "pedir permiso". En la etapa de "notificación", la administración de Windows es informada de los cambios realizados con la política de aceptar estos cambios de manera predeterminada. En la etapa de "pedir permiso", solo se permiten cambios realmente significativos, por regla general, solo unos pocos cambios por día.

Por ejemplo, la primera compilación de la actualización de octubre (nombre en clave RS5) se lanzó a los iniciados el 14 de febrero, y la compilación estable de la actualización de abril (RS4) se produjo dos meses después, el 16 de abril. RS5 no recibió ninguna característica nueva significativa hasta el 7 de marzo. Se agregaron muchas características durante mayo, junio y julio, y luego solo se hicieron pequeños cambios en agosto y septiembre. Incluso se eliminaron varias características pequeñas en agosto, ya que era difícil prepararse para su lanzamiento en octubre.

Por supuesto, el proceso ha cambiado un poco. Por ejemplo, las nuevas características aparecen en precompilaciones en el transcurso de muchos meses. Esto indica que la integración de nuevas funciones parece ocurrir mucho antes, ya que las funciones se desarrollan y no en un gran paquete de fusión al final.

Disminución de la calidad.

Pero hay similitudes clave. Lo más importante, un código deliberadamente defectuoso está integrado en una base de datos común, y la fase de prueba y estabilización se utiliza para resolver cualquier problema. Este momento incluso se reconoce explícitamente: al anunciar una nueva asamblea preliminar , Microsoft advierte: “Como es habitual al comienzo del ciclo de desarrollo, las asambleas pueden contener errores que pueden ser dolorosos. Si esto le causa algún inconveniente, puede considerar cambiar a un ciclo de actualización lento (Anillo lento). Allí, las asambleas seguirán siendo de mayor calidad ".

Vemos esto en la práctica en RS5. En octubre del año pasado, con la actualización, introdujeron una nueva característica para OneDrive: marcadores de posición, que muestran archivos en la nube que no se descargan localmente. Cada vez que una aplicación intenta abrir un archivo, OneDrive extrae de manera transparente el archivo del almacenamiento en la nube y lo guarda localmente, y la aplicación ni siquiera sabe que el archivo no estaba inicialmente accesible localmente. La compilación RS5 implementó la función de limpiar archivos de nube replicados del almacenamiento local si se agota el espacio en disco.

Esta es una característica realmente inteligente y útil que mejora la integración con el almacenamiento en la nube. Este es un nuevo código; Hay un controlador de kernel que proporciona un enlace entre el código de sincronización en la nube (utilizado para cargar archivos y descargar cambios) y los iconos en el sistema de archivos. También hay una API (parece que terceros también pueden usar esta función para sus servicios de sincronización).


Las compilaciones previas de Windows usan una "pantalla de muerte" verde en lugar de azul, por lo que son fáciles de distinguir

Es razonable suponer que Microsoft realizará un conjunto de pruebas para este nuevo código: crear un archivo, verificar la sincronización, eliminar una copia local al guardar el icono, abrir el icono con la descarga del archivo real, eliminar el archivo por completo, y así sucesivamente. Existen varias operaciones básicas para manipular archivos y directorios, y en cualquier proceso de desarrollo flexible, hay pruebas para verificar que todas las operaciones funcionen como se espera, y la API hace lo que debe hacer.

Además, era razonable suponer que cualquier cambio de código que rompa las pruebas sería rechazado y no se permitiría la integración. El código debe ser reparado, debe pasar sus pruebas antes de que llegue a la rama principal de Windows, y aún más va a los beta testers.

Sin embargo, hubo un error en muchas compilaciones preliminares: el sistema colgó al eliminar un directorio sincronizado con OneDrive. Este error no solo se integró en el código de Windows, sino que también se lanzó a los usuarios finales.

Pruebe el software antes del lanzamiento, no después

Esto sugiere algunos de los principios fundamentales del desarrollo de Windows. O bien, no hay pruebas para este código (me dijeron que sí, que está permitido integrar el código sin pruebas, aunque espero que esta no sea la norma), o que las fallas en las pruebas se consideran problemas aceptables, sin bloqueo, y los desarrolladores pueden integrar código que obviamente no funciona correctamente Afuera, no podemos decir exactamente qué está sucediendo exactamente, tal vez incluso una combinación de ambos enfoques, pero ninguno de ellos puede considerarse bueno.

Para las partes más antiguas de Windows, esto puede considerarse más excusable: después de todo, se desarrollaron antes de la era de las pruebas automáticas, y es posible que no haya pruebas. Pero las insignias de OneDrive no son una parte antigua de Windows; es una característica completamente nueva. No hay una buena razón por la cual no haya un conjunto sólido de pruebas para probar la funcionalidad básica del nuevo código. Y un código defectuoso conocido definitivamente no debe incluirse en la base del código hasta que se arregle, sin mencionar el envío a los evaluadores.

Como resultado, el desarrollo de Windows 10 sigue los viejos principios. Nuevas características se vierten en la base de datos con la degradación de la estabilidad y la fiabilidad. Se supone que la base del código se llevará a un nivel aceptable en la etapa de prueba y estabilización.

Las pruebas automáticas inadecuadas y / o ignorar los errores de prueba, a su vez, significa que los desarrolladores de Windows no pueden estar seguros de que los cambios y las correcciones no causen efectos dominó. Aquí es donde surgió la fase de desarrollo de "pedir permiso": a medida que se completa la actualización, es necesario minimizar el número de cambios porque Microsoft no está seguro de que el alcance y el impacto de cada cambio estén aislados. Esta confianza solo viene con una infraestructura masiva de pruebas disciplinadas: usted sabe que el cambio es seguro porque todas las pruebas pasan con éxito. No importa qué tipo de pruebas realice la compañía para Windows, claramente no es suficiente para ganar tanta confianza.

Pero en otros aspectos, Microsoft actúa como si tuviera esa certeza. La compañía tiene muchas pruebas; Me dijeron que un ciclo de prueba completo para Windows lleva muchas semanas. Este ciclo completo se lleva a cabo realmente, solo que no en los ensamblajes que realmente entran en producción. Un ejemplo es la actualización de octubre de 2018: el código se ensambló el 15 de septiembre y el 2 de octubre, la asamblea se hizo pública. Independientemente de qué versión de RS5 haya pasado por un ciclo de prueba completo, este no es el que realmente recibimos, porque un ciclo de prueba completo lleva demasiado tiempo.

Esta es una posición controvertida. Si se realizan cambios posteriores al código con un alto grado de confianza de que no rompieron nada, puede comenzar el ciclo de prueba completo en el ensamblaje anterior. Pero si Microsoft tuviera tanta confianza en que estos cambios no romperían nada, no tendría que estrangularlos tanto en la etapa de "pedir permiso".


Windows 10 realmente puede funcionar como una máquina confiable

Como hacerlo bien

Vemos una diferencia significativa con proyectos reales de Agile. Por ejemplo, un proceso de desarrollo que Google usa para su servidor de envío de anuncios. Esta es una parte crítica de la infraestructura de la compañía, pero los nuevos desarrolladores de la compañía describen que hicieron cambios para cerrar un pequeño error, y los cambios entraron en producción durante el día. Cuando se envía una solución al repositorio, se reconstruye automáticamente y se somete a una batería de pruebas. El responsable del mantenimiento de esta sección de código considera el cambio, lo acepta y lo combina con la base de código principal, que se vuelve a probar y se implementa en producción.

Por supuesto, es un poco injusto comparar esto con Windows: después de todo, es mucho más fácil para los servicios en la nube revertir el cambio cuando se detecta un error. Modificar Windows con una pantalla azul al iniciar el sistema es mucho más difícil de deshacer y restaurar.Sin embargo, el servidor de anuncios es un servicio crítico de Google, al final, la compañía gana dinero y una actualización fallida puede causar fácilmente una pérdida de millones de dólares. Pero las pruebas automáticas y todo el proceso establecido permiten que incluso el interno de la empresa implemente sus cambios en la producción en unas pocas horas y lo haga con confianza.

La mentalidad de desarrollo es fundamentalmente diferente. Una nueva característica puede ser inestable durante el desarrollo, pero cuando se agrega a la rama principal, debe corresponder a un alto nivel de calidad. El enfoque de Microsoft es "fusionar todos los errores ahora, los arreglaremos más adelante", y en el proceso correcto, los errores se eliminan antes de que la nueva función se agregue a la rama principal.


Chrome , , —

Si bien las aplicaciones en la nube ofrecen cierta flexibilidad, los métodos ágiles también son adecuados para el software de escritorio. Por ejemplo, Google tiene procesos similares para Chrome. Las versiones beta de Chrome tienen errores raros, pero en general, su código está cerca de la calidad de lanzamiento. De hecho, el principio del desarrollo de Chrome es que incluso la última versión debería ser de calidad de lanzamiento. Puede usar la versión de desarrollo de Chrome como un navegador normal, y solo por el icono comprenderá que se trata de un canal alfa, no estable. Esto es posible gracias a la amplia automatización de pruebas y comprobaciones: durante todo el proceso de desarrollo, el código de Chrome es de alta calidad, sin una caída en la calidad, con los cambios posteriores que vemos en Windows.

Para hacer esto, Google ha invertido en infraestructura. Ella tiene un sistema de compilación distribuido que construye Chrome en paralelo en mil núcleos, por lo que se puede completar una compilación completa en solo unos minutos. Se ha establecido una ramificación disciplinada para que las fusiones sean fáciles y predecibles. Google tiene una amplia gama de pruebas funcionales y de rendimiento para detectar errores y regresiones lo antes posible. Nada de esto es gratuito, pero es importante que Google lance las versiones de Chrome de manera sostenible y regular.

El proceso de desarrollo de Windows siempre ha sido malo

En el nuevo proceso de desarrollo, Microsoft ha asignado proporcionalmente más tiempo para escribir nuevas funciones y menos tiempo para estabilizar y corregir estas funciones. Todo sería bueno si la calidad de las funciones fuera alta desde el principio, con una infraestructura de prueba y estándares más altos antes de integrar un nuevo código. Pero la experiencia con Windows 10 hasta ahora es que Microsoft no ha desarrollado los procesos y sistemas necesarios para admitir este nuevo enfoque.

El problema de reducir el número de problemas de dos a uno por año no solucionará el problema. A menudo me parece que la gente mira el desarrollo anterior de Windows a través de lentes rosas. Pero si recuerda los tiempos de Windows 7 y anteriores, entonces veremos problemas muy similares. Y luego, el consejo habitual era no actualizar a una nueva versión de Windows hasta que se lanzara el Service Pack 1. ¿Por qué? Debido a que la primera versión siempre fue inaceptablemente defectuosa e inestable, y fue mejor esperar hasta que el Service Pack 1 resuelva la mayoría de estos problemas.

La diferencia no es que el nuevo enfoque para desarrollar Windows es mucho peor que antes, o que el antiguo proceso dio mejores resultados. En absolutoAhora vemos lo mismo que entonces, solo el momento en que "espere el Service Pack 1" llega dos veces al año. Después de cada nueva actualización, llega un momento en que Microsoft cree que el código es lo suficientemente bueno para los usuarios corporativos, generalmente de tres a cuatro meses después del lanzamiento inicial. Este es nuestro "nuevo" Service Pack 1.

Por lo tanto, obtenemos lo peor de ambos mundos: desde el antiguo enfoque para desarrollar Windows, hay versiones malas que deben corregirse. Desde un nuevo enfoque: lanzamientos dos veces al año, y no una vez cada tres años. Por lo tanto, la inestabilidad hasta el lanzamiento del Service Pack persiste durante la mayor parte del año.

El principal inconveniente es la desestabilización de la base del código mediante la integración de funciones probadas inadecuadamente con la esperanza de solucionarlo más tarde. Este es un mal proceso. Esto fue malo en un momento en que Windows se lanzó cada tres años, y fue malo cuando se lanzó cada seis meses.

Este no es el trabajo de los iniciados

El segundo problema es la naturaleza de las pruebas. Microsoft solía tener una gran cantidad de probadores, y se asignó un cierto número de desarrolladores y probadores a cada función. Muchos de ellos fueron despedidos o transferidos a otros puestos en 2014. La idea era que se asignarían más responsabilidades de prueba a los desarrolladores que crean estas características. El programa Windows Insider también proporciona una gran cantidad de pruebas informales, con muchos millones de participantes (expertos). Esto es mucho más que en cualquiera de los programas beta anteriores de Windows.

No estoy seguro si el enfoque anterior habría detectado un error de pérdida de datos. Quizás los evaluadores profesionales no probarían un escenario específico en el que se eliminen los datos. Pero está claro que Microsoft no está manejando el flujo de mensajes de error de personas de adentro. La pérdida de datos se registró tres meses antes de la actualización. Muchos mensajes de error parecen ser de baja calidad, carecen de los detalles necesarios o de la terminología correcta, pero si la empresa no ha notado el problema durante tres meses, no es obvio que un período de desarrollo más largo sea importante. Un período de desarrollo más largo significará que el error se ignoró durante seis meses, no tres.

Microsoft prometió cambiar el proceso de retroalimentación con información privilegiada para que indiquen la gravedad del problema y llamen más la atención sobre este tipo de problemas. Esto puede ayudar si los expertos usan correctamente los indicadores de gravedad, pero parece insuficiente para resolver el problema principal: demasiados informes de errores de muy baja calidad.

Esto se refiere al problema de la calidad del código. La verdadera fortaleza de Insider es la variedad de hardware y software. Los iniciados pueden identificar los errores de compatibilidad más exóticos, problemas con los controladores, etc. Pero los expertos no deben hacer pruebas de funciones básicas. Pero a menudo existe la sensación de que Microsoft los usa como probadores de tiempo completo.

Además, si la calidad del código disminuye durante el desarrollo, las compilaciones previas generalmente no son adecuadas para el uso diario en PC normales. No son lo suficientemente confiables. A su vez, esto socava el valor de las pruebas realizadas por expertos: no los instalan en la PC principal y no someten el ensamblaje a la gama completa de hardware y software. Usan PC secundarias y máquinas virtuales.

Tienes que invertir en tus herramientas

Desarrollar una infraestructura de prueba como Chrome para un proyecto tan gigantesco como Windows es una tarea muy seria. Aunque algunas partes de Windows permiten la prueba fuera de línea, otras solo se pueden probar de manera efectiva en un sistema integrado e integrado. Algunos de ellos, como la función de sincronización de archivos OneDrive, incluso dependen de la operación de servicios de red externos. Esta no es una tarea trivial.

Un gran cambio sería la adopción del principio de que el código de Windows debería proporcionar calidad de lanzamiento en todo momento, no "después de varios meses de corrección", sino "ahora, en cualquier momento". Pero esta es una condición necesaria. Microsoft debe lograr una situación en la que cada nueva actualización tenga calidad de lanzamiento desde el primer día. Situaciones en las que actualizar a la última versión no es un problema, y ​​esta opción se puede aceptar de forma segura. Las actualizaciones de funciones deben ser invisibles para los usuarios. Reducir el número de lanzamientos a uno por año o uno en tres años no proporcionará esta situación, y nunca lo hizo. El proceso en sí debería cambiar, no el momento.