¿Cómo se mantiene el código de desarrollo y el código de producción?

Question

¿Cuáles son las mejores prácticas y reglas básicas para seguir mientras se mantiene el código? ¿Es una buena práctica tener solo el código de producción listo en la rama de desarrollo, o debería estar disponible el último código no probado en la rama de desarrollo?

¿Cómo mantienen el código de desarrollo y el código de producción?

Editar - Pregunta complementaria - ¿Su equipo de desarrollo sigue el protocolo "commit-as-soon-as-possible-and-often-even-if-the-code-contains-minor-bugs-or-is-incomplete" o el protocolo "commit-ONLY-perfect-code" mientras se confirma el código en la rama DEVELOPMENT?

Answer 1

Todo depende de la naturaleza secuencial de la gestión de la liberación

En primer lugar, es todo en el maletero realmente para la próxima versión? Usted puede encontrar que algunas de las funciones que actualmente desarrolladas son:

• demasiado complicado y todavía tienen que ser refinado
• no está listo en el tiempo
• interesante, pero no para esta próxima versión

En este caso, la troncal debe contener todos los esfuerzos de desarrollo actuales, pero una rama de liberación definida antes de la próxima versión puede servir como rama de consolidación en el que solo se fusiona el código apropiado (validado para la próxima versión), luego se fija durante la fase de homologación, y finalmente se congela a medida que entra en producción.

Cuando se trata de código de producción, también es necesario para administrar sus ramas de parche, mientras que teniendo en cuenta que:

• el primer conjunto de parches en realidad podría comenzar antes de la primera liberación en la producción (es decir, usted sabe que entrará en producción con algunos errores que no puede solucionar a tiempo, pero puede iniciar el trabajo para esos errores en una rama separada)
• las otras ramas de parche tendrán el lujo de comenzar desde una etiqueta de producción bien definida

Cuando se trata de dev rama, usted puede tener uno tronco, a menos que tenga otros esfuerzos de desarrollo que tenga que hacer en paralelo como:

• refactorización masiva
• las pruebas de una nueva biblioteca técnico que podría cambiar la forma en que llama cosas en otras clases
• comienzo de un nuevo ciclo de publicación donde se deben incorporar cambios arquitectónicos importantes.

Ahora, si su ciclo de lanzamiento y desarrollo es muy secuencial, puede ir como lo sugieren las otras respuestas: un tronco y varias ramas de liberación. Eso funciona para pequeños proyectos en los que seguro se incluirá todo el desarrollo en la próxima versión, y se puede congelar y servir como punto de partida para la rama de lanzamiento, donde se pueden realizar parches. Ese es el proceso nominal, pero tan pronto como tenga un proyecto más complejo ... ya no es suficiente.

---

Para contestar el comentario de M. Ville:

• tener en cuenta que dev DOE rama no significa 'una rama por desarrollador' (que daría lugar a 'combinar la locura', en el que cada desarrollador tendrían que fusionar el trabajo de otros para ver/obtener su trabajo), pero una rama dev por cada esfuerzo de desarrollo.
• Cuando esos esfuerzos deben ser fusionado de nuevo al tronco (o cualquier otro "principal" o liberación rama que defina), este es el trabajo de los desarrolladores, no - repito, NO - el Administrador de Carolina del Sur (que haría no sabe cómo resolver una combinación conflictiva). El líder del proyecto puede supervisar la fusión, es decir, asegurarse de que comienza/finaliza a tiempo.
• quienquiera que elija para hacer realidad la fusión, el más importante es:
  • que tienen pruebas de unidad y/o entorno de ensamblaje en el que se puede desplegar/probar el resultado de la fusión.
  • de haber definido una etiqueta antes el comienzo de la fusión con el fin de ser capaz de volver al estado anterior si dicha fusión se ha revelado demasiado compleja o más bien larga para resolver.

Answer 2

dev va en el tronco (estilo SVN) y libera (código de producción) obtener sus propias ramas

Es el "Poder-según el modelo objetivo" (figura 3 en The importance of branching models /! \ Pdf)

