¿Qué progtwigs de control de versiones pueden hacer cumplir la ejecución y el pase de las testings antes de la integración de los cambios?

En mi trabajo, actualmente usamos el control de versiones Aegis / SCM. La forma en que lo tenemos configurado, tenemos un montón de testings y obliga a que las siguientes cosas sean ciertas antes de que se pueda integrar un cambio:

  • El set completo de testings debe haberse ejecutado.
  • Todas las testings deben haber pasado.

Con el desarrollo basado en testings (TDD), estos parecen requisitos razonables. Pero no he oído hablar de ninguna manera de hacerlo con otros sistemas de control de versiones. (Actualmente no estamos planeando cambiar, pero me gustaría saber cómo hacerlo en el futuro sin utilizar Aegis).

Me interesaría cualquier VCS (distribuido o no) que pueda hacer esto, también estoy interesado en cualquier complemento / extensión de VCS existente que lo permita. Preferiblemente software de fuente abierta.

ETA: OK, parece que lo habitual es tener el software de continuous integration VCS +, y ejecutar las testings se automatiza como parte de la compilation, en lugar de como un paso separado. Si lo entiendo correctamente, eso todavía te permite confirmar el código que no pasa las testings, solo te avisan al respecto, ¿es así? ¿Hay algo que te impida poder integrarlo / comprometerlo?

OMI es mucho mejor utilizar un sistema de continuous integration como CruiseControl o Hudson si quiere hacer cumplir que sus testings pasan, y hacer que la construcción en lugar del control dependa de los resultados de las testings. Las herramientas son sencillas de configurar, y usted obtiene las ventajas de la notificación integrada de los resultados (a través de correo electrónico, RSS o complementos del browser) y los resultados de los informes de testing a través de una página web.

Con respecto a la actualización de la pregunta, tiene razón: VCS + CI le permite confirmar el código que no pasa las testings; con la mayoría de las configuraciones de CI, no obtendrá una versión final de su producto a less que pasen todas las testings. Si realmente desea evitar que alguien se comprometa, a less que se aprueben todas las testings, tendrá que usar ganchos en el VCS, como otros han sugerido. Sin embargo, esto me parece difícil de tratar: los desarrolladores tendrían que ejecutar todas las testings cada vez que realizaran un checkin, incluidas testings que no son relevantes para el checkin que están realizando, o tendrían que haga algunos ganchos VCS muy granulares que solo ejecutan las testings que son relevantes para un logging determinado. En mi experiencia, es mucho más eficiente confiar en los desarrolladores para que ejecuten localmente las testings relevantes, y hacer que el sistema de CI tome nota de los errores ocasionales.

Con subversion y git puede agregar ganchos de pre-commit para hacer esto.

Parece que necesita ver Integración continua (o una variante de).

Piensa que Git tiene un gancho en aplicar el parche también.

Subversion y git lo soportan a través de los enganches de precompromiso.

Visual Studio Team System es compatible con esto de forma nativa a través de políticas de logging .

Creo que Rational ClearCase también lo admite, aunque nunca lo he visto así, por lo que no puedo decirlo con certeza.

Usamos git y buildbot para hacer algo similar, aunque no exactamente lo mismo. Damos a cada desarrollador su propio repository de Git, y tenemos el buildbot configurado para build cualquier momento empuja a uno de esos repositorys. Luego, hay alguien que actúa como integrador, que puede verificar el estado del buildbot, revisar los cambios y fusionar sus cambios o decirles que arreglen algo, según corresponda.

Hay muchas variaciones de este flujo de trabajo que podría hacer con Git. Si no quería que alguien fuera el integrador de forma manual, probablemente podría configurar el buildbot para ejecutar un script con éxito, lo que fusionaría automáticamente el cambio de esa persona en el repository principal (aunque tendría que tratar con casos en los que la fusión automática no funcionó, y debería probar también los resultados de la fusión, ya que incluso el código que se combina de manera limpia a veces puede presentar otros problemas).

Creo que el software de continuous integration, como team city, le permite realizar precompromeo de compilation y testing. No sé de ningún vcs que lo proporcione directamente … puede haber alguno como el que usa, pero no estoy familiarizado con ellos.

También puede usar ganchos de precompromiso en Perforce. Y, si usted es una tienda .NET, Visual Studio puede configurarse para requerir loggings "bloqueados".

VSTS con elementos de trabajo personalizados, ¿verdad? No veo nada de malo en usar esto. Construido en informes. La elección de automatizar. Por qué no?

Lo que hago aquí es seguir un patrón de twig por tarea que le permite probar el código ya enviado al control de versiones pero manteniendo la línea principal intacta. Más sobre este patrón aquí .

Puede encontrar más información sobre estrategias de integración aquí y también comentarios sobre Mark Shuttleworth sobre el control de versiones aquí .

La mayoría de las implementaciones de CI tienen un mecanismo para rechazar los loggings que no cumplen con todos los criterios (lo más notable es pasar todas las testings). Se llaman por diferentes nombres. VCS debería hacer lo que mejor saben hacer … código fuente de la versión.

  • TeamCity – Compromiso probado previamente
  • TFS – Check-ins privados
Intereting Posts