¿Cuál es la política / proceso de revisión de código interno de Google?

En primer lugar, ninguna de las cosas que describo es propietaria porque Guido ya reveló la mayoría de las partes internas de la revisión del código de Google con gran detalle en sus presentaciones públicas de video / diapositivas (ver enlace a continuación). Habiendo dicho eso …
Google ahora usa Critique, que es una reescritura completa de Mondrian arriba. Solo puedo hablar sobre el viejo Mondrian. En los viejos tiempos, todas las presentaciones de revisión se realizan a través de g4, que es un contenedor alrededor de p4 Perforce (que ya no se usa). Sus diferencias se centran en listas de cambios (grupos de CL). Todas las revisiones de CL se realizan en una interfaz de usuario llamada Mondrian, y todo debe revisarse antes de registrarse en mainline / head. El código debe ser aprobado diciendo “LGTM” por alguien que tenga legibilidad en un idioma en particular (una insignia de honor que dice que ahora está escribiendo un código que se ajusta a la guía de estilo de Google súper estricta – Guías de estilo para proyectos de código abierto originados en Google – Proyecto de alojamiento de Google). Esto significa que cada pequeño espacio, puntuación, alineación, debe seguir estas reglas. También debe ser aprobado por alguien en el archivo PROPIETARIOS que exista en el directorio. Si ha demostrado ser Googly, puede agregarlo al archivo OWNERS. Por lo general, con el tiempo, se lo agregará a los PROPIETARIOS ya que las personas van y vienen todo el tiempo.

Mondrian (escrito por el famoso Guido, ahora reescrito como Critique) es la interfaz de usuario donde los revisores pasan la mayor parte del tiempo. Una buena interfaz de usuario de revisión ayuda a que la revisión de Google fluya de manera eficiente, que era la intención de Mondrian. Los no usuarios de Google pueden echar un vistazo a cómo era Mondrian en 2006 a partir de este video obsoleto de Guido: http://www.youtube.com/watch?v=s… .

Para los que no son de Google, hay algunas opciones disponibles para usar. He intentado esto después de dejar Google, y obviamente hay muchas más opciones, pero estas son las más similares a Mondrian por experiencia personal:

1) Google Code Review (código llamado Rietveld, una bifurcación de Mondrian) alojado en GAE.
Usarlo es muy fácil: en el panel de administración de GAE, habilite Google Code Review (a través de laboratorios) y comience a cargar los diferenciales de código usando upload.py, que funciona con su Git, Perforce, Subversion, Mercurial y CVS. http://code.google.com/appengine …
Tenga en cuenta que hay algunos problemas con Rietveld:
a) LGTM no se aplica
b) el registro de código (línea de comando) y el problema de cierre (formulario web) se realiza manualmente, por separado
c) aún puede omitir la Revisión del Código de Google yendo directamente a git, subversion, etc.
d) no hay un enlace previo / posterior al compromiso

Tengo un contenedor para GCR que resuelve los problemas anteriores, e imita más de cerca a g4 + Mondrian aquí: CR (un contenedor para Google Code Review).

2) http://Reviewable.io . Este es un sistema alojado de “luz de revisión de código”.
Piotr es un X-Googler que trabaja en este proyecto. Creo que tiene la mejor interfaz de usuario de todos los sistemas de revisión de código que he visto hasta la fecha. Se integra fácilmente con Github. Lo que hace mejor que Google Code Review es que las diferencias se generan automáticamente cuando se envía a Github. Lo considero un sistema “ligero” porque tampoco aplica LGTM y el estado de compilación / prueba, por lo que los desarrolladores pueden omitir las comprobaciones y posiblemente enviar código roto a Github en cualquier momento. Para las personas que desean un sistema de revisión de código ligero y dedican una cantidad mínima de tiempo a la configuración (solo unos segundos y unos pocos clics), http://Reviewable.io es el camino a seguir.

Ahora, si tiene un poco más de tiempo para ser un administrador de revisión de código, algunas de las opciones a continuación ofrecerán más funcionalidad (por ejemplo, la aplicación de LGTM, el enlace CI previo al envío, etc.):

3) Phabricator (Phabricator).
Aunque no es un tenedor de Mondrian, esto es muy similar en espíritu a Mondrian. Algunas ventajas:
a) es extremadamente fácil de configurar (en comparación con Gerrit, que requiere mucho más tiempo para configurar)
b) funciona sobre los repositorios existentes, como Github, por lo que es un cambio menos dramático para los desarrolladores existentes (por otro lado, Gerrit requiere que el repositorio esté alojado en el propio repositorio privado de gerrit de Gerrit, lo que requiere que todos hagan cambios más drásticos. En seguida)
c) aún puede agregar prueba unitaria y linting (en el lado del cliente) como un enlace previo al compromiso.
d) puede agregar reglas de vigilancia (heraldo), muy similares al archivo OWNERS de Google, pero aún mejor porque es mucho más flexible
e) la desventaja es que la integración a Jenkins es un poco primitiva en este momento, pero se está desarrollando en este momento y epriestley (Evan Priestley) es extremadamente receptiva en tickets y correos electrónicos. Me impresionó lo rápido que me ayudó a resolver algunos problemas.

4) Gerrit ( http://code.google.com/p/gerrit/ …).
Similar a GCR, también es una bifurcación de Mondrian. Lo he usado en mi empresa anterior. Si está ejecutando una corporación más grande y quiere alojar su propio sistema de control de versiones, este es el camino a seguir. Es el más rico en funciones, pero también toma mucho más tiempo configurarlo que todas las otras opciones. Gerrit es ideal para una corporación más grande porque:
a) es muy potente y le permite configurar reglas extremadamente finas, que incluyen:
b) prueba de unidad previa al compromiso
c) requerir aprobaciones estrictas, o no, por repositorio
d) muy buena integración con Jenkins
e) la vista / IU es extremadamente compacta, por lo que puede incluir una gran cantidad de contenido en una página. Esto es importante cuando intentas revisar el código en una pequeña computadora portátil.
f) cualesquiera que sean las reglas que Google tiene ahora, puede configurarlas con Gerrit (en el lado del servidor), ya que es muy poderoso.

En resumen, he usado varios sistemas de revisión que han tenido cierta influencia de Google: 0) Mondrian, propietario, antiguo 1) Google Code Review tardó minutos en configurarse en GAE, pero no es muy poderoso. 2) http://Reviewable.io es el camino a seguir si usa Github y necesita un sistema de revisión de inmediato 3) Phabricator es el siguiente más fácil de configurar y lo suficientemente potente. Por último, 4) Gerrit es el más poderoso, pero como dije, requiere un tiempo considerable para configurar reglas muy finas (y para enseñar a los desarrolladores cómo usarlo).