Trabajo para una empresa de desarrollo de productos. Primero hacemos lanzamientos internos, y luego lanzamientos públicos. Me preguntaba cómo otras empresas de desarrollo de productos gestionan su lanzamiento. ¿Cómo se da el número de lanzamiento? Etiquetar el control de origen?Release Management: mejor práctica
Utilizamos SubVersion, donde las etiquetas y las ramas son baratas de crear.
En cuanto a los comunicados van, seguimos esta convención:
(versión principal) (Versión secundaria) (Patch Release) (SVN revisión)
¿Tiene sentido? Si necesita más información, agregue un comentario y editaré mi publicación para aclararla.
En mi empresa, cuando un lanzamiento está listo, creamos una rama para los números de versión 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 crea una rama R_2_1_1 para marcar esa versión. Por lo que el árbol se ve así:
Mainline
|
|- R_2_1
| |
| |-R_2_1_0 (locked)
| |
| |
| |-R_2_1_1 (locked)
| |
. .
. .
. .
trabajé para un proveedor de software a medida que con el tiempo se transformó en un proveedor de soluciones cuando los clientes decidieron que no querían poner en práctica sus propias Callcenters 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 cojos. 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!
Utilizamos 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 de origen 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 fusionaron de nuevo en el tronco cuando se completa. Las principales versiones se pueden hacer desde el tronco.
Una respuesta basada en el marco ITIL (que es más o menos igual a las otras).
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:
• Mayor versiones de software y actualizaciones de hardware, normalmente contiene grandes áreas de nuevas funcionalidades, algunas de las cuales pueden hacer intervenir soluciones para los problemas 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 pueden haber sido emitidas como arreglos de emergencia. Una actualización menor o versión generalmente reemplaza todas las soluciones de emergencia anteriores.
• software de Emergencia y hardware fija, normalmente contiene las correcciones a un pequeño número de problemas conocidos
Así, después de esto debe tener:
Mayor: V1, V2, V3, etc
Menor: v1 .1, V2.1, etc.
Emergencia: v1.1.1, V2.1.1, etc.
Su pregunta es sobre el tema en [ITIL Stackexchange] (http://area51.stackexchange.com/proposals/89073/itil?referrer=x5X3k7r_NAmvg4ZTdjTOlw2) – SQLMason
Como han dicho otros, la mejor manera de gestionar 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, hotfixes) 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.
I created a similar question, pero quería agregar algo más: Recomiendo utilizar algo como Jira para administrar un ciclo de lanzamiento. Puede asociar commits con requests/issues/bugs, y luego marcarlos como parte de un lanzamiento.
En particular, Si desea saber cómo gestionar un buen ciclo de publicación, eche un vistazo a cómo lo hace la fundación Apache, porque lo tienen bajo la ciencia. Por ejemplo, aquí está el roadmap for releases in the Mahout project.
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 CruiseControl y Hudson) y pruebas unitarias para que su ciclo de construcción administrado junto con todo lo demás.
Seguimiento de la respuesta del co-gato con respecto a TFS. Hay una nueva dirección URL con algunas versiones de VS2010 y VS11
No estoy seguro de que yo llamaría ramas subversión y etiquetas baratas para crear ... al menos, no después de haber utilizado Git de todos modos. –
Lo que dijo Bob: estamos a punto de cambiar * de * Subversion * a * Git, en parte porque la ramificación y el etiquetado son mucho menos costosos en Git que en SVN. http://www.whygitisbetterthanx.com/ es una buena comparación de varios VCS, aunque con una obvia preferencia por Git. –