Answer 3

I usar Git y tengo 2 ramas: maestros y maint

• amo - código de desarrollo
• maint - produ código cción

cuando suelto código para la producción, lo que etiquetar y fusionar maestro a maint rama. Siempre despliego desde maint rama. Los parches de la rama de desarrollo los selecciono para maint branch e implementan parches.

Answer 4

Resolvemos este problema separando por completo 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 minuciosamente (por el control de calidad y los revisores de código).

De esta manera no hay confusión sobre qué código funciona, siempre es la rama principal.

Answer 5

Por lo que vale la pena, esto es cómo lo hacemos.

La mayor parte del desarrollo se realiza en tronco, aunque las características experimentales o cosas que pueden romper el sistema tienden 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.

Lo que significa es que es importante mantener el tronco con el fin vagamente de trabajo, ya que es perfectamente posible para romper por completo. En la práctica, eso no sucede a menudo, y rara vez es un problema importante.

Para una versión de producción, ramificamos el tronco, dejamos de agregar nuevas características y trabajamos en la corrección de errores y pruebas de la rama (fusionando regularmente en el tronco) hasta que esté lista para su lanzamiento. En ese punto hacemos una fusión final en el tronco para asegurarnos de que todo esté allí y luego lo liberamos.

Mantenimiento continuación, se puede realizar en la rama de lanzamiento según sea necesario, y esas correcciones pueden ser fácilmente incluido de nuevo en el tronco.

No pretendo que esto sea un sistema perfecto (y que todavía tiene algunos agujeros - No creo que nuestra gestión de la liberación es un proceso lo suficientemente apretado aún), pero funciona bastante bien.

Answer 6

Tenemos una "liberación" rama que contiene lo que está actualmente en producción o se implementará en breve (ya ha pasado la mayor parte de QA)

Cada proyecto, o en algunos casos otra unidad, tiene su propia rama que está ramificado desde lanzamiento.

Los cambios se confirmen, por los desarrolladores en el proyecto, en la propia rama de su proyecto. Periódicamente, la versión se fusiona nuevamente en una rama de desarrollo.

Una vez que los paquetes de trabajo en la rama son todos QA'd (unidad de prueba, prueba del sistema, revisión de código, revisión de control de calidad, etc.), la rama se combina en la rama de lanzamiento. Las nuevas compilaciones se crean a partir de la rama de publicación y la validación final se realiza en esa versión.

El proceso está básicamente bien hasta que se descubre un problema después de que se ha realizado una fusión. Si un WP se "atasca" después de que se ha fusionado, lo mantiene todo después hasta que se solucione (no podemos hacer otro lanzamiento hasta que se libere el bloqueado).

---

También es algo flexible - un cambio muy trivial podría ocurrir directamente en la rama de lanzamiento si estaba siendo liberado en una escala de tiempo muy corto (como 1-2 días o menos).

Si un cambio se produjo directamente en la producción por alguna razón (un problema de producción crítico que afecta al cliente y que requería un cambio de código inmediato para solucionarlo), esos cambios se volverían a poner en BRANCH_RELEASE. Eso casi nunca sucede.

Answer 7

Oh, sí - una otra cosa - que mantener el código no sea de producción (es decir, aquello que nunca se dará a conocer - por ejemplo, las secuencias de comandos de la herramienta, poniendo a prueba los servicios públicos) en la cabeza de cvs. Por lo general, debe estar claramente marcado para que nadie lo "accidentalmente" lo libere.

Answer 8

Utilizamos:

• rama de desarrollo exclusivamente

hasta que el proyecto llega a su fin, o estamos creando una versión hito (por ejemplo.demostración del producto, la versión de presentación), entonces (regularmente) se ramifican nuestra rama de desarrollo actual en el:

• rama de lanzamiento

No hay nuevas características van a la rama de lanzamiento. Solo se corrigen errores importantes en la rama de publicación, y el código para corregir estos errores se reintegra en la rama de desarrollo.

