build - Cuándo utilizar el registro de entrada privado
continuous-integration tfs2010 (3)
No hay realmente una razón por la que sepa por qué no hacer un Check-in controlado en cada cambio que realice. 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 resultados finales negativos de un check-in. Si puedes lograr eso, me gusta más que los check-ins cerrados.
Estoy usando TFS 2010. Actualmente utilizo la compilación de Check In Gated solo en la rama troncal (MAIN). Y uso CI en las ramas DEV y RELEASE.
- ¿Por qué no utilizar compilación de Check In Gated en todas las sucursales?
- ¿En qué escenarios, no debe usar la creación de Check In Gated en las ramas DEV y RELEASE?
- ¿Es mejor usar siempre la compilación de Check In establecido en cada rama?
En nuestro gran equipo, también estamos protegidos 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 se detectará 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 feature / dev usando CI durante la mayor parte del ciclo y en las ramas más altas con mucha más gente durante la estabilización final del juego. Ambas últimas condiciones respaldan el caso de Gated.
En un equipo grande, también necesitamos hacer que las compilaciones de CI y las pruebas continuas se hagan en paralelo para encontrar los problemas más rápidamente cuando los tiempos de construcción no son triviales y los conjuntos de prueba completos 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.
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.