release-management - que - release management traduccion
Gestión de lanzamientos: mejores prácticas (8)
Trabajo para una compañía de desarrollo de productos. Primero hacemos lanzamientos internos, y luego lanzamientos públicos. Me preguntaba cómo otras compañías de desarrollo de productos gestionan su lanzamiento. ¿Cómo se da el número de lanzamiento? Etiquetar el control de origen?
Trabajé para un proveedor de software personalizado que eventualmente se transformó en un proveedor de soluciones cuando los clientes decidieron que no querían implementar sus propios centros de llamadas y sitios web.
En ese entorno, cada cliente importante tuvo la oportunidad de personalizar algunos aspectos de cómo funcionaba el sistema. Así que el desarrollo tenía un producto principal con componentes comunes a todos los contratos, y sucursales separadas para cada cliente (algunos clientes necesitaban pequeños ajustes, otros una mayor integración con otros sistemas).
Funcionó bien, hasta que el negocio creció y el número de sucursales se expandió, a menudo para acomodar cambios realmente poco convincentes. En un momento creo que tenían algo así como 15 versiones activas diferentes de la misma base de código ... lo que hacía que las cosas fueran realmente inflexibles y difíciles de soportar.
No hagas lo que hicimos: ¡haz que tus lanzamientos escalen!
En mi compañía, cuando un lanzamiento está listo, creamos una rama para los números de lanzamiento mayor / menor, llamada algo así como R_2_1 . La versión inicial se realiza creando una rama de instantánea o etiqueta inmediatamente después, llamada R_2_1_0 . Cuando QA archiva errores en una versión, los cambios de código se realizan en la rama R_X_Y y luego se R_2_1_1 una rama R_2_1_1 para marcar esa versión. Entonces el árbol se ve así:
Mainline
|
|- R_2_1
| |
| |-R_2_1_0 (locked)
| |
| |
| |-R_2_1_1 (locked)
| |
. .
. .
. .
Usamos SVN y creamos dos ramas para cada lanzamiento. Una es una etiqueta del código fuente utilizado para compilar esta versión, y otra es una nueva importación de los archivos binarios publicados. Esto es importante porque (no importa cuánto intente hacer lo mismo con las máquinas de dos desarrolladores, o intente mantener una máquina de compilación estable), inevitablemente, cuando intente regenerar la construcción X 6 meses después, encontrará que algo ha cambiado y el binario resultante es sutilmente diferente.
Los parches menores se crean en las ramas copiadas de la rama fuente de la versión y se fusionan en la línea troncal. Una versión menor se puede hacer fácilmente copiando la rama fuente de la versión a una nueva rama y fusionando los parches que sean necesarios.
El trabajo principal se lleva a cabo en las ramas copiadas del tronco, y se fusionan de nuevo en el tronco cuando se completa. Las principales versiones se pueden hacer desde el tronco.
Como otros dijeron, la mejor forma de lidiar con la administración de las publicaciones es mediante la bifurcación. Recomiendo echar un vistazo a la TFS Branching Guide ( http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785 ) que explica varios enfoques para crear la estructura de la sucursal dependiendo del tamaño de sus proyectos y diferentes formas de proporcionar su software a los usuarios finales (versiones principales, service packs, hotfix). La mayoría no es específica de TFS, por lo que puede aplicarla a la mayoría de los demás sistemas de control de origen.
Seguimiento de la respuesta del co-gato con respecto a TFS. Hay una nueva URL con algunas actualizaciones para VS2010 y VS11
Usamos SubVersion, donde las etiquetas y las ramas son baratas de crear.
En cuanto a los lanzamientos, seguimos esta convención:
(Versión principal). (Versión menor). (Versión de parche). (Revisión SVN)
- Parche de lanzamiento = correcciones de errores
- Menor lanzamiento = compatible binario / interfaz compatible
- Versión principal = incluye cambios de última hora.
¿Tiene sentido? Si necesita más información, agregue un comentario y editaré mi publicación para aclararla.
Una respuesta basada en el marco ITIL (que es más o menos igual a los demás).
ITIL clasifica las versiones en 3 grupos: lanzamiento de software importante, lanzamiento de software menor y correcciones de software de emergencia.
De los libros de ITIL:
• Principales versiones de software y actualizaciones de hardware, que normalmente contienen grandes áreas de nuevas funcionalidades, algunas de las cuales pueden hacer que las soluciones intermedias a Problemas sean redundantes. Una actualización importante o liberación normalmente reemplaza todas las actualizaciones menores anteriores, lanzamientos y arreglos de emergencia.
• Versiones de software menores y actualizaciones de hardware, que normalmente contienen pequeñas mejoras y correcciones, algunas de las cuales ya se han publicado como arreglos de emergencia. Una actualización menor o versión generalmente reemplaza todas las soluciones de emergencia anteriores.
• Soluciones de software y hardware de emergencia, que normalmente contienen las correcciones a un pequeño número de problemas conocidos
Entonces, siguiendo esto deberías tener:
Mayor: v1, V2, v3, etc.
Menor: v1.1, V2.1, etc.
Emergencia: v1.1.1, V2.1.1, etc.
Creé una pregunta similar , pero quería agregar algo a esto: recomiendo utilizar algo como Jira para administrar un ciclo de publicación. Puede asociar commits con requests / issues / bugs, y luego marcarlos como parte de un lanzamiento.
En particular, si quiere saber cómo gestionar un buen ciclo de publicación, eche un vistazo a cómo lo hace la fundación Apache, ya que lo consideran una ciencia . Por ejemplo, esta es la hoja de ruta para los lanzamientos en el proyecto Mahout .
Junto con un sistema que rastrea problemas y los agrupa en un paquete de lanzamiento, querrá comenzar a integrar esto con su integración continua (he usado tanto CruiseControl como Hudson) y pruebas unitarias para que su ciclo de construcción se administre junto con todo más.