Las liberaciones con múltiples ramas de larga vida utilizando Maven

Question

Así que aquí está la subversión, Jenkins, configuración Beanstalk:

• tronco/-> desarrollo de la línea principal
  • CI se basa en el check-in
  • correcta construcción CI genera CD generación que empuja al medio ambiente habichuelas mágicas "Prueba"
/
• ramas/qa -> versión actual candidato
  • CI se basa en el check-in
  • correcta construcción CI desova acumulación de CD que empuja a "control de calidad" entorno Beanstalk
• ramas/prod/-> versión actual
  • CI se basa en el check-in
  • éxito CI construir desova acumulación de CD que empuja al medio ambiente "Prod" Beanstalk

Básicamente lo que quiero hacer es lo siguiente:

• ciclo de desarrollo comienza en el tronco (tronco: 0.1-SNAPSHOT)
• Cuando ciclo de desarrollo es la rama completa a qa y siendo q un ciclo. También comience el próximo ciclo de desarrollo en el enlace troncal (troncal 0.2-SNAPSHOT, qa: 0.1-SNAPSHOT)
• Cuando el ciclo qa está completo, bifurque para producir y ejecutar la liberación. También comenzará el próximo ciclo de control de calidad (tronco 0,2-INSTANTÁNEA, qa: 0.2-SNAPSHOT, prod: 0,1)

La idea es tener carreras cortas, donde al final de cada cylce un desarrollo termina y comienza un ciclo de control de calidad. Cuando el ciclo qa está completo, se envía a un entorno de producción.

Me gustaría conservar las ramas y fusionarlas a \ desde las ramas en lugar de eliminarlas y volver a crearlas. La idea es que cualquier corrección hecha en qa se fusionaría de nuevo en el tronco de entrada, y cualquier cambio realizado en prod se fusionaría de nuevo en qa (y de nuevo en el tronco).

prod es por lo tanto una rama "caliente" y representa el estado actual del entorno de producción.

esto es para un pequeño equipo de desarrolladores que trabajan en sprints semanales.

Preguntas:

1. ¿Cómo funciona este sonido configuración?
2. ¿Puedo hacer que maven actúe correctamente, o tendré que guiar esto?
3. ¿Quién es tu papá? Y que hace el?

Answer 1

No recomendaría una rama qa y prod. Lea sobre las mejores prácticas de subversión. Recomendaría The SVN Book, en particular el capítulo 4 sobre ramificación/fusión.

Debe versionar todas las versiones, incluso si se trata de control de calidad (mediante etiquetas). Trunk se utiliza para el trabajo de desarrollo actual, las etiquetas son para versiones publicadas (definidas como "característica completa", no en qué entorno se encuentra), y las ramas son para corregir defectos (entre otras cosas).

Escenario de ejemplo:

Versión 1.0 está en producción, su equipo acaba de lanzar 2.0 de control de calidad para las pruebas, y ahora están trabajando en una versión 3.0. En este punto se tendría:

• /tronco (desarrolladores trabajando en 3.0)
• /tags/2.0 (utilizado para QA)
• /tags/1.0 (histórica por lo que está en producción)

Si su equipo de control de calidad encuentra un problema en 2.0, creará una bifurcación de la etiqueta 2.0. Haga su corrección, fusione al tronco y luego suelte la rama como 2.0.1 (otra etiqueta). A continuación, se quedará con:.

• /tronco (desarrolladores que trabajan en 3.0, 2.0 + la corrección de defectos)
• /branches/2.0.* (utilizar el carácter * para indicar que es donde todos los 2.0 * se comprometerán correcciones. puede volver a utilizar esta misma rama, si aún otro defecto se encuentra en el código 2.0)
• /tags/2.0 (QA etiqueta original estaba probando con el defecto)
• /tags/2.0.1 (2,0 base de código, con SOLO la corrección de defecto)
• /tags/1.0 (histórico para lo que está en producción)

Answer 2

He hecho un trabajo similar antes de la bifurcación y liberación, y en mi experiencia, la configuración que ha descrito ha terminado siendo muy difícil de manejar y burocrática en poco tiempo.

La respuesta de Domenic D. es bastante similar al tipo de configuración que preferiría, particularmente con un pequeño número de desarrolladores. Cuantas más sucursales tenga, más compleja será la administración del código base y más es probable que introduzca errores a través de malas prácticas de fusión.

Una cosa que no menciona es importante, en mi opinión, para empezar desde el principio es su política de check-in. El SCM no es una copia de seguridad para el trabajo incompleto, debe esforzarse para asegurarse de que las líneas principales estén por lo menos construyendo. Sea estricto al respecto, al final hará la vida de todos más fácil.

Sin embargo, lo más importante es que, independientemente de los procedimientos de publicación que se presenten, asegúrese de obtener la aceptación de su equipo y de que no tienen que ser "forzados" a su lugar. Esa es una señal de que puede haber algo mal con lo que se te ocurrió que no está bien y que probablemente será rápidamente ignorado o subvertido.