¿Cuáles son las mejores prácticas y reglas generales a seguir mientras se mantiene el código? ¿Es una buena práctica tener solo el código listo para producción en la rama de desarrollo, o debería estar disponible el último código no probado en la rama de desarrollo?
¿Cómo mantienen ustedes su código de desarrollo y su código de producción?
Editar - Pregunta complementaria - ¿Su equipo de desarrollo sigue el protocolo "commit-tan-pronto-como-posible-y-a menudo-incluso-si-el-código-contiene-errores-menores-o-está-incompleto" o "commit- ¿ÚNICO protocolo de código perfecto mientras se confirma el código en la rama DESARROLLO?
Respuestas:
Actualización 2019:
En estos días, la pregunta se vería en un contexto usando Git, y 10 años de usar ese flujo de trabajo de desarrollo distribuido (colaborando principalmente a través de GitHub ) muestra las mejores prácticas generales:
masteres la rama lista para implementarse en producción en cualquier momento: la próxima versión, con un conjunto seleccionado de ramas de características fusionadasmaster.dev(o rama de integración, o 'next') es aquella en la que la rama de características seleccionada para la próxima versión se prueba en conjuntomaintenance(ohot-fix) es la rama de uno de los actuales arreglos evolución de liberación / errores, con posibles fusiones atrás adevy omasterEse tipo de flujo de trabajo (donde no se combinan
devamaster, pero donde se fusionan única rama función paradev, a continuación, si es seleccionado, paramaster, con el fin de ser capaz de soltar fácilmente presentará ramas no está listo para la próxima versión) se implementa en el Git repositorio en sí, con el flujo de trabajo (una palabra, ilustrada aquí ).Ver más en
rocketraman/gitworkflow. La historia de hacer esto vs Desarrollo basado en troncos se observa en los comentarios y discusiones de este artículo de Adam Dymitruk .(fuente: Gitworkflow: un manual orientado a tareas )
Nota: en ese flujo de trabajo distribuido, puede confirmar cuando lo desee y enviar a una rama personal algo de WIP (Work In Progress) sin problema: podrá reorganizar (git rebase) sus confirmaciones antes de hacerlas parte de una rama característica.
Respuesta original (octubre de 2008, hace más de 10 años)
Todo depende de la naturaleza secuencial de su gestión de lanzamiento
Primero, ¿está todo en su baúl realmente para el próximo lanzamiento ? Puede descubrir que algunas de las funciones desarrolladas actualmente son:
En este caso, el enlace troncal debe contener cualquier esfuerzo de desarrollo actual, pero una rama de lanzamiento definida antes de la próxima versión puede servir como rama de consolidación en la que solo se fusiona el código apropiado (validado para la próxima versión) y luego se fija durante la fase de homologación, y finalmente congelado a medida que entra en producción.
Cuando se trata de código de producción, también debe administrar sus ramas de parches , teniendo en cuenta que:
Cuando se trata de la rama de desarrollo, puede tener una troncal, a menos que tenga otros esfuerzos de desarrollo que necesite hacer en paralelo como:
Ahora, si su ciclo de desarrollo-lanzamiento es muy secuencial, puede seguir como sugieren las otras respuestas: un tronco y varias ramas de lanzamiento. Eso funciona para proyectos pequeños donde todo el desarrollo seguramente irá a la próxima versión, y solo puede congelarse y servir como punto de partida para la rama de lanzamiento, donde pueden tener lugar parches. Ese es el proceso nominal, pero en cuanto tienes un proyecto más complejo ... ya no es suficiente.
Para responder el comentario de Ville M.:
fuente
Usamos:
hasta que el proyecto esté cerca de su finalización, o si estamos creando una versión histórica (por ejemplo, demostración del producto, versión de presentación), luego (regularmente) ramificamos nuestra rama de desarrollo actual en:
No hay nuevas características en la rama de lanzamiento. Solo los errores importantes se corrigen en la rama de lanzamiento, y el código para corregir estos errores se reintegra en la rama de desarrollo.
El proceso de dos partes con un desarrollo y una rama estable (lanzamiento) nos hace la vida mucho más fácil, y no creo que podamos mejorar ninguna parte introduciendo más ramas. Cada rama también tiene su propio proceso de compilación, lo que significa que cada dos minutos se genera un nuevo proceso de compilación y, por lo tanto, después de un registro de código, tenemos un nuevo ejecutable de todas las versiones y ramificaciones de compilación en aproximadamente media hora.
De vez en cuando también tenemos sucursales para un único desarrollador que trabaja en una tecnología nueva y no probada, o que crea una prueba de concepto. Pero generalmente solo se hace si los cambios afectan muchas partes de la base de código. Esto ocurre en promedio cada 3-4 meses y dicha rama generalmente se reintegra (o desecha) dentro de uno o dos meses.
En general, no me gusta la idea de que cada desarrollador trabaje en su propia sucursal, porque "saltas y te mueves directamente al infierno de integración". Yo recomendaría encarecidamente que no lo haga. Si tiene una base de código común, todos deberían trabajar juntos en ella. Esto hace que los desarrolladores sean más cautelosos acerca de sus registros, y con experiencia cada codificador sabe qué cambios están potencialmente rompiendo la compilación y, por lo tanto, las pruebas son más rigurosas en tales casos.
En la pregunta temprana de check-in:
Si solo necesita que se registre el CÓDIGO PERFECTO , en realidad no se debe registrar nada. Ningún código es perfecto, y para que el QA lo verifique y pruebe, debe estar en la rama de desarrollo para que se pueda construir un nuevo ejecutable.
Para nosotros, eso significa que una vez que el desarrollador haya probado y completado una característica, esta se registrará. Incluso puede registrarse si hay errores conocidos (no fatales), pero en ese caso las personas que se verían afectadas por el error Generalmente informado. El código incompleto y de trabajo en progreso también se puede registrar, pero solo si no causa ningún efecto negativo obvio, como bloqueos o interrupción de la funcionalidad existente.
De vez en cuando, un código combinado inevitable y el registro de datos harán que el programa sea inutilizable hasta que se haya creado el nuevo código. Lo menos que hacemos es agregar un "ESPERE PARA CONSTRUIR" en el comentario de check-in y / o enviar un correo electrónico.
fuente
Por lo que vale, así es como lo hacemos.
La mayor parte del desarrollo se realiza en el tronco, aunque las características experimentales o las cosas que pueden romper el sistema tienden significativamente a tener su propia rama. Esto funciona bastante bien, ya que significa que cada desarrollador siempre tiene la última versión de todo en su copia de trabajo.
Significa que es importante mantener el tronco en un estado de funcionamiento vago, ya que es perfectamente posible romperlo por completo. En la práctica, eso no sucede a menudo y rara vez es un problema significativo.
Para una versión de producción, ramificamos troncales, dejamos de agregar nuevas funciones y trabajamos en la corrección de errores y en la prueba de la ramificación (fusionando regularmente en la troncal) hasta que esté lista para su lanzamiento. En ese momento, hacemos una fusión final en el tronco para asegurarnos de que todo esté allí, y luego lo liberamos.
El mantenimiento se puede realizar en la rama de lanzamiento según sea necesario, y esas correcciones se pueden combinar fácilmente en el tronco.
No afirmo que este sea un sistema perfecto (y todavía tiene algunos agujeros, no creo que nuestra gestión de lanzamientos sea un proceso lo suficientemente apretado todavía), pero funciona lo suficientemente bien.
fuente
¿Por qué nadie todavía menciona esto? Un exitoso modelo de ramificación Git .
¡Es para mí el último modelo de ramificación!
Si su proyecto es pequeño, no use todo el tiempo todas las ramas diferentes (quizás podría omitir ramas de características para características pequeñas). Pero de lo contrario, ¡es la forma de hacerlo!
fuente
Código de desarrollo en sucursales, código en vivo etiquetado en Trunk.
No es necesario que exista una regla de "comprometer solo el código perfecto"; todo lo que el desarrollador se pierda debe ser recogido en cuatro lugares: la revisión del código, la prueba de ramificación, la prueba de regresión, la prueba de control de calidad final.
Aquí hay una explicación más detallada paso a paso:
fuente
dev va en tronco (estilo svn) y los lanzamientos (código de producción) obtienen sus propias ramas
Es el "modelo de ramificación por propósito" (figura 3 en La importancia de los modelos de ramificación /! \ Pdf)
fuente
Resolvemos este problema separando completamente el código de producción (el tronco principal) del código de desarrollo (donde cada desarrollador tiene su propia rama).
No se permite ningún código en el código de producción antes de que se haya verificado a fondo (por QA y revisores de código).
De esta manera no hay confusión sobre qué código funciona, siempre es la rama principal.
fuente
Ah, sí, otra cosa: guardamos el código que no es de producción (es decir, el que NUNCA se lanzará, por ejemplo, scripts de herramientas, utilidades de prueba) en cvs HEAD. Por lo general, debe estar claramente marcado para que nadie lo libere "accidentalmente".
fuente
Desarrollamos en tronco que luego se ramifica cada dos semanas y se pone en producción. Solo los errores críticos se corrigen en la rama, el resto puede esperar otras dos semanas.
Para troncal, la única regla es que un commit no debe romper nada. Para administrar el código wip y el código no probado, solo agregamos declaraciones if apropiadas para facilitar el encendido y apagado.
Básicamente, sería posible ramificar el tronco en cualquier momento y ponerlo en producción.
fuente
Uso git y tengo 2 ramas: master y maint
cuando lanzo el código a producción, lo etiqueto y fusiono master para mantener rama rama de . Siempre despliegue desde la rama de mantenimiento . Parches de la rama de desarrollo Los selecciono para mantener la rama e implementar parches.
fuente
Tenemos una rama de "lanzamiento" que contiene lo que está actualmente en producción o se implementará en breve (ya pasó la mayoría de QA)
Cada proyecto, o en algunos casos otra unidad, tiene su propia rama que se ramifica desde su lanzamiento.
Los desarrolladores del proyecto comprometen los cambios en la propia sucursal de su proyecto. Periódicamente, la versión se fusiona nuevamente en una rama de desarrollo.
Una vez que todos los paquetes de trabajo en la rama son QA'd (prueba de unidad, prueba del sistema, revisión de código, revisión de QA, etc.), la rama se fusiona con la rama de lanzamiento. Las nuevas compilaciones se crean desde la rama de lanzamiento, y la validación final ocurre en esa versión.
El proceso es básicamente correcto hasta que se descubre un problema después de haber realizado una fusión. Si un WP se "atasca" después de haber sido fusionado, lo retiene todo hasta que se arregle (no podemos hacer otra versión hasta que se libere la bloqueada).
También es algo flexible: un cambio muy trivial podría ocurrir directamente en la rama de lanzamiento si se lanzara en una escala de tiempo muy corta (como 1-2 días más o menos).
Si un cambio se aplica directamente a producción por algún motivo (un problema de producción crítico que afecta al cliente y que requiere un cambio de código inmediato para solucionarlo), esos cambios se volverían a colocar en BRANCH_RELEASE. Eso casi nunca sucede.
fuente
Depende del proyecto. Nuestro código web se registra de manera bastante consistente, mientras que nuestro código de aplicación solo se registra si se compila. Me di cuenta de que esto es bastante similar a cómo lanzamos las cosas. Las cosas web suben siempre que pueden mientras las aplicaciones alcanzan una fecha límite difícil. Sin embargo, no he visto una pérdida de calidad en ninguno de los métodos.
fuente