svn - tipos - ventajas de usar un sistema de control de versiones

Describa su flujo de trabajo de usar control de versiones(VCS o DVCS) (2)

Me gustaría aprender el flujo de trabajo de otras personas cuando utilizo vcs o dvcs.

Por favor describa su estrategia para manejar las siguientes tareas:

Implementar una característica
Corrección de errores (durante el desarrollo y la aplicación implementada)
Revisión de código
Código de refactorización (revisión de código postal)
Incorporar parches
Lanzando la versión más nueva de su aplicación (escritorio, web, móvil, ¿los trataría de manera diferente?)

Siéntase libre de organizar su respuesta no agrupada por las tareas, sino agrupada por lo que considere relevante, pero organícela mediante VCS / DVCS (no las mezcle).

Gracias.

La característica principal que todo VCS usa para las diversas tareas que menciona es la branching : la capacidad de aislar un esfuerzo de desarrollo de forma colaborativa. Dado que es un VCS central, varios desarrolladores pueden colaborar en una misma rama, con bloqueos pesimistas u optimistas en los archivos, para desarrollar una historia paralela.

Pero ser un VCS tiene dos efectos principales en la ramificación:

Tiende a desalentar las confirmaciones, porque una vez que se compromete un archivo, influirá inmediatamente en el espacio de trabajo de otras vistas con la misma configuración (es decir, "trabajando en la misma rama").
~ El proceso de "publicación" es uno activo, con consecuencias inmediatas,
~ mientras que la parte "consumidora" (actualización de su área de trabajo) es pasiva (se ve obligado a ocuparse de los cambios publicados por otros inmediatamente después de la actualización de su área de trabajo)
Funciona bien para el flujo de trabajo de combinación lineal (es decir, "solo se fusiona de la rama A a la rama B, no mezcla las fusiones en ambas direcciones" - A a B a A a B ...). Las fusiones son triviales, todas las modificaciones de A simplemente se transfieren a B

Ahora:

Implementando una característica

Cualquier VCS hará eso haciendo una rama, pero lo que me sorprendió mucho es que una rama "característica" no es fácil:
* la característica puede volverse demasiado complicada
* puede estar listo a tiempo para la próxima versión
* solo es posible que deba combinarse una parte de la misma en la rama de desarrollo principal
* puede depender de otras características que aún no se han completado

Por lo tanto, debe tener cuidado en la forma en que administra su rama de características y sus compromisos: si están estrechamente relacionados con la misma función, funcionará bien (fusionará todo de nuevo en su rama de desarrollo principal cuando lo necesite). . De lo contrario, las fusiones parciales no son fáciles con esas herramientas.

Corregir errores

La diferencia entre la corrección de errores durante el desarrollo y después del lanzamiento es que, en el primer caso, a menudo puede hacerlo de forma lineal en la misma rama, ya que en este último caso deberá establecer una rama de corrección de errores y decidir qué errores tendrá. necesidad de back-port a su rama de desarrollo actual.

Revisión de código

Se utiliza mejor con herramientas externas ( como Crucible, por ejemplo) y utiliza funciones de VCS como censuras o anotaciones extensamente, para asignar mejor las correcciones de código después de una revisión.

Código de refactorización (revisión de código postal)

Si la refactorización es menor, puede continuar en la misma rama. Pero si es grande, se debe configurar una rama especial, con pruebas unitarias antes de comenzar dicha refactorización.

Incorporar parches

Mismo comentario que el último punto. Si el parche es grande, se necesita crear una rama.

Liberando la versión más nueva de tu aplicación

Un VCS solo lo llevará tan lejos a la hora de lanzar su aplicación, porque no es una herramienta de gestión de versiones.
Necesitará identificar previamente una versión para ser lanzada (etiqueta), pero luego viene el proceso de implementación que involucra:

detener lo que se está ejecutando actualmente
copiando los nuevos archivos
desplegándolos (actualizando la base de datos sql, webapp, ...)
crear instancias de todos los archivos de configuración (con los valores correctos, direcciones, número de puerto, rutas, ...)
reinicio (y si su sistema está compuesto por varios componentes, ¡reinícielos en el orden correcto!)

Las cosas clave con VCS y administración de lanzamientos son:

no están muy bien adaptados para almacenar binarios que se lanzarán, lo que significa que los necesita para construir su aplicación, no para almacenar el ejecutable resultante
no siempre son bienvenidos en el entorno de producción (donde las restricciones de seguridad limitan el acceso a la escritura, así como la cantidad de herramientas que se ejecutan en esas plataformas, esencialmente herramientas de supervisión y generación de informes)

El mecanismo de liberación también influye en las dependencias binarias:

