Código publicado accidentalmente para vivir. ¿Cómo evitar que ocurra nuevamente?

Question

Tuvimos un incidente recientemente donde se lanzó un código para vivir que no estaba programado para su lanzamiento.

Obviamente se había registrado en el maletero. Lo cual está bien, supongo que como quiera 'check in early, check in a menudo'.

Sin embargo, en este caso no se suponía que se lanzaría en la próxima versión.

Qué tipo de controles/estrategia/proceso se pueden implementar para evitar que el código se publique prematuramente.

Me parece que incluso con la integración continua y las pruebas unitarias esto es un problema de procedimiento humano?

- Lee

Answer 1

Modifique sus procedimientos de integración.

Si "entrar en funcionamiento" significa que alguien está ejecutando un script por lotes, no se sorprenda si esto volverá a suceder.

Además, considere la posibilidad de ramificar. Un ejemplo común podría ser utilizar el tronco para el desarrollo, una rama separada para probar (digamos, se fusiona una vez por semana) y una rama final (de la rama de prueba mencionada anteriormente) para RTC.

Esta rama, antes de implementarse en la producción, debe probarse exhaustivamente.

Answer 2

El problema, obviamente, no es con la comprobación del código al repositorio. Tiene dos problemas aquí:

1) Cualquier código que se suponga que se active debe tener una etiqueta o rama de versión especial o lo que sea, dependiendo del control de fuente que use. Entonces, el código en vivo nunca se confunde con el código en desarrollo.

2) ¿Quién es el imbécil que pone código no probado en vivo de todos modos? Existe una grave falta de comunicación si la persona que la publicó cree que su código de desarrollo está listo para la producción.

Answer 3

Debe tener diferentes ramas si el software de control de origen lo permite.

En este caso, tendrá una persona responsable de fusionar el código que ya se encontró con la barra de calidad de la rama principal en la rama de producción.

---

ACTUALIZACIÓN: Aunque producto específico, la guía disponible en TFS 2008 Branching Guide 2.0 tiene un montón de guías que se pueden aplicar a otros programas de control de origen que tiene la capacidad de crear ramas.

Answer 4

No compilar para la producción desde el troncal - fusionar manualmente el código de troncal probado en una rama de producción e ir a vivir desde allí. O como dicen las otras respuestas, use cualquier cantidad de ramas y pasos en el procedimiento de prueba que se ajuste a sus necesidades.

Además, los cambios de código que toman más de un día más o menos generalmente se deben realizar en una rama de características separada hasta que finalice.

Answer 5

¿Qué tipo de cheques/estrategia/ proceso se puede poner en su lugar para evitar que se publique código vivir prematuramente.

Yo diría que cualquier proceso que no tenga registro en el maletero como un ritual de desarrollo habitual, lo que significa cualquier modelo de desarrollo a excepción de la codificación de vaquero.

Deje que los desarrolladores se registren temprano y con frecuencia en sus ramas de características y las combine en el tronco cuando llegue el momento.

Answer 6

Para continuar con la discusión de la bifurcación, es el camino a seguir para mantener estructurado el manejo de la versión.

Usamos el tronco como la rama principal, y cuando alcanzamos un cierto punto en el ciclo de desarrollo donde no se nos permite cometer más características (solo correcciones de errores), ramificamos una nueva rama para esa versión (en lugar de pasando por una fusión propensa a errores), y esa rama está bien probada antes de que construyamos la versión de la misma. Por supuesto, para que esto funcione, todos los programadores deben mantener las confirmaciones limpias cuando se acerca la fecha de congelación de las características.

Answer 7

Creamos un administrador de versiones que funciona con subversión. www.ReleaseManager.com Para que podamos controlar lo que se libera por número de problema (o número de error) y tenemos el control para que podamos sacar las cosas de la versión cuando sea necesario. Buscando sitios beta ahora :)

Answer 8

Me parece incluso con continua Integración y Unidad Tests Esta es una cuestión humana procedimiento ?

Indeed! Sin embargo, debería poder obtener algún apoyo de su infraestructura para respaldar el lado humano de su proceso. Cuando va a hacer un lanzamiento, debería ser capaz de ver fácilmente todos los compromisos que serían parte de él y todos los problemas relacionados. Este es el lado informativo de la integración continua. (Diría que hay four elements (pdf): creación, implementación, prueba y generación de informes.)