cómo automatizar o facilitar la construcción/prueba multiplataforma antes de comprometerse?

Question

Nuestro software está basado en plataformas Linux y Windows. Dependiendo de la preferencia del desarrollador, una contribución se desarrolla y prueba en cualquiera de las plataformas y luego se compromete con nuestro repositorio de subversión. Luego resulta que la contribución no se basa en la otra plataforma, y ​​se debe hacer una corrección. La solución en la otra plataforma puede romper nuevamente la construcción en la plataforma original, y así sucesivamente.

Prefiero ver que se crea una contribución (y se prueba la regresión) en la otra plataforma antes de comprometerla. Tenemos un servidor de compilación continuo (CruiseControl), pero ese servidor se crea a partir del repositorio. Estoy buscando una solución en la que el servidor de compilación continua se base en la otra plataforma como una verificación previa a la confirmación y luego se comprometa si la compilación y la prueba tienen éxito.

¿Alguna sugerencia?

Answer 1

Matheiu Godlewski ha hecho una buena sugerencia en el CruiseControl wiki

Si combina su sugerencia con el elemento veto, creo que debe ser fijado.

Answer 2

Puede ser más fácil tener dos ramas, una donde la gente se registra y otra en la que fusionan sus cambios después de haber pasado la integración continua.

Answer 3

Teamcity controla la confirmación comprobada previamente, es posible que pueda hacer algo con las nuevas funciones de encadenamiento de compilación en 4.0 (http://www.jetbrains.com/teamcity/features/newfeatures.html). Los agentes son multiplataforma y se pueden configurar para que solo ejecuten bits particulares de la compilación, por lo que posiblemente se puedan configurar solo para ejecutar un subconjunto de pruebas.

Tenga en cuenta que no he hecho esto en realidad :)

Answer 4

se utilizó una estructura de encargo y una instalación de ensayo que remotamente podría desplegar en múltiples sistemas operativos (y varios productos de base de datos en múltiples sistemas operativos). Esto se hizo como una creación nocturna con una regla que corrige sus errores a la mañana siguiente.

No completamente continuo entonces, pero eso es potencialmente mucho trabajo para hacer en un gancho precompromiso. Especialmente si su repositorio de control de origen bloquea los archivos afectados durante la ejecución del enlace de precompilación.

Creo que hay una diferencia entre una prueba de integración continua que se ejecuta durante el día, por compromiso y una prueba de integración del sistema que se ejecuta todas las noches.

Answer 5

Douglas Leeder sugirió una rama de "integración": lo bueno de esto es que es posible automatizar. Si las pruebas pasan, combine con el 'tronco'.

Algunos sistemas de control de versiones (por ejemplo, bzr/hg/git) hacen esto más fácil que otros, pero es posible en la mayoría.