Patrones para integración continua y DVCS

Actualmente usamos Subversion y TeamCity, vamos a pasar a usar Mercurial (específicamente Kiln, ya que somos usuarios de FogBugz).

Obviamente, esto dará como resultado cambios, ojalá mejoras, en nuestros patrones de desarrollo (¡los dos!), Pero el único problema con el que estoy luchando es cómo estructurar las cosas para que aún disfrutemos de los beneficios de la integración continua / nuestro servidor CI ( que hay y seguirá habiendo beneficios es un hecho, cuya discusión está fuera del alcance de esta pregunta).

Con SVN nos comprometemos con un número limitado de repositorios centrales, efectivamente uno por proyecto (más o menos una solución de Visual Studio), por lo que es fácil activar una compilación y obtener la seguridad de que todos los archivos se han comprometido y que no hay dependencias perdidas, etc., etc. Pero si vamos a aprovechar adecuadamente el mercurial, vamos a querer tener más instancias de repositorio, donde esperaría que los cambios generalmente fluyan hacia un repositorio definitivo "en vivo". El problema con el que estoy luchando es que el repositorio en vivo me parece demasiado "tarde" para activar mis compilaciones de CI OTOH Una compilación de CI por proyecto por desarrollador es probablemente excesiva (y causa otros problemas).

Estoy pescando un poco, pero eso es porque una de las cosas que un repositorio de subversión central le da a uno (¡yo, con nuestra configuración!) Es mucha claridad sobre qué construir cuando.

Nota: no estoy preguntando acerca de la mecánica del uso de mercurial con integración continua: tengo que trabajar como un regalo para un proyecto personal, sus patrones y estructuras y la práctica de trabajo / flujo de trabajo que estoy tratando de entender.

Primero, tener múltiples compilaciones por proyecto en TeamCity es realmente el camino a seguir. La naturaleza de la plataforma lo hace realmente fácil: el botón copiar está ahí por una razón.

En cualquier caso, cuando estábamos en SVN, normalmente ejecutamos 2 compilaciones para cada proyecto: una apuntaba a la línea de desarrollo principal (en nuestro caso, el tronco) y otra apuntaba a nuestra rama de lanzamiento. Llevamos esta configuración de compilación a HG mientras seguimos un modelo de ramificación similar a este . El único desafío real ha sido encontrar un nuevo funk schwea sobre los números de compilación ahora que ya no podríamos usar el número de revisión SVN actual.

Tratamos de alentar a las personas a presionar con relativa frecuencia, especialmente cuando hay mucho trabajo al mismo tiempo y queremos ciclos de retroalimentación más rápidos. El hecho de que sea un DCVS no significa que solo tenga que presionar una vez al día o algo así.

Hemos estado usando Kiln durante aproximadamente un año y hemos probado varias cosas diferentes. Donde terminamos es usar ramas con nombre (en lugar de clones de ramas) con la siguiente estrategia de ramificación:

• pistas predeterminadas de desarrollo "completado"
• las ramas de características rastrean el trabajo que está actualmente en progreso
• liberar sucursales puntos de seguimiento donde liberamos de forma predeterminada

Entonces, el trabajo comienza creando una rama de características desde la punta actual predeterminada . Cuando se realiza la ramificación de la función *, la ramificación se cierra y se fusiona con la predeterminada .

En algún momento, decidimos que estamos listos para lanzar, por lo que creamos una nueva rama de lanzamiento desde la punta actual en forma predeterminada . Esto nos permite realizar cambios en el código que se encuentra actualmente en producción al comprometernos con la rama de lanzamiento y al mismo tiempo permitir el desarrollo activo en las ramas de características y las predeterminadas .

En cuanto a la integración continua, hacemos dos cosas:

• Una integración "siempre activa" que supervisa el estado predeterminado
• Nuevas integraciones para cada rama de lanzamiento

El trabajo de bifurcación predeterminado nos permite saber que nuestro árbol de origen principal siempre es estable: los trabajos de bifurcación de lanzamiento nos permiten saber que esas bifurcaciones son estables y nos proporcionan el resultado de compilación que necesitamos para impulsar una liberación a producción.

_{* Nuestra definición de "hecho" es que la función está actualizada con fusiones por defecto y ha sido aprobada en la revisión del código.}

Si se muda a un DVCS, como Hg, no solo obtiene la "parte distribuida", sino que también obtiene toda la potencia de una buena ramificación y fusión.

Teniendo en cuenta que ahora tendrá un buen rastreador de problemas y un buen SCM ... ¿por qué no crear una rama para cada tarea?

El patrón de "ramificación por tarea" no es nuevo (consulte el libro de Berczuk) pero definitivamente es algo para probar.

Lo expliqué en detalle aquí , y los pros y los contras de CI frente a "controlado" aquí .