Commit Early Commit a menudo con revisiones de código?

Question

Estoy buscando asesoramiento/experiencia/mejores prácticas sobre cómo conseguir que un equipo de desarrolladores participe en un compromiso de compromiso temprano a menudo trabaje el paradigma mientras se beneficia de un proceso de revisión de código completo. Actualmente usamos la placa de revisión y es política que no se confíe ningún código a SCM sin una revisión por pares. Si bien adopto por completo las revisiones de códigos, parece ralentizar el proceso en general y presenta un gran salto de velocidad a la idea de cometer compromiso temprano a menudo. Así que estoy pidiendo la experiencia de otros en lo que funciona y lo que no. ¿Te comprometes temprano y con frecuencia? ¿También usas revisiones de código? ¿Existe una forma obvia (que me falta) de que las dos ideas se puedan combinar?

Answer 1

Yo sugeriría tal vez cambiar a SCM distribuido. Podrías hacerlo para que cada miembro del equipo se comprometa con su propio repositorio. Cuando una característica está lista para su revisión, el revisor recibe una notificación. Si el revisor acepta los cambios, los empuja/los fusiona en el repositorio estable (que es bastante sencillo).

Git y Mercurial (hg) son buenos ejemplos de distribución

Answer 2

Primera de SMC de todo, lo que el software de control de versiones está usando?

Según su software RCS, puede lograr ambos objetivos al mismo tiempo. Por ejemplo, si está utilizando Subversion, cada desarrollador puede comprometerse temprano y con frecuencia a su propia rama de desarrollo privado. Se pueden requerir revisiones por pares antes de que las ramas de desarrollo se fusionen en el enlace troncal. Otros sistemas RCS pueden hacer algo similar.

Editar: me olvidó mencionar que si usted es de hecho utilizando un "cometió temprano y con frecuencia" estrategia con Subversion (con o sin ramas de desarrollo), los desarrolladores necesitan para asegurarse de que update su copia de trabajo con los cambios comprometido con el tronco igualmente a menudo. Este fue un problema que mi equipo tuvo durante un tiempo después de migrar de VSS a Subversion. No estábamos acostumbrados a poder realizar combinaciones de tres vías, y los desarrolladores actualizaban sus copias de trabajo con poca frecuencia (a veces menos de dos veces al día), lo que normalmente requeriría una gran cantidad de fusión manual. Eventualmente, todos se acostumbraron a ejecutar svn update cada vez que se realiza una confirmación (tenemos un enlace posterior a la confirmación que actualiza una fuente RSS con confirmaciones nuevas) o, como mínimo, cada hora más o menos. Como resultado, la mayor parte de la fusión se maneja automáticamente y la cantidad de trabajo manual requerido para fusionar los cambios de una rama de desarrollo en el tronco suele ser trivial. Esto también mantiene el diff entre el tronco y la rama de desarrollo lo más pequeño posible, lo que hace que la revisión del código sea más fácil (ya que normalmente nos centramos en el diff entre la rama y el tronco al revisar el código).

Answer 3

utilizar un sistema de control de versiones distribuido. Uno de los mayores inconvenientes del control de versiones centralizado es que dificulta el "compromiso temprano, comprometerse a menudo". Los sistemas distribuidos lo alientan.

Answer 4

Todas las respuestas existentes proponen distribuidos SMC. Esto es suficiente, pero no es necesario. Antes de la existencia de SCM distribuido, todavía era posible hacer esto.

Cada desarrollador debe trabajar en su propia sucursal (o puede preferir niveles más bajos de bifurcación de sucursales como por error o tarea (especialmente con programación de pares, o desarrolladores que trabajan en muchas tareas a la vez). Probablemente se le puede dejar al desarrollador, si tiene un equipo maduro en lugar de confiar en ellos.

Los desarrolladores deben comprometerse temprano y con frecuencia en su propia rama: es como un sistema de respaldo, que realiza copias de seguridad en puntos importantes y realiza un seguimiento de lo que estaba pensando cuando realizó el cambio.

Solo fusionar las ramas revisadas por código nuevamente en la rama principal.

Los sistemas SCM distribuidos tienen muchos beneficios, y no quiero sonar como si estuviera en contra de ellos, pero si no los usa, no hay excusa para no usar ramas por desarrollador.

Answer 5

Utilizar la bifurcación.

Ejemplo:

trabajo Devs en su propia rama en una rama de la característica. Revise los cambios cuando se combina con la rama de desarrollo de la línea principal. Fusionar en las ramas de desarrollo contra la rama de liberación cuando se realizan las versiones.

Answer 6

Usted debe echar un vistazo a este Google TechTalks por Linus Torvalds: http://www.youtube.com/watch?v=4XpnKHJAok8

Linus se explaigning qué distribuida SMC (como Git o Hg) bajar la barrera psicológica de cometer, por tanto, permitir que los desarrolladores a "comprometerse temprano, cometen a menudo "(usando branches, gracias a fusionándose siendo tan simple en git).

Luego, la revisión por pares la realizan otros desarrolladores que conectan su rama con la de ellos, verifican lo que quieran comprobar y ejecutan conjuntos de pruebas.

Finalmente, cuando todo el mundo esté contento, puede pasar a una sucursal "en vivo" o "pre-live" que debe ser mantenida por un equipo/persona preseleccionado.

Sólo decir algo así como "No soy yo, es Linus contarla!", Debería ayudar mucho :)

