Lanzamiento de software / Uso de integración continua: ¿qué es lo que la mayoría de las empresas parecen usar?

7

He configurado nuestro sistema de integración continua, y ha estado funcionando durante aproximadamente un año. Finalmente hemos llegado a un punto en el que queremos hacer lanzamientos usando el mismo. Antes de nuestro sistema de CI, el proceso que se utilizó fue:

(Develop) -> Ready for release -> Create a branch -> (Build -> Fix bugs as QA finds them) Loop -> Final build -> Tag

(Develop) -> Ready for release -> (build -> fix bugs) Loop -> Tag



Our CI setup:
1 server for development (DEV)
1 server for qa/release (QA)

El segundo se ha integrado perfectamente en CI. Creo una rama cuando el software está listo para su lanzamiento, y la rama nunca cambia después, lo que significa que la compilación es reproducible sin tener que cambiar el trabajo de CI. Cualquier desarrollo futuro tiene lugar en HEAD, e incluso los lanzamientos de mantenimiento obtienen una rama completamente nueva y un trabajo completamente nuevo, que permanece en el sistema de CI para siempre, y más.

El primer método es más difícil de adaptar. Si la rama cambia, la compilación no se puede reproducir a menos que yo use la etiqueta para construir [los trabajos en el servidor de CI usan la rama para QA / LIBERAR, y HEAD para las compilaciones de desarrollo].

Sin embargo, si uso la etiqueta para compilar, tengo que crear un nuevo trabajo de CI para compilar desde la etiqueta (perder registro de cambios en el servidor), o cambiar el trabajo existente (perder la configuración original del trabajo).

Sé que esto suena complicado, y si es necesario, reescribiré / editaré para explicar mejor la situación. Sin embargo, mi pregunta:

[Si lo hay] qué proceso usa su empresa para lanzar software utilizando sistemas de integración continua. ¿Se hace incluso usando el sistema CI, o manualmente?

    
pregunta Sagar 08.02.2011 - 00:06

3 respuestas

2

Nos ramificamos en el lanzamiento. Creo que es inevitable si liberas parches, porque parchear significa volver atrás y actualizar el lanzamiento. También tendemos a mantener la codificación durante el proceso de RTM, lo que significa que la versión enviada está desactualizada antes de abandonar el edificio. Algunos de nuestros usuarios omiten versiones, por lo que ahora tenemos dos versiones activas en el campo más la nueva versión en la que estamos trabajando ahora. Así que tenemos 1.0, 1.1, 2.0, 2.1, 2.2 y pronto 3.0 en uso (y recibimos llamadas de soporte para todos ellos). La prueba de la matriz de parches / versiones mantiene el control de calidad bastante ocupado.

Nuestro proceso es más como este:

(develop) -> branch to QA -> RTM -> ship -> patch branch ...
          -> keep developing in trunk -> merge patches ...

Me interesará ver qué otras opciones aparecen.

    
respondido por el Мסž 08.02.2011 - 05:01
1

Usamos lo siguiente: (Desarrollar en línea principal) - > Pruebas de fase 1 - > Pruebas de fase 2 - > (Rama de la línea principal) - > Pruebas de fase 3 - > RTM - > Parche en rama

Cada compilación está etiquetada después del hecho. La construcción de oro tiene una etiqueta más tradicional. El desarrollo comienza a funcionar en la próxima versión de la línea principal durante las pruebas de la fase 3.

    
respondido por el Arcege 08.02.2011 - 08:43
1

Construimos desde la etiqueta. El trabajo de compilación está parametrizado (el parámetro es el nombre de la etiqueta), por lo que solo fue necesario crearlo una vez.

    
respondido por el Jeff Knecht 08.02.2011 - 14:34

Lea otras preguntas en las etiquetas