Para la versión basada en ramas, debemos hablar del siguiente diagrama, que ilustra perfectamente el panorama del proceso de gestión de configuración. En primer lugar, este diagrama está escrito a partir del modelo Git, pero en realidad, Git y Subversion han descifrado el concepto de gestión de control de versiones, aunque Git sí da un salto cualitativo respecto a Subversion en gestión de sucursales y rendimiento distribuido (aunque este no es el foco de este artículo).
Antes de introducir el principio de este grafo, hablemos de dos estrategias diferentes para el control general de versiones: una es "backbone pionero, rama estable" y la otra es "backbone estable, rama pionera". Como su nombre indica, es la versión estable (versión de producción), en el tronco o en la rama. En el caso de los equipos de proyecto tradicionales que usan VSS, es difícil decir a qué modo pertenece, principalmente porque el propio VSS no tiene una estrategia de gestión de sucursal, por lo que muchos equipos de proyecto establecen bibliotecas de dos versiones (o tres) respectivamente, correspondientes al entorno de producción y al entorno de desarrollo; por supuesto, esto también es una especie de gestión de sucursal disfrazada. Sin embargo, si cambias a Subversion o Git como herramienta de control de versiones, la mayoría de los equipos usan el modo trunk estable, es decir, el trunk (truck o master) corresponde a un entorno de producción estable y etiqueta diferentes versiones para indicar la versión de producción. Personalmente, creo que el patrón de código backbone estable debería ser la solución de control de versiones de código más común en la actualidad. La imagen anterior es el modelo estándar de gestión de "backbone estable".
maestro: La subversión correspondiente es camión。 Correspondiente a la versión de producción, se etiqueta una vez en cada lanzamiento.
Rama de liberación (también conocida como rama de integración): Mientras la producción se actualice, primero debe integrarse en la rama de lanzamiento (rama de integración). Es algo similar a lo que el equipo del proyecto llama actualmente el concepto de "preproducción" y "entorno simulado".
Desarrollar rama (rama de desarrollo o rama de desarrollo): El entorno al que se enfrenta el entorno de desarrollo.
Rama de características (rama de características): Algunas funciones independientes pueden separarse de una rama de desarrollo separada. Esto es principalmente para lidiar con el hecho de que algunas funciones pueden tardar bastante en actualizarse, para no arrastrar la versión y las ramas separadas.
Rama de correcciones rápidas (rama de corrección de errores): El error aquí es principalmente un error de producción.
Después de introducir el tronco y las ramas, necesito explicar la dirección de la generación y fusión de estas ramas.
Master es la versión de producción, y el tronco solo acepta dos ramas para fusionar, una es la de lanzamiento (rama de integración) y la otra es la rama de correcciones rápidas. Ninguna otra rama puede fusionarse en una rama de producción.
La rama de lanzamiento se crea inicialmente al mismo tiempo que la producción, que es exactamente igual que la producción. Solo acepta que la rama de desarrollo se fusione con ella. En otras palabras, no acepta fusionar directamente desde la rama de características o la rama de corrección de errores.
La rama de desarrollo, la rama de desarrollo, al igual que la rama de integración, es igual que el entorno de producción en un momento determinado. Sin embargo, a medida que avance el desarrollo, seguirán creándose nuevas funciones en la rama de desarrollo. La teoría de desarrollo solo acepta la fusión de dos ramas, una son correcciones rápidas y la otra es la rama de características.
Feature branch, comenzando en un punto determinado (versión) con la rama de desarrollo, la rama de feature eventualmente se fusionará con la de desarrollo.
Vamos a presentar brevemente el método de control de versiones en forma de escenario
Supongamos que una versión de producción se divide en ramas (dev, hotfixes, release), y en ese momento dev empieza a desarrollar un total de diez funciones. Cuando se desarrollaron 8 de las 10 funcionalidades, el equipo de pruebas comenzó a intervenir para pruebas internas, y el administrador de configuración desplegó la rama de desarrollo en el entorno de desarrollo para pruebas mediante herramientas de integración continua (un tema aparte aquí). Cuando la verificación de prueba encontró que dos de las funciones eran completamente inaceptables y necesitaban ser rehechas, como el seguro simple y la devolución de reclamaciones, dos ramas de características se separaron del desarrollo, correspondientes al seguro simple y al reembolso de reclamaciones, y en la rama de desarrollo también fue necesario revertir el código correspondiente (operación manual aquí). Cuando el equipo de pruebas detecta que no hay problema con la prueba de la rama de desarrollo, esta cumple las condiciones de UAT, por lo que el administrador de configuración fusiona la rama de desarrollo con la de lanzamiento y luego utiliza herramientas de integración continua para publicar esta rama en el entorno de preproducción y entregarla al usuario para su prueba. Cuando la verificación de usuario detecta un problema, el desarrollador modifica la rama de desarrollo y luego la fusiona con la rama de lanzamiento (aquí, en la imagen original, se modifica directamente en la rama de lanzamiento, creo que esto no es bueno, recomiendo que el desarrollador solo se enfrente a la rama de desarrollo), cuando el proceso de verificación de la versión detecta de repente que hay un error grave en el entorno de compilación que debe corregirse inmediatamente, entonces se modifica urgentemente en la rama de correcciones rápidas y se lanza urgentemente tras verificar que es correcto. Al mismo tiempo, la rama de hotfixes se fusiona con dev (aquí es mayormente manual, porque en este momento la versión de producción ya es muy diferente de la de dev, y a menudo es imposible completar la fusión automática), y luego dev se fusiona con la versión. Tras un periodo de tiempo, la función de devolución de reclamaciones puede dejar de ser necesaria y debe cancelarse, por lo que la rama de devolución de reclamación se eliminará. Otra función es fácil de asegurar y se ha desarrollado y fusionado de nuevo con la rama de desarrollo para lanzar la siguiente versión online.
El escenario anterior incluye básicamente el desarrollo rutinario, el desempaquetado, las actualizaciones de emergencia y otros escenarios en el proceso diario de desarrollo.
|
Publicado en 8/4/2018 10:25:39
|
|
|
|
