¿Cuándo hacer revisiones de código al hacer una integración continua?

Estamos tratando de cambiar a un entorno de integración continua, pero no estamos seguros de cuándo hacer revisiones de código. Por lo que he leído sobre la integración continua, deberíamos intentar registrar el código tantas veces al día. Supongo que esto significa incluso para características que aún no están completas.

Entonces la pregunta es, ¿cuándo hacemos las revisiones de código?

No podemos hacerlo antes de ingresar el código, porque eso ralentizaría el proceso en el que no podremos realizar registros diarios, y mucho menos registros múltiples por día.

Además, si el código que estamos registrando simplemente se compila pero no está completo, la revisión de código no tiene sentido, ya que la mayoría de las revisiones de código se realizan mejor cuando se finaliza la función. ¿Significa esto que debemos hacer revisiones de código cuando se completa una característica, pero ese código no revisado entrará en el repositorio?

En mi opinión, debe revisar el código antes de que se publique en la línea principal para que la línea principal solo tenga el código de mayor calidad.

OTOH, un buen punto podría ser que '¿por qué molestarse en revisar si la automatización de prueba de CI no se ha ejecutado en él?', Por lo que quizás lo mejor sería dar a los desarrolladores una rama privada que el servidor de CI construirá y probará para ellos . De esa manera, primero se comprometen y presionan allí, luego, una vez que pasa, lo revisan y luego se combinan con la línea principal (donde obtendrá otra ejecución a través del servidor CI).

Definitivamente, debe revisar el código que no completa las características para asegurarse de que el andamiaje para las características futuras esté en su lugar, o al menos que no haya nada que impida que se implementen dichas características futuras.

Además, tenga en cuenta que las revisiones de código no tienen que ser lentas o sincrónicas: una herramienta como gerrit o reviewboard o similar puede hacerlas asíncronas y bastante indoloras.

(Divulgación completa: solía trabajar para SmartBear, creadores de Code Collaborator, una herramienta de revisión de código)

¿Configurar la programación de pares?

Todo el código se revisa a medida que se escribe sin extender el proceso o introducir otro paso.

Aquí está el extracto del autor de entrega continua:

Jez Humble escribe como:

Actualmente estoy escribiendo una publicación de blog sobre este tema. La respuesta corta es esta:

• La mejor manera de revisar el código es a través de la programación de pares
• Es una mala idea fusionar la puerta de entrada a la línea principal, creando una rama separada, por ejemplo, en un proceso de revisión formal. Esto inhibe la integración continua (la mejor manera de reducir el riesgo de cambios incorrectos, que es lo que realmente desea lograr).
• Creo que Gerrit es una buena herramienta, pero debería usarse después del check-in (de hecho, así es como está diseñado). Parte del trabajo de los desarrolladores senior es revisar todos los registros. Podrían, por ejemplo, suscribirse a un feed.

Para resumir: la revisión del código es buena. Muy bien, deberíamos hacerlo continuamente, a través de la programación de pares y la revisión de confirmaciones. Si un desarrollador senior encuentra un mal compromiso, debe emparejarse con la persona que lo cometió para ayudarlo a solucionar el problema.

La combinación de compuerta a línea principal en una revisión formal es mala, y crear ramas para hacerlo es muy malo, por la misma razón que las ramas de características son malas.

Gracias,

Jez

el enlace original es: https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ

No sé si es la mejor manera de hacerlo ... pero explicaré cómo lo hacemos. Uno o más desarrolladores trabajan en una rama determinada y confirman su código con la mayor frecuencia posible para evitar perder el tiempo en la fusión que de otra manera no habría sucedido. Solo cuando el código está listo se compromete en la cabeza. Ahora eso es para los commits y la rama / head.

