OpenSUSE Factory, el nuevo proceso de desarrollo

OpenSUSE está inmerso en cambios, uno de ellos, quizás el más importante es el nuevo desarrollo de openSUSE Factory que lo hace más estable.

 

Un mes despues de que openSUSE anunciara que la rama de Factory se convertía en una auténtica rolling release en la que poder disfrutar de las últimas aplicaciones, entornos de escritorio o Kernel, en openSUSE news nos comentan que ya tenemos las primeras métricas para ver la aceptación que está teniendo esta propuesta.

 

La evolución de Factory es bastante espectacular pasando de 1952 usuarios en Junio a 5969 a finales de Agosto, mientras Tumbleweed que debería ser reemplazada a medio plazo, sorprendemente sigue manteniendo su cuota de mercado con 5471 en Junio y 5637 a finales de Agosto.

 

 

Factory, tal como hasta ahora se conocía es el repositorio de openSUSE de pruebas. Es decir, después del lanzamiento oficial de una nueva versión, se empezaba a trabajar en la siguiente y eso se hacía mediante este repositorio.

 

Se incluían nuevas versiones de software y se iban corrigiendo errores y puliendo detalles en él. Por tanto no era un repositorio para una máquina del día a día y sí una para testear informar de fallos y participar en el desarrollo de una u otra manera.

Pero eso ahora ha cambiado. openSUSE Factory se ha convertido en un repositorio no de pruebas, si no uno en el que se incluye lo último en software pero ha pasado una serie de pruebas que lo hacen estable.

Hasta ahora Factory era el sitio donde se llevaba a cabo la integración de las nuevas versiones de software. Cuando una nueva versión de un paquete era liberada, cuando ese paquete se empaquetaba para openSUSE, se incluía en este repositorio. Y no había un control previo en una máquina de trabajo normal de posibles bugs o errores, eso se pulía en Factory.

Del desarrollador –> a Factory –> y directamente al usuario.

Visión general del proceso de desarrollo.

El proceso de desarrollo completo se detalla en esta página. Consta de los siguientes pasos:

    La hoja de ruta y planificación de características se gestiona por el encargado de publicaciones, que crea una hoja de ruta inicial. Mientras tanto, los desarrolladores establecen los objetivos técnicos para la distribución basándose en las fechas previstas de publicación y congelación.

 

    El desarrollo de paquetes comienza en un proyecto de usuario en el OBS. El desarrollador de paquetes puede trabajar ahí si afectar a nadie más. Una vez que el paquete es lo suficientemente bueno se puede crear una una solicitud de envío a un proyecto de desarrollo.

    La integración con el proyecto de desarrollo continua, supervisada por encargados de proyecto que mantienen un ojo en la calidad técnica de las solicitudes de envío y en el estado general del proyecto de desarrollo. Tras una integración exitosa, los encargados de proyecto crean una solicitud de envío para Factory.

 

    El proceso de revisión se asegura de que todos los paquetes que van camino de Factory pasen por 4 (a veces 5) revisiones:
        Factory-Auto: un script que comprueba las reglas básicas 
        Legal-Auto: un script que comprueba si la licencia del paquete está en la base de datos de las permitidas 
        Repo-Checker: una comprobación automática más en profundidad (y lenta) 
        Equipo de revisión: comprobación por personas de la solicitud
        Opcional: comprobación por personas del Equipo de seguridad (si Legal-Auto lo estima necesario)

    La Integración con Factory se supervisa por el encargado de Factory y los encargados de publicaciones que aceptan la solicitud de envío que llega de los distintos proyectos a Factory [9]. Mayormente toman las decisiones en base a fechas y factores políticos como las congelaciones que pueden estar vigentes mientras el proceso de revisión ya se ha ocupado de la calidad. En algunos casos deciden que se necesita un proyecto de transición. Cuando sucede, la solicitud de envío tiene que pasar por openQA y debe producir un resultado positivo. Una vez todo va bien, el encargado de Factory podría aceptar el proyecto de transición para que todas las solicitudes de envío que pertenecen a él se chequeen en Factory.

    El Quality Assurance Process (openQA) funciona todo el tiempo. El OBS genera imágenes ISO de forma periódica y se las hace pasar por un conjunto de tests predefinidos. Si se encuentran problemas se crea un informe que recoge los fallos en la citada ISO. En la actualidad, openQA se dedica principalmente al testeo de proyectos de transición y de imágenes de Factory a probar (Factory-To Test).

 

    Factory-To Test. En el modelo actual de Factory, Factory-To Test representa | el proyecto que almacena varias instantáneas de Factory que son candidatas para la publicación si la calidad fuera suficientemente buena en openQA.

 

    Proceso de publicación. En base a fechas y a resultados del proceso QA, el encargado de publicaciones puede liberar una milestone o beta. Quién ocupe el puesto en ese momento se hace cargo de las tareas de la publicación: calcula los códigos hash (verificación) MD5/SHA1 de la ISO, configura los repositorios, prepara los servidores espejo (mirrors) semilla, distribuye los productos y avisa a marketing para que comunique la publicación.

 

    Los tests públicos tienen lugar después de la publicación de una milestone, normalmente en hardware real y en menor medida en máquinas virtuales.

 

No mucho después de la publicación de la beta (última milestone antes de la congelación total), el equipo de publicación crea una rama separada de Factory para la publicación y usa el proceso de actualizaciones de mantenimiento para estabilizarla.

 

Si te ha gustado el artículo inscribete al feed clicando en la imagen más abajo para tenerte siempre actualizado sobre los nuevos contenidos del blog: