R-RELEASE

R-RELEASE FAQ

Preguntas frecuentes sobre los R-releases

warning: file_get_contents(http://www.telize.com/geoip/54.198.2.110) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /var/www/www.4d.com/docs/includes/common.inc(1762) : eval()'d code on line 4.

¿Cómo se desarrollan las nuevas funcionalidades en los R-releases?

Cada nueva funcionalidad se desarrolla exclusivamente en la rama de desarrollo principal. Cada funcionalidad se desarrolla de una manera que nos permite desactivarla. Luego, para cada funcionalidad, realizamos pruebas automatizadas y/o manuales según el tipo de funcionalidad. (Damos prioridad a las pruebas automatizadas, que se puede volver a realizar en cualquier momento.) 

 

Cada 3-4 meses, por ejemplo, creamos una nueva rama 4D v1 Rx de la rama principal de desarrollo. Cuando se crea la rama, sólo se mantienen las funcionalidades que están "listas" (es decir, 100% probadas). Desactivamos todas las demás funcionalidades cuyas pruebas no están completas, incluso si están a punto de terminar. Cualquier funcionalidad que esté "casi terminada" se pospondrá hasta el próximo R-release.

 

El concepto es entregar únicamente cuando la versión esté lista, no cortar funcionalidades o disminuir la calidad sólo para entregar en una fecha determinada.

R-releases y bug fixes: ¿Son los mismos bug fixes en 4D v15.x que en v15 Rx?

La respuesta es no. Sin embargo, los R-releases por supuesto incluyen correcciones de errores. Pero es sólo una cuestión de sincronización. La razón de esta desincronización se debe en realidad al propio proceso de desarrollo de Ios R-releases.

Se ofrecen notas de lanzamiento para R-releases y para versiones menores, para que pueda saber qué bugs se han corregido en un lanzamiento.
 
Para profundizar en los detalles, aquí están los diferentes pasos cuando un bug se corrige en 4D v15.x (lo mismo para 4D v14.x):

  • Se informa un bug en, digamos, 4D v15.x
  • El bug se investiga y una solución se lleva a cabo en la rama de desarrollo principal.
  • La corrección del bug se prueba y es validada por nuestro equipo de pruebas, siempre en la rama de desarrollo principal. La prueba puede tardar algunos días, dependiendo del tipo de bug y sus posibles repercusiones.
  • Una vez que la solución se valida, se integra a la rama 4D v15.x. A continuación, al siguiente día se lanza el Nightly Build en el foro.

Cuando nos acercamos a un envío de lanzamiento menor público, la rama se congela, por lo general por un periodo de 3 a 5 semanas. "Frozen" significa que no hay más correcciones de bugs integradas en la rama y ​​sólo se realizan pruebas manuales. Si de alguna manera una corrección anterior conduce a una cuestión secundaria (que no se detectó durante la prueba automática), una nueva corrección se realiza en la correción del bug inicial, o se elimina el código inicial de corrección del bug. Luego la versión se lanza como un lanzamiento menor.
 

Cada cambio de código puede potencialmente conducir a nuevos problemas, por lo tanto, esas tres semanas de pruebas manuales (con dos semanas adicionales previstas en caso de cualquier problema de bloqueo, que necesitaríamos para realizar pruebas una vez más).
 
Ahora, en relación con la nueva implementación de funcionalidades, el desarrollo se lleva a cabo exclusivamente en la rama principal de desarrollo. Por ejemplo, la rama 4D v15 R2 ha sido creada a partir de la rama de desarrollo principal, y esta rama se creó en febrero de 2014. Por lo tanto esta rama incluye todas las nuevas funcionalidades implementadas a partir de 4D v15, así como también todas las correcciones de bugs realizadas en la rama de desarrollo principal hasta esa fecha.

 
Las funcionalidades que no son suficientemente estables/maduras se desactivan y luego la rama se congela. Absolutamente nada entra (cambios de última hora, cambios de código minúsculos), salvo correcciones de bugs relacionadas con las nuevas funcionalidades o correcciones de bugs importantes (como showstoppers, corrupción de datos, etc.) Mientras tanto, la versión se ha desplegado para producción en nuestros sistemas internos. Así es como aseguramos la estabilidad en los R-releases.
 

Este es un concepto que Google, por ejemplo, seguido por Chrome. La entrega de una actualización con problemas conocidos es mejor que la liberación de una versión probada insuficientemente con otros problemas posibles desconocidos. Esto es radicalmente diferente al método habitual, en el se solucionan tantos problemas como sea posible, lo más rápido posible. Aquí es de donde vienen los ciclos cortos.

 
Como otro ejemplo, la rama 4D v14 R5 incluye todas las correcciones de bugs incluidas en la rama de desarrollo principal hasta ahora. Esas correcciones se han probado durante varios meses y no sólo por unos pocos días como 4D v15.x (en Nightly Builds). Así es como podemos asegurar que una corrección de bug dada no introduzca ninguna inestabilidad. La versión será programada para entrega tres meses más tarde.

¿Qué papel juegan los Nightly Builds?

Las versiones Hotfix se introdujeron antes de empezar a ofrecer acceso a los Nightly Builds. En ese momento, teníamos un proceso build automático, pero sólo pruebas automatizadas básicas.

 
Una versión hotfix se ejecuta por un período de 3 a 5 días de pruebas manuales (en comparación con 3-5 semanas para un lanzamiento menor).
 
Desde 2013-2014, empezamos a invertir fuertemente en las pruebas automáticas. El proceso de construcción ahora se ejecuta una vez por hora (desde un conjunto de ordenadores que crean automáticamente las versiones 4D v13, 4D v14, 4D v14 Rx y así sucesivamente, al igual que con Wakanda, para Mac OS X 32 y 64-bit, Windows 32 y 64 bits, Linux 32 y 64 bits y todo este trabajo para cada idioma disponible, como inglés, francés, alemán, japonés y así sucesivamente. Las versiones creadas se distribuyen automáticamente a un grupo de equipos de prueba, donde se ejecutan no sólo la unidad de pruebas, sino también muchas pruebas totalmente automatizadas con las aplicaciones 4D. Hemos mejorado 4D para este fin, con funcionalidades tales como FORM SCREENSHOT desarrolladas con este tipo de pruebas en mente.

 
Como resultado, los Nightly Builds han alcanzado un nivel de calidad igual al de los hotfixes anteriores, en muchos casos incluso mejor.

 
Por supuesto, seguimos mejorando el proceso. También estamos diseñando nuevos comandos en una base regular para facilitar la comprobación automática y naturalmente, estos comandos también estarán disponibles para nuestros clientes. 

¿Los Nightly Builds estarán disponibles para los R-releases?

. Los Nightly Builds serán entregados, pero sólo si se encuentra un problema importante en un R-release: por ejemplo problemas de corrupción de datos, crashes mayores, etc.
 

A diferencia de 4D v14 y 4D v15 los Nightly Builds, R-release, no serán distribuidos a través del foro 4D sino utilizando el mismo enlace de descarga que el R-release oficial. (Puede acceder al enlace desde su cuenta 4D Store.)

¿Los R-releases son para despliegue?

Por supuesto que ¡! Los R-releases le dan la oportunidad de ver cuáles serán las nuevas funcionalidades de la próxima versión principal, para jugar con ellas y darnos su opinión, pero no es sólo eso.
 

En los últimos años, empezamos las pruebas beta tempranas y esperando retroalimentación temprana en el ciclo de desarrollo, pero no funcionó. Los desarrolladores daban un vistazo rápido a las nuevas funcionalidades y eso era todo. Generalmente, los desarrolladores esperan de 0.2 a 0.3 versiones, sólo entonces comenzaban a probar y a aprender que algunas nuevas funcionalidades no eran totalmente utilizables como opciones faltantes o cualquier otras cosa que podría ser útil en sus aplicaciones. 4D hacia el 95% del trabajo, pero el 5% de lo que se necesitaba para que la funcionalidad fuera plenamente utilizable faltaba.

 
En ese momento ya estábamos cerca de la beta para la TNV (la próxima versión), por lo que ya era demasiado tarde para tener en cuenta la retroalimentación del cliente. El resultado es que la funcionalidad se convirtió en una funcionalidad totalmente utilizables en dos o incluso tres versiones principales más tarde.

 
Así, la calidad general no era perfecta, ya que se hacían muchos cambios al mismo tiempo.
 
Si da un vistazo a sitios y blogs de noticias de informática, "entrega continua" es un tema primordial por estos días y casi todos están de acuerdo en que es la clave para mejorar la calidad para deshacerse del problema del punto-cero (es decir, tener que esperar 0.2 o 0.3 versiones antes de entrar en producción).
 
Una clave para la entrega continua es que sólo funciona si el usuario final está realmente utilizando el producto, no sólo probándolo.