¿Cuándo es apropiado comenzar a usar la próxima revisión de una herramienta cuando se alimenta de perros?

Específicamente, estoy trabajando en una herramienta que integra un DVCS y un sistema de compilación, pero imagino que el desafío al que me enfrento surgiría para cualquiera que desarrolle una herramienta "meta" (compilador, VCS, sistema de compilación, corredor de prueba, etc.) que deseo desarrollar a través de "dogfooding" .

Mi pregunta es: en un proceso de lanzamiento de estilo scrum que usa el flujo de trabajo de ramificación , ¿en qué punto empiezo a usar una versión más nueva de la herramienta en el ciclo de desarrollo de la herramienta?

Estoy buscando un proceso para crear un equilibrio entre:

• uso constantemente la developversión de la herramienta: encuentro que estoy rompiendo mi propio desarrollo a medida que se incorporan cambios.

• use constantemente la masterversión de la herramienta: cualquier problema que descubra a través de dogfooding es un problema que ya se ha publicado.

Lo primero que debe hacer es tener pruebas de regresión fuera de línea automatizadas muy completas. Haga que pasar esas pruebas sea un requisito mínimo para lo que usa oficialmente.

En segundo lugar, necesita una forma muy simple de recurrir a la versión de trabajo anterior, para los problemas que sus pruebas automatizadas no detectan.

Por ejemplo, mi kernel de Linux fue parcheado por un tiempo. Parchearía y compilaría mi kernel en la misma computadora en la que pretendía usarlo, lo que significaba que podría perder mi entorno de desarrollo si creaba un kernel defectuoso. Así que me aseguré de mantener siempre un buen núcleo conocido en mi menú de GRUB, así que si me equivocaba, volvía a un buen entorno de desarrollo con un simple reinicio.

Coordinar eso con un equipo es complicado, pero supongo que es principalmente una cuestión de permitir que cualquiera inicie una reserva y comunique las razones. En el control de versiones, una forma de designar eso sería con algo como una last_known_goodrama, en algún lugar entre developy masteren su flujo de trabajo. Nada se empuja allí hasta que hayas forzado con éxito una construcción.

Si esta herramienta se usa para producir software de calidad de producción (especialmente si se usa de forma recursiva, es decir, para desarrollarse), aumentaría sus esfuerzos de prueba por adelantado y esperaría a la alimentación de perros hasta que el lanzamiento sea lo suficientemente estable como para que esté bastante seguro de que no estará rompiendo el código de producción al usarlo.

Si tiene que esperar a que la versión maestra tenga ese nivel de confianza, que así sea.

Git también es una herramienta de este tipo y, obviamente, también hace comida para perros. Pero lo hace en diferente medida en diferentes entornos. Los servidores públicos solo están ejecutando la versión, mientras que los desarrolladores generalmente trabajan con next(ese es el nombre del proyecto git para "desarrollar") o pu(incluso más desarrollar que desarrollar). Cualquier desarrollador que está bloqueada por algún problema puede volver a nexto mastero la última versión siempre que estén bloqueadas por algo y el repositorio principal no se ve afectada, por lo que los problemas se pueden limpiar con referencia a la misma.

El modelo de ramificación es similar al anterior con nombres ligeramente diferentes. masteres de lo que se hacen los lanzamientos grandes, maintes la rama de lanzamiento para el próximo lanzamiento del punto, nextes similar al desarrollo con una ligera diferencia de que las características se pueden fusionar para dominar por separado después de estar en el siguiente ya en lugar de fusionar todo el próximo.

Hay una rama adicional, pu. Esto se crea al fusionar todas las ramas de características que se consideran para la integración next(la rama se descarta y se recrea cada vez). IIRC solo se publica si pasa el conjunto de pruebas. La última vez que miré, Junio, el mantenedor, estaba ejecutando los scripts para construirlo regularmente a mano, pero dichos scripts podrían ejecutarse mediante una integración continua todas las noches y creo que Gerrit incluso lo crea automáticamente.

Entonces ese tipo de es la respuesta. Usted es la versión más desarrollada que tiene en entornos de desarrollo, pero utiliza versiones anteriores para versiones de construcción.

Según la respuesta aceptada , voy a ampliar el flujo de trabajo de ramificación para mantener ramas similares a las siguientes:

• master: se fusiona con el release-*cierre
• dogfood: ramas de master; incluye correcciones identificadas durante la alimentación del perro; se fusiona developcuando el software se considera "estable" para uso interno; la cabeza de esta rama puede retroceder en el tiempo si es necesario
• develop: ramas de master; incluye cambios continuos, correcciones de errores y fusiones de dogfoody feature-*ramas
• feature-*: ramas de develop; incluye cambios para una nueva característica particular
• release-*: se ramifica desde dogfoodcuando el software se considera "estable" para uso externo; incluye actualizaciones de documentación y correcciones de errores menores antes de fusionarse conmaster