En cuanto a la revisión del código, utilizamos Sonar como nuestra herramienta de integración continua (y Maven / Jenkins para interactuar con Sonar) para proporcionarnos nuevos resultados de prueba, cobertura de código y revisión automática de código todas las mañanas (las construcciones se realizan todas las noches) para que podamos los desarrolladores pueden pasar un máximo de una hora cada mañana para solucionar sus problemas / olores de código. Cada desarrollador se responsabiliza (¡también se enorgullece!) De la función que está escribiendo. Ahora, esa es la revisión automática de código, que es excelente para encontrar posibles problemas técnicos / arquitectónicos, pero lo más importante es probar si estas nuevas características implementadas están haciendo lo que la empresa quiere que hagan, correctamente.

Y para eso, hay dos cosas: pruebas de integración y revisión de código de pares. Las pruebas de integración ayudan a tener una confianza razonable de que el nuevo código no rompe el código existente. En cuanto a la revisión del código de pares, lo hacemos los viernes por la tarde, que es un momento un poco más relajado para hacer eso :-) Cada desarrollador se asigna a una rama en la que no trabaja, toma un tiempo leer los requisitos de la nueva característica primero, y luego verifica lo que se ha hecho. Su trabajo más importante es asegurarse de que el nuevo código funcione como se espera, dados los requisitos, no rompa nuestras propias "reglas" (use este objeto para eso y no ese), sea fácil de leer y permita Extensión fácil.

Por lo tanto, tenemos dos revisiones de código, una automática y otra "humana" e intentamos evitar ingresar código no revisado en la rama HEAD. Ahora ... A veces sucede por varias razones, estamos lejos de ser perfectos, pero tratamos de mantener un equilibrio justo entre calidad y costo (¡tiempo!)

@pjz también proporciona una buena respuesta, y menciona herramientas de revisión de código. Nunca he usado ninguno, así que no puedo decir nada al respecto ... aunque en el pasado he tenido la tentación de trabajar con Crucible ya que ya estamos usando JIRA .

Creo que el concepto principal que ayudará es el de un área de "Puesta en escena".

Sí, no desea verificar el código que está roto. Pero también debe verificar el código con frecuencia. ¿Esto implica perfección? ;) No. Simplemente use múltiples áreas y un DVCS como git.
De esta manera, realiza cambios (localmente) y los confirma con frecuencia a medida que realiza la prueba y se desarrolla hasta que pasan las pruebas. Luego empuja a un área de ensayo para la revisión del código.

Luego, debe pasar de la puesta en escena a otros esfuerzos de control de calidad, como las pruebas del navegador y las pruebas del usuario. Finalmente, puede ir a un área de prueba de volumen, luego finalmente producción.

También hay flujos de trabajo dentro de esto, como todos los que trabajan en la rama principal o usan ramas individuales para todos los esfuerzos.

La integración continua en sí misma también puede ocurrir en múltiples niveles. Puede ser local para una máquina de desarrolladores 'hasta que pasen las pruebas' y también puede estar en áreas de preparación y qa para cuando el código les llegue.

Desacoplar la revisión de código y la integración continua!

¿Por qué los combinaste?

Utilizamos git flow para nuestros repositorios, y hacemos nuestras revisiones de código cuando se trata de fusionarse en la rama de desarrollo.

Cualquier cosa en desarrollo es completa, implementable y revisada por código.

También tenemos CI establecida para nuestras sucursales de desarrollo y maestría.

Realmente, realmente, realmente creo que necesitarías un DVCS (por ejemplo, mercurial, git) para hacer esto de forma natural. Con un CVCS necesitarías una rama y esperar a cualquier dios que tengas, no hay un infierno que se fusione.

Si usa un DVCS, puede nivelar el proceso de integración para que el código ya lo revise antes de que llegue al servidor de CI. Si no tiene un DVCS, bueno, el código llegará a su servidor CI antes de ser revisado, a menos que los revisores de código revisen el código en la máquina de cada desarrollador antes de enviar sus cambios.

Una primera forma de hacerlo, especialmente si no tiene un software de administración de repositorios que pueda ayudar a publicar repositorios personales (por ejemplo, bitbucket, github, rhodecode), es tener roles de integración jerárquica. En los siguientes diagramas, puede hacer que los lugartenientes revisen el trabajo de los desarrolladores y que el dictador sea el integrador principal que revisa cómo los lugartenientes fusionaron el trabajo.

