Estoy usando TFS 2010. Actualmente utilizo la compilación de registro bloqueado en la rama troncal (MAIN) solamente. Y uso CI en las ramas DEV y RELEASE.Cuándo utilizar el registro de entrada privado
En nuestro equipo de gran tamaño, también hacemos gated en la rama principal y CI en las ramas dev/feature (muchas de ellas).
Gated ofrece más protección para la sucursal, pero con un equipo muy grande y una gran base de código, puede respaldar la cola si todo el equipo de desarrollo está haciendo cambios en esa rama.
CI proporciona protección con un poco más de confianza en los desarrolladores, sabiendo también que cualquier problema quedará atrapado rápidamente. Es un poco más optimista y permite que el equipo se mueva mucho más rápido, lo que es apropiado para una rama de desarrollo.
En ambos casos, los desarrolladores ejecutan pruebas unitarias y prueban el código que están cambiando. CI (afecta al equipo) y Gated (consume tiempo en la cola) no deberían reemplazar las pruebas: debería haber una explicación plausible más compleja de lo que no lo intenté.
Todo el equipo está en las ramas/dev de desarrollo usando CI durante la mayor parte del ciclo y en las sucursales superiores con mucha más gente durante la estabilización final del juego. Ambas últimas condiciones respaldan el caso de la compuerta.
En un equipo grande, también necesitamos hacer que las compilaciones de CI y las pruebas continuas se realicen en paralelo para encontrar los problemas más rápidamente cuando los tiempos de construcción no son triviales y las pruebas completas tampoco son triviales. En ese escenario, la gente está haciendo check-in, el CI está recogiendo el último lote de checkin, ejecutando una compilación y cuando una compilación cae, otra máquina está recogiendo y ejecutando las suites de prueba.
Esto es lo que hacemos también. –
Si las colas de espera están copiando, parece que el equipo se beneficiaría de la fusión de las presentaciones. Suponiendo que la mayoría de los cambios no serán rechazados, la validación de 2 o más cambios a la vez puede reducir el tiempo de espera de la cola. –
En realidad no hay una razón que yo sepa por qué no hacer Cerrada Check-In en cada cambio que haga. Sin embargo, (en general) es un requisito previo para realizar el Check-in cerrado: el tiempo total de construcción no debe ser superior a unos minutos, incluida cualquier prueba (unidad) que le gustaría realizar antes de que se acepte el check-in. . De lo contrario, se tarda mucho tiempo para que un check-in sea aceptado, o peor para el desarrollador, para ser rechazado. Para un equipo de desarrollo también es un poco más complejo, o al menos algo a lo que acostumbrarse.
La integración continua (en mi opinión, optimizada en forma de construcciones Rolling) permite que el desarrollador registre su código sin tener la incertidumbre de si será aceptado o no. Importante es que el desarrollador siempre tendrá que enfrentarse lo antes posible con los resultados finales negativos de un check-in. Si puedes lograr eso, me gusta más que los check-ins cerrados.
En un equipo muy grande con una gran base de código, gated solo está garantizado en ramas de tipo de versión de nivel superior. El equipo no puede permitirse el lujo de participar en las ramas características/dev. Debido al tamaño del equipo y la base de código, se realiza una copia de seguridad. Ver mi publicación a continuación. – bryanmac
Prefiero el Check-in cerrado en todas partes porque limita el dolor al desarrollador que se registra en lugar de compartir ese dolor con todo el equipo cuando alguien (inevitablemente) comete un error.
Como se mencionó anteriormente, es importante mantener los registros controlados rápidamente. A veces tendré un Gated Checkin que ejecuta las comprobaciones más importantes, luego una compilación de CI que se inicia después de que la verificación cerrada tiene éxito y se ejecutan las comprobaciones más lentas.
No estoy seguro de que resuelva el problema. En mi trabajo, una compilación completa + todas las pruebas tardan 24 horas en hardware nuevo. Tenemos pruebas de humo que podemos ejecutar en aproximadamente 30 minutos pero el problema es que, naturalmente, las pruebas más exhaustivas o simplemente más largas que consumen tiempo (como las pruebas de que puede migrar con éxito de una versión de una base de datos a otra con muchos datos) empujado a la categoría "larga". A menudo, el humo no capta nada, entonces CI correrá la categoría "larga" y fallarán una docena de pruebas. Para entonces, el revisor a menudo ya ha aprobado el código y, en cualquier caso, el resto del equipo ha sido herido – Mike
¿Puede explicar con sus propias palabras la diferencia entre una compilación TRIGGERED y una INTEGRACIÓN CONTINUA? – kroonwijk
Kroonwijk; Corregí mi pregunta. Debe decir Check-in cerrado, no activado. –
¡Gracias! Ahora esta claro. – kroonwijk