Answer 7

Utilizamos la estrategia descrita en Version Control for Multiple Agile Teams - funciona también para un solo equipo - y funciona muy bien para nosotros.

A continuación, un ejemplo para toda una iteración:

y una muy breve explicación:

• El tronco contiene HECHO historias hace, tiene una política liberable(puede ser lanzado en cualquier momento).
• El desarrollo se realiza en ramas de trabajo (una por equipo), tienen una política más flexible (unidad probada).
• cuando se HACE una historia, se empuja desde la rama de trabajo al tronco.
• Las fusiones de las ramas de trabajo a trabajo se realizan todos los días.

Incluimos "código revisado" en nuestra "Definición de Hecho" por lo que una historia no puede ser publicada desde una rama de trabajo al tronco si el código no ha sido revisado. Sin embargo, las personas PUEDEN comprometerse temprano y con frecuencia en la rama de trabajo de su equipo (siempre que el código sea probado en unidades).

He utilizado este enfoque en varios proyectos, de varios tamaños (proyecto pequeño con un solo equipo para un gran proyecto con varios equipos), con diferentes VCS incluyendo Subversion con éxito. Y recomiendo leer todo el documento.

Answer 8

No puedo comentar tan - la estrategia con diferentes niveles de ramas (respuesta de Pascal) es genial. Sin embargo, creo que una cosa que te gustaría aclarar es si "commit" equivale a "release". No debería. Lo que hemos estado haciendo con un solo equipo por proyecto es que los desarrolladores se comprometen cuando están listos, sin embargo el compromiso no debe romper el control de unidades (similar a la política "unidad probada" en el flujo de trabajo de la excelente respuesta de Pascal). Tenemos un servidor de prueba que se ejecuta directamente desde el repositorio y se actualiza después de cada confirmación (lo hacemos con aplicaciones web; esto equivale a tener una compilación de su software en cada compromiso o todos los días). Todos pueden acceder a ese servidor, incluidas las OP y las partes interesadas; de hecho, cualquiera que quiera puede jugar con él y proporcionar comentarios.

Ahora, las revisiones de código se asignan como trabajo explícito en la acumulación de sprints a cada elemento. Los elementos que no han sido revisados ​​por código no se consideran completados y no forman parte del incremento de envío que se lanza al final del sprint.

En este escenario, "confirmar" significa enviar su código al repositorio. Su código será visible para otros, también será visible trabajando en el servidor de prueba (si no se romperá algo). La barrera psicológica es mucho más baja que si comprometerse significara enviar algo que se considera liberable. Aún así, cada desarrollador sabe que su código no se lanzará realmente antes de una revisión del código y que deberán usar un sombrero de aspecto divertido por el resto del día si envían un compromiso que rompa las pruebas unitarias.

En cuanto a las revisiones de código, tomar tiempo - bueno, este es el tiempo bien empleado, el tiempo invertido hacia una mayor calidad del producto. Bien vale la pena.

Answer 9

Si está buscando una combinación, le sugiero que adopte una nueva política: el código producido en pares no requiere una revisión del código.

La programación de pares proporciona el mismo valor que una revisión de código, permite una excelente transferencia de conocimientos y ayuda a los programadores noveles (¡y en ocasiones a los programadores experimentados!) A aprender rápidamente. Por supuesto, trae sus propios desafíos ... ninguno de ellos insuperable.

Answer 10

El equipo en el que estoy ha adoptado una política similar de que no se comete ningún código sin una revisión, pero la forma en que lo abordamos es hacer una programación de pares casi exclusiva. Algunos podrían argumentar que eso no constituye una "revisión", pero sí garantiza que al menos dos desarrolladores revisaron el código, el diseño y la prueba. En el check-in, ambos revisores ingresan sus iniciales para la trazabilidad.

No estoy seguro si eso funcionará con su placa de revisión, pero es algo que quizás quiera considerar.