Otra forma de hacerlo si tiene un software de administración de repositorio, es usar un flujo de trabajo como el siguiente:

El software de administración de repositorios generalmente ayuda a emitir notificaciones cuando hay actividad en los repositorios (por ejemplo, correo electrónico, rss), así como también permite solicitudes de extracción . La revisión del código puede ocurrir orgánicamente durante las solicitudes de extracción, ya que las solicitudes de extracción suelen hacer que las personas participen en conversaciones para integrar el código. Tome esta solicitud de extracción pública como ejemplo. El administrador de integración en realidad no puede permitir que el código llegue al repositorio bendecido (también conocido como "repositorio central") si es necesario corregir el código.

Lo que es más importante, con un DVCS aún puede admitir un flujo de trabajo centralizado, no necesita tener otro flujo de trabajo sofisticado si no lo desea ... pero con un DVCS puede separar un repositorio de desarrollo central del CI servidor y darle a alguien la autoridad para enviar los cambios del repositorio de desarrollo al repositorio de CI una vez que se haya realizado una sesión de revisión de código .

PD: crédito para las imágenes ir a git-scm.com

¿Por qué no tener más de un repositorio? Uno para el trabajo "diario", conducir un servidor de integración continua, ejecutar todas las pruebas unitarias y las pruebas de integración para obtener un buen ciclo de retroalimentación, y otro para el trabajo "estable", donde los compromisos son menos frecuentes, pero tienen que pasar por una revisión.

Dependiendo de la ruta que tomen los cambios a medida que se mueven a través del sistema, esto puede terminar siendo una solución un poco compleja, y podría funcionar mejor cuando se usan herramientas como Git o Colas Mercuriales (advertencia: no he usado ninguna de ellas con ira) pero muchas organizaciones hacen algo similar.

¿Significa esto que debemos hacer revisiones de código cuando se completa una característica, pero ese código no revisado entrará en el repositorio?

Mucho más arriba es la forma en que lo he visto hacer en al menos tres proyectos que estaban utilizando intensivamente la integración continua y, según mi recuerdo, funcionó de maravilla. Esta práctica se conoce como revisiones de códigos posteriores a la confirmación : busque este término en la web si le interesan los detalles.

• ^{Por otro lado, el único caso en el que estuve en un proyecto tratando de "casarme" con revisiones de código de confirmación previa con CI resultó bastante doloroso. Bueno, cuando las cosas salieron al 100% sin problemas, estuvo bien, pero incluso las interrupciones poco frecuentes (como cuando los revisores principales y de respaldo no estuvieron disponibles por unas pocas horas) causaron un estrés notable. También noté que la moral del equipo sufrió un poco: hubo demasiados conflictos.}

Primero, debemos aclarar el concepto de "integración continua". En los métodos de desarrollo tradicionales, la integración continua significa que podemos integrar y construir nuestro repositorio de código fuente todos los días, lo que evitará las trampas del "infierno de integración". Las revisiones de código siempre se encuentran entre el período de codificación y las pruebas unitarias. Debemos garantizar que el código que se fusiona con la sucursal puede compilarse sin errores. Rara vez existe la situación de que partes de la característica se fusionen con la rama porque es difícil manejar la coherencia de la interfaz y los errores de compilación.

La integración continua es popular en el proceso de programación extrema. El desarrollo basado en pruebas agrega la programación de pares, que es parte real de un proceso de revisión de código, lo que hace que la integración continua sea fácil de implementar. La programación extrema en sí misma es un proceso continuo de revisión e integración de código. Las revisiones de código existen en todas partes.

En algunas comunidades de código abierto, las revisiones de código se ejecutan justo antes de que el código se fusione con la sucursal. Siempre es la gente más experimentada en este equipo para hacer las revisiones del código y decidir si el código puede fusionarse con la rama principal. De esta manera, el período de integración continua es un poco más largo, pero la calidad del código es un poco mejor.

Regrese a la pregunta. No hay una respuesta estándar para cuándo hacer revisiones de código, y depende de su proceso de desarrollo original y la implementación real de su integración continua.