El proceso de dos partes con una rama de desarrollo y estable (versión) hace la vida mucho más fácil para nosotros, y no creo que podamos mejorar ninguna parte mediante la introducción de más ramas. Cada rama también tiene su propio proceso de compilación, lo que significa que cada par de minutos se genera un nuevo proceso de compilación y, por lo tanto, después de la verificación del código, tenemos un nuevo ejecutable de todas las versiones y ramas en aproximadamente media hora.

Occassionally también tenemos sucursales para un solo desarrollador que trabaja en una tecnología nueva y no probada, o que crea una prueba de concepto. Pero, en general, solo se hace si los cambios afectan a 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 un mes o dos.

En general, no me gusta la idea de que cada desarrollador trabaje en su propia sucursal, porque "salta y ve directamente al infierno de la integración". Recomiendo encarecidamente que no lo haga. Si tiene una base de código común, todos deberían trabajar juntos. Esto hace que los desarrolladores sean más cautelosos con sus registros, y con la experiencia de cada programador sabe qué cambios pueden romper la compilación y, por lo tanto, las pruebas son más rigurosas en tales casos.

En el registro de entrada en cuestión principios:

Si necesita solamente código perfecto que deben controlarse para, a continuación, en realidad nada debe ser evaluada en ningún código es perfecto, y para el control de calidad para verificar y probar. debe estar en la rama de desarrollo para que se pueda construir un nuevo ejecutable.

Para nosotros eso significa que una vez que una característica es completa y probada por el desarrollador se comprueba en. Incluso puede comprobarse en si hay errores conocidos (no mortales), pero en ese caso las personas que se verían afectados por el error generalmente son informados. El código incompleto y de trabajo en progreso también se puede verificar, 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 & data checkin hará inutilizable el programa hasta que se haya creado el nuevo código. Lo mínimo que tenemos que hacer es agregar un "ESPERA PARA CONSTRUIR" en el comentario del check-in y/o enviar un correo electrónico.

Answer 9

Código de desarrollo en sucursales, código Live etiquetado en Troncal.

No es necesario que haya una regla de "comprometer solo el código perfecto": todo lo que el desarrollador omita debe ser recogido en cuatro lugares: revisión del código, prueba de ramificación, prueba de regresión, prueba de QA final.

He aquí una explicación más detallada paso a paso:

1. hacer todo el desarrollo en una rama, cometiendo regularmente a medida que avanza.
2. Código independiente Revisión de los cambios una vez que se completa todo el desarrollo.
3. Luego pase la rama a Pruebas.
4. Una vez completada la prueba de bifurcación, combine el código en la rama Candidato de liberación.
5. Release La rama candidata se prueba de regresión después de cada combinación individual.
6. Pruebas finales de QA y UA realizadas en RC después de todas las ramas de desarrollo fusionadas.
7. Una vez que se superan los pasos QA y UAT, fusione la rama de liberación en la rama MAIN/TRUNK.
8. Finalmente, marque el Troncal en ese punto e implemente esa etiqueta en Live.

Answer 10

Desarrollamos en el tronco que luego se ramifica cada dos semanas y se pone en producción. Solo los errores críticos se arreglan en la sucursal, el resto puede esperar otras dos semanas.

Para el tronco la única regla es que un compromiso no debe romper nada. Para administrar el código wip y el código no probado, solo agregamos las declaraciones apropiadas para facilitar el encendido y apagado.

Básicamente, sería posible ramificar el tronco en cualquier momento y ponerlo en producción.

Answer 11

Depende del proyecto. Nuestro código web se verifica de manera bastante uniforme, 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 cosas. Las cosas en la Web aumentan cada vez que pueden, mientras que las aplicaciones tocan una fecha límite difícil. Sin embargo, no he visto una pérdida de calidad en ninguno de los métodos.

Answer 12

¿Por qué nadie aún menciona esto? A successful Git branching model.

¡Es para mí el mejor modelo de ramificación!

Si su proyecto es pequeño, no use todo el tiempo todas las ramas diferentes (tal vez podría omitir las ramas de características para las características pequeñas). ¡Pero de lo contrario, es la manera de hacerlo!