Noticia 5 - Building Windows: 4 millones de commits, 10 millones de items

El cambio de Microsoft al uso de Git como sistema de control de versiones para el desarrollo de Windows ha generado muchos desafíos. Git realmente no fue creado para un repositorio de 300GB con 3.5 millones de archivos, y el esfuerzo de ingeniería para hacer que Git maneje este volumen de datos continúa.

Pero al adoptar y desarrollar lo que la compañía llama One Engineering System (1ES), el Windows and Devices Group (WDG) ha adoptado algo más que Git; el grupo también ha implementado el Visual Studio Team Services (VSTS), el sistema de control de fuente, seguimiento de elementos, integración y prueba de la compañía, y con VSTS un enfoque de desarrollo más integrado y de estilo devops. Git es una parte importante de esto, pero está lejos de toda la historia. Microsoft escribió hoy sobre algunas de sus experiencias al usar VSTS, incluidos algunos de los problemas que la escala de la operación ha causado.

La adopción de las características de VSTS y las prácticas de DevOps no es uniforme en WDG. La integración continua y la entrega continua tienen sentido para algunas partes de WDG: los servicios en línea son un ejemplo obvio, e incluso algunas de las aplicaciones en la Tienda de Microsoft podrían calificar, pero son menos aplicables al sistema operativo central de Windows. No obstante, la compañía ha trabajado para estandarizar las prácticas que son comunes a todos los componentes.

La Fall Creators Update (versión 1709) es una buena demostración de cuán grande es la operación de Windows. Esa actualización incluyó unos 4 millones de commits, agrupados en medio millón de pull requests para incorporar esos cambios al código principal de Windows. Cada pull request, un grupo de cambios que representan una nueva característica, un bugfix o similar, es una solicitud para unir algunos cambios en la rama principal, con esos cambios en la versión más reciente de la rama principal.

En proyectos típicos con un número normal de desarrolladores, el número de pull requests suele ser lo suficientemente bajo como para que nadie intente realizar dos merges al mismo tiempo, por lo que este escenario casi nunca sucede. De hecho, si solo hay una persona que acepta pull requests, una situación común en pequeños proyectos de código abierto, esto nunca sucederá. Pero para Windows, la gran cantidad de pull requests y cambios significa que la rama principal casi siempre se está actualizando, por lo que es mucho más probable que dos pull requests intenten hacer un merge simultáneamente. Las pull requests fallarán, incluso después de que hayan sido aceptadas. Para manejar esto, Microsoft agregó un sistema de colas para que las solicitudes de extracción aceptadas se realicen de forma secuencial; no compiten entre sí, y el sistema puede cortar el trabajo desperdiciado.

Esto representa un problema recurrente con 1ES: prácticas que están bien para equipos más pequeños y los productos se vuelven inutilizables con los 7.000 desarrolladores y 4.000 diseñadores, administradores de programas e ingenieros de servicio que trabajan dentro de WDG. Como otro ejemplo, VSTS regular usa un cuadro desplegable de nombres de usuario para asignar elementos de trabajo a las personas. Ese sistema funciona bien cuando un proyecto tiene solo unos pocos desarrolladores, pero Microsoft tiene un total de unas 80,000 cuentas en VSTS, demasiadas para enumerarse en un solo menú desplegable.

La compañía también tiene muchos work items. La práctica de Microsoft es usar work items para todo; los bugs y las nuevas características, por ejemplo, son todos elementos de trabajo. Históricamente, la empresa brindaba amplio acceso interno al seguimiento de fallas, pero el seguimiento de las nuevas características era mucho más opaco, visible solo para los equipos o divisiones que trabajaban en una función en particular. Con 1ES, estas cosas se registran todas dentro del sistema VSTS, con visibilidad en toda la compañía y un total de alrededor de 10 millones de work items.

Con esta visibilidad mejorada, se pueden crear dependencias entre divisiones para que, por ejemplo, se pueda configurar una función de Visual Studio u Office para que dependa de una característica de Windows. El progreso de estos elementos también se puede rastrear para garantizar que ambos se envíen en el momento correcto. Antes de 1ES, la empresa tenía cinco formas diferentes de rastrear estas dependencias.

El trabajo en 1ES no solo ha implicado la construcción de un sistema común para el desarrollo de Windows, sino también procesos y nombres comunes para esos procesos. Antes, diferentes equipos podían usar el término "error" o "problema" o "defecto", y cuando se trataban, esos errores podían ser "completos" o "completados" o "cerrados", con diferentes flujos de trabajo para manejarlos. Al reunir a los diferentes grupos, la terminología y los procesos están siendo estandarizados, lo que permite una mejor generación de informes y una comunicación más fácil entre las transmisiones.

via ArsTechnica