java - integracion - Gestión de compilación/mejores prácticas de integración continua

integracion continua scrum

Question

¿Cómo maneja su equipo Builds?
Utilizamos Cruise Control, pero (debido a la falta de conocimiento) nos enfrentamos a algunos problemas: congelación de código en SVN, gestión de compilación
Específicamente, ¿cómo se pone a disposición un lanzamiento particular cuando el código se revisa constantemente?

En general, ¿puede hablar sobre las mejores prácticas que usa en la gestión de lanzamientos?

Answer 1

Estoy realmente asombrado de que esto no sea un duplicado, pero no puedo encontrar otro.

De acuerdo, este es el trato. Son dos preguntas separadas, pero relacionadas.

Para la administración de compilación, el punto esencial es que debe tener una compilación automática y repetible que reconstruya toda la colección de software desde cero, y llegue hasta su configuración de entregas. en otras palabras, debe construir efectivamente un candidato de lanzamiento cada vez. Muchos proyectos realmente no hacen esto, pero lo he visto quemar gente (léase "haber sido quemado") demasiadas veces.

La integración continua dice que este proceso de compilación debe repetirse cada vez que haya un evento de cambio significativo para el código (como un check in) si es posible. He hecho varios proyectos en los que esto se convirtió en una compilación todas las noches porque el código era lo suficientemente grande como para que tardara varias horas en compilarse, pero lo ideal es configurar el proceso de compilación de forma tal que algún mecanismo automático, como una hormiga script o make file --- solo reconstruye las piezas afectadas por un cambio.

Usted maneja el problema de proporcionar un lanzamiento específico preservando de algún modo la configuración exacta de todos los artefactos afectados para cada compilación, para que pueda aplicar su proceso de compilación repetible a la configuración exacta que tenía. (Es por eso que se llama "gestión de configuración"). Las herramientas de control de versiones habituales, como git o subversion, proporcionan formas de identificar y nombrar configuraciones para que puedan recuperarse; en svn, por ejemplo, puede construir una etiqueta para una compilación en particular. Simplemente necesita mantener un poco de metadatos para saber qué configuración usó.

Es posible que desee leer uno de los libros de "Pragmatic Version Control" y, por supuesto, las cosas sobre CI y Cruise Control en el sitio de Martin Fowler son esenciales.

Answer 2

Mire la integración continua: mejores prácticas , de Martin Fowler.

Bueno, he logrado encontrar un hilo relacionado , en el que participé, hace un año. Puede que también lo encuentres útil. Y así es como lo hacemos.

[Editado]

Estamos usando Cruise Control como herramienta de integración. Nos ocupamos del trunk, que es el repositorio principal de Subversion en nuestro caso. Rara vez sacamos una nueva sucursal para hacer nuevas historietas, cuando existe la posibilidad de conflictos complejos. Normalmente, sacamos una sucursal para un lanzamiento de versión y creamos la compilación de eso y lo entregamos a nuestro equipo de prueba. Mientras tanto, continuamos el trabajo en el maletero y esperamos los comentarios del equipo de prueba. Una vez que todos hemos probado, creamos una etiqueta de la rama, que es inmutable lógicamente en nuestro caso. Entonces, podemos lanzar cualquier versión en cualquier momento a cualquier cliente por si acaso. En caso de errores en el lanzamiento, no creamos etiquetas, reparamos las cosas allí en la rama. Después de obtener todo lo arreglado y aprobado por el equipo de prueba, fusionamos los cambios nuevamente en trunk y creamos una nueva etiqueta desde la rama específica para esa versión.

Entonces, la idea es que nuestras sucursales y etiquetas realmente no están participando directamente en la integración continua. Al fusionar el código de la rama de nuevo con el tronco, este código se convierte automáticamente en la parte CI (Integración continua). Normalmente hacemos correcciones de errores, para la versión específica, en las sucursales, por lo que realmente no participa en el proceso de CI, creo. Por el contrario, si comenzamos a crear nuevas historietas, por alguna razón, en una rama, entonces no mantenemos esa rama aparte demasiado tiempo. Tratamos de fusionarlo de nuevo al tronco lo antes posible.

Precisamente,

• Creamos ramas manualmente, cuando planificamos un próximo lanzamiento
• Creamos una rama para el lanzamiento y correccion de errores en esa rama en el caso
• Después de hacer todo bien, hacemos una etiqueta desde esa rama, que es lógicamente inmutable
• Por último, fusionamos la rama de nuevo en el tronco si tiene algunas correcciones / modificaciones

Answer 3

Para resumir: cree una rama copiada del tronco y ejecute / cree su versión en esa rama en el servidor de compilación.

Sin embargo, llegar a ese punto de una manera completamente automatizada usando cc.net no es una tarea fácil. Podría entrar en detalles sobre nuestro proceso de compilación si lo desea, pero probablemente sea demasiado detallado para esta discusión.

Estoy de acuerdo con Charlie en tener una compilación automática y repetible desde cero. Pero no hacemos todo lo posible para la compilación "Continua", solo para compilaciones de versiones Nightly, Beta, Weekly u Omega (GA / RTM / Gold). Simplemente porque algunas cosas, como la generación de documentación, pueden llevar mucho tiempo, y para la creación continua que desea proporcionarle al desarrollador comentarios rápidos sobre un resultado de compilación.

Estoy totalmente de acuerdo con la preservación de la configuración exacta, que es la razón por la bifurcación de un lanzamiento o etiquetado es imprescindible. Si tiene que mantener un lanzamiento, es decir, no puede simplemente liberar otra copia del tronco, entonces una aproximación de liberación de rama es el camino a seguir, pero deberá sentirse cómodo con la fusión.

Answer 4

Puede usar Team Foundation Server 2008 y Microsoft Studio Team System para realizar su control de fuente, bifurcación y lanzamientos.

Answer 5

Release Management va mucho más allá de la integración continua.

En su caso, debe usar Cruise Control para crear automáticamente una etiqueta, lo que permite a los desarrolladores seguir codificando mientras se lleva a cabo su construcción incremental.

Si su compilación es incremental, eso significa que puede activarla cada x minutos (y no para cada confirmación, porque si son demasiado frecuentes, y si su compilación es demasiado larga, es posible que no tenga tiempo de finalizar antes de que la próxima compilación intente tener lugar). La ''x'' se debe adaptar para que sea más larga que un ciclo de compilación / prueba de unidad.

Una integración continua también debe incluir el lanzamiento automático de pruebas unitarias.

Más allá de eso, un proceso de gestión de lanzamiento completo implicará:

• una serie de implementación en servidores de homologación
• un ciclo completo de homologación / UAT (prueba de aceptación del usuario)
• pruebas de no regresión
• pruebas de rendimiento / estrés
• pre-producción (y pruebas de ejecución paralela)

antes de finalmente lanzar a producción.

Nuevamente, la "gestión de versiones" es mucho más compleja que la simple "integración continua";)