Desventajas de un check-in cerrado en TFS

Question

Desventajas de un check-in cerrado en TFS

Siempre he trabajado con la Integración Continua (CI) en TFS. Sin embargo, en mi último proyecto comenzamos a usar el disparador de check-in cerrado.

¿Hay alguna desventaja al usar un check-in cerrado? Porque si impide que el equipo verifique el código roto, ¿cuál es el propósito de un activador de CI?

23

continuous-integration tfs checkin

Author: mguassa, 2015-07-28

Source

2 answers

Los checkins cerrados hacen que comprometerse sea más difícil y más lento. Eso es comúnmente una mala cosa, porque:

En TDD, los miembros deberían ser capaces de enviar confirmaciones con pruebas fallidas
Reportar errores como pruebas fallidas es súper útil
Al cooperar en una rama de WIP (work in progress), los miembros deben ser capaces de empujar cambios sucios para ponerlos rápidamente a disposición de otros
Cuando se trabaja en un gran cambio, puede ser útil dejar que otros miembros revisen el trabajo inacabado antes de invertir el tiempo para terminar
A muchas personas les gusta cometer regularmente trabajos incompletos como una forma de instantánea/copia de seguridad
cometer un trabajo incompleto es genial cuando se cambia con frecuencia entre ramas (almacenar solo ayuda limitada, en particular para archivos nuevos)
QA no debe estar limitado en el tiempo, pero la confirmación no debe tomar mucho tiempo
El control de calidad del código debe ocurrir en un entorno limpio de todos modos, el entorno local dado probablemente no es tan prístino como un CI servidor
Del mismo modo QA a menudo se debe hacer con una matriz de entornos (diferente versión del compilador, diferentes navegadores, diferentes sistemas operativos, ...), los costes de instalación se invierten mejor en una CI central

Así que los escenarios donde gated checked están bien:

Su VCS hace que la ramificación sea difícil, o su empresa no permite la ramificación
El proyecto es pequeño
Solo un desarrollador
No IC present

1

Author: tkruse,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-07-26 10:42:50

score 34 · Accepted Answer

Gated checkin es una forma de construcción de integración continua. En TFS, crea un shelveset que contiene el código que se está validando, y luego ejecuta una compilación de ese código. Solo si ese código se compila correctamente y todas las pruebas unitarias configuradas pasan el código realmente se confirma.

La integración continua es diferente in en CI, el código se confirma independientemente de lo que ocurra como resultado de la compilación. Si una compilación de CI falla debido a que se ha enviado un código incorrecto, el código sigue allí, en control de fuente, disponible para que todo el mundo lo tome.

Ahora la parte basada en la opinión: Gated checkin es genial si tienes un gran número de desarrolladores de diferentes niveles de habilidad/experiencia, ya que evita que el código roto entre en el control de código fuente. La desventaja es que aumenta el tiempo entre el código que se confirma y el código que está disponible para otros, y por lo tanto puede llevar a situaciones en las que las personas están sentadas alrededor girando sus pulgares esperando que se complete la compilación exitoso.

Recomiendo usar el check-in cerrado como medida provisional. Si tienes una tonelada de construcción de check-in cerrada fallando, entonces está haciendo su trabajo y evitando que el código malo se comprometa. Si, con el tiempo, el equipo madura y las compilaciones de check-in cerradas fallan con poca frecuencia, entonces está sirviendo menos propósito y debe cambiarse a la integración continua y corregir las compilaciones fallidas a medida que vienen, en lugar de retrasar cada confirmación en la remota posibilidad de que haya un problema.