para dependencias binarias externas, probablemente use mecanismos como maven para obtener revisiones fijas de bibliotecas externas
pero para las dependencias internas, cuando no está desarrollando solo una aplicación, sino varias que dependen una de otra, necesita saber cómo hacer referencia a los binarios producidos por las otras aplicaciones (dependencias binarias internas), y generalmente no se almacenarán. en su VCS (especialmente en la fase de desarrollo, donde puede producir muchos lanzamientos diferentes para que otras aplicaciones puedan usar)

También puede elegir estar en dependencias de origen (y obtener todas las fuentes de los otros proyectos internos que necesita para su propio), y un VCS está bien adaptado para eso, pero no siempre es posible / práctico recompilar todo.

La principal diferencia con un DVCS (Distributed Version Control) de un VCS, es que está hecho (por la propia naturaleza de su trabajo distribuido) para hacer una cosa, y una cosa bien:

fusionar

Entonces, las tareas que menciona pueden verse desde ese ángulo.
Se seguirán realizando sucursales, pero no todos serán visibles por otros desarrolladores. Muchos de ellos no saldrán de tu repositorio local .

Ser un DVCS tiene dos efectos principales en la fusión:

te comprometes tantas veces como quieras. Esos compromisos no son inmediatamente visibles para otros (es decir, "no tendrán que fusionarlos inmediatamente después de la próxima actualización de su área de trabajo").
~ el proceso de publicación es pasivo: los repositorios pueden ignorar sus impulsos.
~ la parte "consumidora" es activa: puede examinar qué se le ha enviado antes de fusionarla con su sucursal y decidir qué desea fusionar y de quién (y no solo porque todos están trabajando en un "mismo rama").
funciona bien para cualquier flujo de trabajo de fusión (parcial, entrecruzado, recursivo, ...) El DAG (Gráfico Acíclico Direccionado ) usado a menudo para registrar el historial por aquellos DVCS (al menos Git y Mercurial) hace que sea más fácil encontrar lo que tiene ya se ha fusionado y encuentra el ancestro común. Esa es una diferencia importante entre SVN y sus equivalentes DVCS , pero también hay otros .

Ahora:

Implementar una característica

Como detallo en mi respuesta de CVCS (Central VCS) , la dificultad detrás de una rama de "característica" es que muchas subcaracterísticas terminan entrelazadas.
Aquí es donde brillará DVCS, ya que le permitirán reorganizar su historial local (como en "no empujado todavía") (conjuntos de cambios para Mercurial, SHA1 commits ofr Git), para facilitar fusiones parciales, o creaciones de sucursales secundarias.

Corregir errores

Casi puede crear una rama por arreglo de errores si lo desea. La idea es asegurarnos de que se identifique una solución de errores mediante un conjunto lineal simple de commmits fusionados en la rama de desarrollo (o la rama de mantenimiento si se libera).
Prefiero asegurarme de volver a establecer la base de la rama de reparación de errores en la parte superior de la rama de desarrollo (para asegurarme de que mis correcciones siguen siendo compatibles con cualquier trabajo que se haya realizado en paralelo en dicha rama principal), antes de fusionar esa rama de desarrollo con la solución de errores uno (fusión de avance rápido: la rama principal ahora hace referencia a todas las correcciones)

Revisión de código

La función de anotación o culpa aún está allí para ayudar a asignar las tareas durante una revisión del código, pero esta vez, todos los desarrolladores no están necesariamente en un sitio (ya que es un * Distributed * VCS), y no con el mismo esquema de identificación ( no usar el mismo LDAP por ejemplo).

Una forma de DVCS para organizar la revisión del código es enviar nuevos cambios a un repositorio de revisión de código especial, que:

rechazar aquellos compromisos si no responden a los criterios de calidad requeridos
aceptarlos (combinarlos con el repositorio de revisión de código) e insertarlos en un repositorio nuevo (utilizado para varias pruebas, por ejemplo)

Código de refactorización (revisión de código postal)

Se realizan en el repositorio local del desarrollador, en una sucursal (ya que es tan fácil fusionarlo de nuevo)

Incorporar parches

El mismo proceso que la última sección.

Lanzando la versión más nueva de su aplicación (escritorio, web, móvil, ¿los trataría de manera diferente?)

El proceso de lanzamiento real simplemente se inicia mediante una versión especial identificada (etiqueta) de su software. (El resto del "proceso de gestión de versiones", que es la parte de implementación y configuración, se detalla en la respuesta de CVCS )
La pregunta es, con un DVCS:
"¿De qué repositorio vendrá esa versión oficial de su software?"

Necesita establecer un repositorio "central" o más bien "oficial" que desempeñará el papel de:

Repo para las versiones que se lanzarán
Repo para nuevos repositorios quería contribuir

Por lo tanto, puede servir tanto para fines de publicación como para nuevos fines de desarrollo.