La jerga de las Betas

  • Article

Daniel Matey se emocionaba la semana pasada con la disponibilidad de la "Escrow" de la Beta 3 de Windows Server Longhorn. Pero esto, en el fondo, no es la Beta 3 sino un paso previo. Así es que vamos a ver si podemos aclarar un poco qué es éste jaleo de Betas, CTPs, RCs, con sus escrows, Lockdowns, builds, etc que muchas veces se lee por ahí.

Dentro de una metodología de gestión de proyectos general, los equipos de desarrollo de Windows pasan por cinco fases bien definidas y diferenciadas:

  • Análisis de Requerimientos
  • Diseño
  • Implementación
  • Verificación
  • Puesta en el mercado

Durante las dos primeras fases se decide que características tendrá el producto, se trabaja en documentos detallados con las especificaciones que han de cumplir cada una de ellas y se crea una agenda en la que se van definiendo diferentes objetivos o "milestones", que determinan el orden en el que los equipos de desarrollo las irán implementando. Obviamente esto es bastante complejo, ya que hay funcionalidades de los productos que dependen unas de otras y hay que definir las estructuras, funciones e interfaces que habrá que codificar para cumplir con todos los requerimientos.

La fase de implementación se centra en la programación, documentación y pruebas de dichas características. Los diferentes equipos de desarrollo pueden estar al cargo de una o varias de ellas, y equipos independientes se encargan de pasar las baterías de pruebas predefinidas (seguridad, funcionalidad, stress, etc.) y de reportar los "bugs" que encuentren tras analizar los resultados de las mismas. Esta fase termina cuando los equipos han finalizado de implementar las características básicas del producto y estas han sido probadas sin encontrarse problemas que pudieran impedir su uso. Es durante esta fase, previa a las Betas, en la que se suele involucrar a clientes en los programas TAP para ir comprobando el funcionamiento del producto en escenarios reales.

Cada noche de los días de diario se construye una "build" completa del producto que comprende las diferentes plataformas, e incluso los diferentes SKUs o versiones, y que recoge el trabajo de todos los equipos hasta ese momento. Probarlas es un ejercicio divertido a la par que arriesgado, sobre todo si estas fuera de los equipos de desarrollo y testeo y de sus canales de información. Puede suceder que lo que funcionaba ayer no funcione hoy en absoluto y viceversa. Preparando el Techday nos sucedió que ningún Terminal Server abría el puerto 3389 independientemente del equipo. Sin embargo la build del día siguiente funcionaba en ese sentido estupendamente y fue la que utilizamos para jugárnosla en directo con nuestras demos extremas. No obstante los equipos de testeo "marcan" algunas compilaciones específicas que cumplen con ciertos patrones de calidad predefinidos de manera que puedan usarse como referencia para pruebas o incluso despliegues internos (que llamamos "dogfooding").

En la fase de verificación comienza cuando todas las características, o un alto porcentaje de ellas, están implementadas en la "build" principal, aunque lógicamente los desarrolladores siguen trabajando. En esta fase se trata de recopilar los resultados de las pruebas que los "beta testers" realizan independientemente, reportar los bugs y dedicarse a arreglarlos. El número de Betas, si estarán soportadas o no, su difusión, etc., dependen de cada proyecto. Una vez absolutamente todas las características están completas, llegan las Release Candidates (RCs). Son builds que se consideran lo suficientemente buenas como para convertirse en producto final. Una vez el producto entra en esta fase, solamente se arreglarse los fallos que se encuentren en dichas builds. En los casos que yo recuerdo, ha habido tres Betas y dos Release Candidates de las versiones de Windows. Sin embargo es frecuente también que se liberen también compilaciones mensuales o Community Technical Previews (CTPs) con el propósito de que la comunidad de profesionales pueda evaluar los progresos y usarlas para sus propias pruebas.

Lógicamente, el proceso anterior es lo suficientemente complejo como para que haya una única línea de "builds". En las semanas previas a la liberación de una compilación importante (una Beta, RC, CTP o una versión que se vaya a distribuir masivamente, en un evento, por ejemplo), generalmente se produce una ramificación sobre la que se hacen dos cosas. Primeramente todos los equipos ponen encima de la mesa los bugs que manejan en ese momento para asegurarse de que todos están utilizando criterios similares (curiosamente a estas reuniones las llaman "War" y deben ser francamente curiosas de ver) y tras ello se pasa a la fase de "Escrow" (custodia) en la que se permiten pocos cambios en el código de manera que los equipos de testeo puedan llevar a cabo sus pruebas sin tener demasiadas variaciones entre las diferentes builds.

Así es que lo que Dani habrá estado probando este fin de semana (entre, seguramente, 10 o 15 cosas más) y que está disponible en la zona de subscriptores de TechNet y MSDN es la Escrow de la Beta 3, es decir una build que se modificará poco en cuanto a funcionalidad y que será la base de la Beta 3 que saldrá entre Abril y Mayo. Tiene suerte, porque el Padre Parada (que por cierto ha vuelto a la vida y por lo que se ve bastante afectado a nivel intelectual por este galimatías) y yo manejamos actualmente la build diaria, la build diaria de la rama de la Beta 3, y una build diaria específica para Windows Virtualization (que me tiene entusiasma-do).

Por supuesto, la última parte del proceso es la puesta en el mercado, con la versión RTM (Release To Manufacturing). Generalmente esa noche hay juerga por todo lo alto, pero al día siguiente el proceso vuelve a empezar en el punto donde se dejó, ya que hay que ponerse manos a la obra unos con la siguiente versión (Vienna en el caso de Windows), otros con el SP1.

Por último: ¿Dónde puedo conseguir una Beta de <tu producto favorito aquí>?

Saludos