Traducción de la entrada "Tengo que publicar rápido"
-
A medida que nos acercamos al lanzamiento de la OTA-6, me gustaría recopilar los puntos que creo más importantes de esta entrada:
-
Todo el mundo quiere "Publicar mas rápido", sin lugar a dudas.
-
" Publicar más rápido" depende de tener la suficiente confianza de que el software que se publica a estable está bien probado, cosa que nosotros no tenemos. Algunas cosas que se traducirían en tener una mayor confianza en la publicación incluyen:
- Test automáticos en todos los componentes del sistema.
- Test de integración entre todos componentes del sistema.
- Test automáticos del dispositivo completo, como el fabuloso "Laboratorio Frankenstein de dispositivos" de Canonical.
- Pruebas manuales formalizadas por los usuarios quienes pueden confirmar la estabilidad.
-
Incluso con total confianza en la publicación de código (pero especialmente sin ella), un modelo de publicación automático requiere la capacidad de retroceder a una versión anterior de las aplicaciones o del sistema completo.
-
Aparte: quiero experimentar con uno de los nuevos modelos de publicación atómicos como OSTree, que permite formatos de empaquetado agnósticos para ser instalados encima. De mi rápida incursión, veo:
-
Beneficios: Retrocesos automáticos y manuales, diferenciación automática y raíces conmutables.
-
Las desventajas que hacen de eso una idea a largo plazo o imposible para nuestros dispositivos:
- Probablemente requieren versiones del kernel mas nuevas que la 3.4 o 3.10
- No tenemos suficiente poder de ingeniería para inventar una solución que pueda permitir convertir una imagen del sistema a OSTree al vuelo, así que seguramente necesitaremos que los usuario lo cambien manualmente.
-
-
Creo que traer el canal "edge" como un lugar para hacer grandes migraciones fuera con la cadencia de publicación normal va a tener un gran impacto en la rapidez con la que podrémos publicar en el futuro. Anteriormente, el trabajo de @mariogrip para traernos Libhybris habría tenido que esperar hasta después de que la OTA-6 llegara, y luego se habría retrasado hasta la OTA-7 hasta que tuviéramos la confianza adecuada en ella. Con edge, podemos tener personas que nos ayuden a probar estos grandes cambios con la posibilidad de volver atrás y sin interrumpir a los usuarios actuales.
Para responder a mi retrospectiva anterior: OTA-6 todavía no esta (todavía :P) quitando los TDS. No hemos alcanzado la fecha limite establecida, pero aun estaremos dentro de nuestro ciclo de 6 a 8 semanas cuando se publique. Esto incluye nuestra etapa etapa de pruebas y administración de publicaciones, en la que estamos actualmente. Todo esto mientras no tengo prisa en que nos echemos encima una publicación antes de que estemos seguros de que estamos preparados.
Hemos acabado en "Tengo que publicar mas despacio" en este ciclo sin lugar a dudas. Espero hacer las mejoras que que hemos identificado aquí para que "voy a publicar más rápido" pueda convertirse en realidad. También espero poder llevar a cabo nuestra gestión de lanzamientos para poder alcanzar el desarrollo en 2 a 4 semanas y 2 semanas de prueba. Esto significa que tendremos publicaciones más rápidas, pero todavía no haremos publicaciones rápidas.
Nota importante para cualquier persona interesada en contribuir a... básicamente cualquier cosa que he dicho aquí: celebraré una reunión de desarrollo de la OTA-7 al principio del ciclo donde discutiremos como mejorar durante el ciclo de la OTA-7 y recogeremos los fallos en el sistema de seguimiento para el lanzamiento. Solo los tickets asignados se agregarán a este hito, por lo que si tienes un error que quieres corregido ahora, ¡es el momento de involucrarse para ayudar a solucionarlo! Suscríbete a este issue de GitLab para obtener más información a medida que se acerca el día.
Enlaces de interés:
- Entrada en el foro original: https://forums.ubports.com/topic/1813/gotta-release-fast/23
- Issue de Gitlab para obtener más información: https://gitlab.com/ubports/dev/project-management/issues/1 -
-
@krakakanok thank you !!
