version-control - studio - programacion android pdf 2018

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

¿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 "commit-as-soon-possible-or-is-incomplete"? ¿Protocolo "SOLO-código perfecto" al tiempo que se asigna el código a la rama DESARROLLO?

¿Por qué nadie aún menciona esto? Un exitoso modelo de ramificación de Git .

¡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 ramas de características para funciones pequeñas). ¡Pero de lo contrario, es la manera de hacerlo!

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 "accidentalmente" lo libere.

Código de desarrollo en las 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: la revisión del código, las pruebas de ramificación, las pruebas de regresión, las pruebas finales de control de calidad.

Aquí hay una explicación más detallada paso a paso:

Haga todo el desarrollo en una sucursal, comprometiéndose regularmente a medida que avanza.
Revisión de código independiente de los cambios una vez que se completa todo el desarrollo.
Luego pasa la rama a Testing.
Una vez que se completen las pruebas de rama, combine el código en la rama Candidato de liberación.
La rama Candidato de lanzamiento se prueba de regresión después de cada fusión individual.
Pruebas finales de QA y UA realizadas en RC después de que todas las ramas dev se fusionaron.
Una vez que se aprueban QA y UAT, fusione la rama de liberación en la rama MAIN / TRUNK.
Finalmente, etiquete el Troncal en ese punto e implemente esa etiqueta en Live.

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.

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 trunk, la única regla es que una confirmación 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.

Por lo que vale, así es como lo hacemos.

La mayoría del desarrollo se realiza en tronco, aunque las características experimentales o cosas que pueden romper el sistema tienden a obtener 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 orden de trabajo vago, ya que es perfectamente posible romperlo 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 fallas y en probar la rama (fusionando regularmente de nuevo al 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.

El mantenimiento se puede realizar en la rama de liberación según sea necesario, y esas correcciones se pueden fusionar fácilmente de nuevo en el tronco.

No pretendo 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 cerrado), pero funciona bastante bien.

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 QA y revisores de código).

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

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 la versión.

Los desarrolladores se comprometen con los cambios en la rama propia del 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 (prueba de unidad, prueba de sistema, revisión de código, revisión de QA, etc.), la rama se fusiona en la rama de publicación. 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 haya 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 publicación si se lanzara en una escala de tiempo muy breve (como uno o dos días).

Si por alguna razón un cambio se realizó directamente en la producció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.

Todo depende de la naturaleza secuencial de su gestión de lanzamiento

Primero, ¿todo está en tu baúl para el próximo lanzamiento ? Puede descubrir que algunas de las funciones desarrolladas actualmente son:

demasiado complicado y aún necesita ser refinado
no está listo a tiempo
interesante pero no para este próximo lanzamiento

En este caso, el tronco debería contener cualquier esfuerzo de desarrollo actual, pero una rama de liberación definida antes del próximo lanzamiento puede servir como una rama de consolidación en la que solo el código apropiado (validado para el próximo lanzamiento) se fusiona y 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 necesita administrar sus ramas de parche , teniendo en cuenta que:

el primer conjunto de parches podría comenzar antes de la primera versión en producción (lo que significa que 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 la rama de desarrollo, puede tener un tronco, a menos que tenga otros esfuerzos de desarrollo que necesite realizar en paralelo, como:

refactorización masiva
prueba de una nueva biblioteca técnica que podría cambiar la forma en que llamas 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 de 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 responder el comentario de Ville M.

tenga en cuenta que la rama dev no significa ''una rama por desarrollador'' (lo que desencadenaría ''fusionar locura'', en la que cada desarrollador tendría que fusionar el trabajo de otros para ver / obtener su trabajo), pero una rama dev por desarrollo esfuerzo.
Cuando esos esfuerzos deben fusionarse de nuevo en el tronco (o en cualquier otra rama "principal" o de lanzamiento que defina), este es el trabajo del desarrollador, no - repito, NO - el administrador SC (que no sabría cómo resolverlo) cualquier combinación conflictiva). El líder del proyecto puede supervisar la fusión, es decir, asegurarse de que comienza / finaliza a tiempo.
quien sea que elijas para hacer la fusión, lo más importante es:
- tener pruebas unitarias y / o un entorno de ensamblaje en el que pueda implementar / probar el resultado de la fusión.
- haber definido una etiqueta antes del comienzo de la fusión para poder volver al estado anterior si dicha fusión resulta demasiado compleja o bastante larga para resolverse.

Usamos:

rama de desarrollo exclusivamente

hasta que el proyecto esté a punto de finalizar, o estamos creando una versión de hito (por ejemplo, demostración de producto, versión de presentación), entonces (con regularidad) ramificamos nuestra rama de desarrollo actual en:

rama de lanzamiento

No hay nuevas funciones en la rama de publicación. 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 al introducir más sucursales. 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.

Ocasionalmente 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, 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 la pregunta inicial de check-in:

Si solo necesita que se ingrese el CÓDIGO PERFECTO , en realidad no se debe registrar nada. Ningún código es perfecto, y para que el control de calidad lo verifique y lo pruebe, debe estar en la rama de desarrollo para poder crear un nuevo ejecutable.

Para nosotros, eso significa que una vez que el desarrollador completa y prueba una característica, se registra. Incluso se puede registrar si hay errores conocidos (no fatales), pero en ese caso las personas que se verían afectadas por el error son usualmente informado. 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, una combinación inevitable de código y datos combinados 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.

Yo uso git y tengo 2 ramas: master y maint

maestro - código de desarrollo
maint - código de producción

cuando lanzo el código a producción, lo etiqueto y fusiono master a maint branch. Siempre despliego desde la rama de maint . Los parches de la rama de desarrollo los selecciono para maint branch e implementan parches.

dev entra en trunk (estilo svn) y releases (código de producción) obtiene sus propias ramas

Es el "modelo de propósito de sucursal" (figura 3 en La importancia de los modelos de ramificación /! / Pdf)