testing - Mejores prácticas para la integración y el despliegue continuos

continuous-integration teamcity

Question

El concepto de integración continua se acaba de integrar en mi equipo.

Supongamos que tenemos una rama de integración llamada Dev .

De él derivaron 3 sucursales, una para cada proyecto actual específico:

• Proyecto a
• Proyecto b
• Proyecto c

Primero, Teamcity se configura en un servidor dedicado y sus objetivos son:

Compila y lanza pruebas de unidad e integración de fuentes versionadas de cada rama, incluyendo Dev

Luego, por supuesto, cada rama del proyecto (A, B y C) debe probarse en un entorno de producción clonado para que se pueda llevar a cabo la UAT.

Pero me pregunto en qué frecuencia deberíamos desplegarnos. Cada vez que un código fuente cambia?

¿Deberíamos desplegar solo Dev que contenga una combinación de los 3 proyectos después de fusionar cada uno de ellos (correspondiente a la realidad en el próximo lanzamiento de producción) o los 3 proyectos de forma independiente?

Si se implementa Dev, no se deben tener en cuenta los posibles cambios futuros en Dev. De hecho, podría haber un nuevo proyecto que se inicia llamado Proyecto D y no debe ser parte de la próxima versión. Por lo tanto, arriesgarse a tomar Dev para integración (UAT) es porque el implementador podría integrar de forma involuntaria el contenido del Proyecto D, por lo que el entorno no revelará la realidad de la próxima versión.

Otra solución: no estamos tomando Dev, sino los 3 proyectos de forma independiente, así que ¿deben haber 3 entornos de producción clonados en paralelo?

Si es así, UAT no podría ser confiable ya que el comportamiento del entorno de integración puede cambiar muy a menudo ...

El concepto de despliegue continuo para UAT no está claro para mí ...

Answer 1

Oh chico. Estás golpeando problemas de CD del mundo real. Muy buenas preguntas.

La respuesta depende en parte del trabajo de desarrollo de los diversos proyectos.

En mi situación ideal para usted sería tener una serie de entornos de prueba específicos de "esfuerzo". En un caso, podría considerar un entorno de prueba para cada proyecto. Cuando hay una compilación completa del Proyecto A, la inserta en el Entorno A, que tiene las últimas versiones aprobadas / de producción para B / C, y puede realizar pruebas de integración básicas allí. Si pasan, usted promueve la construcción a un entorno de prueba de integración donde se implementa la última buena A, junto con el último B & C para la misma versión. Cuando el entorno de prueba de integración está pasando las pruebas, puede promover su contenido como un conjunto de versiones que contiene versiones conocidas de A, B y C. Ese conjunto de versiones se implementaría en cualquier entorno UAT, de estadificación o de producción.

La idea básica es dar a cada proyecto un grado de aislamiento para que pueda probarse bien, incluso si los otros proyectos están (temporalmente) mal interrumpidos, al tiempo que se obtienen las pruebas de integración completa lo más rápido posible. También queremos asegurarnos de que todo lo que encontremos en realidad pase las pruebas de integración se promoverán juntos. Elegir y elegir versiones de proyectos para lanzar que no se hayan probado juntos es demasiado arriesgado para mi gusto.

Este es realmente un tema del que tengo que hablar bastante. Si no le importa, voy a enumerar algunas de las presentaciones que he dado sobre estos temas.

1) CI de escalamiento para el desarrollo paralelo (presentado conjuntamente con Chris Lucca de Accurev)

Esto habla bien sobre estrategias amplias para equilibrar el aislamiento y la integración. Gran parte de ello supone que los subproyectos se están fusionando en una base de código común, pero los principios se pueden aplicar a módulos construidos y desplegados de forma independiente con solo un poco de imaginación.

2) Usando uDeploy con Jenkins (requiere registro)

Esto está más centrado en el producto, pero muestra casi exactamente la idea de utilizar un entorno de prueba de integración para múltiples proyectos, creando un conjunto de lanzamientos (lo llamamos "instantánea") y promoviendo eso. Nuestra integración con TeamCity es bastante similar, pero creo que la estrategia que se tiene puede ser más importante

3) Diapositivas visualizando una tubería de múltiples componentes:

http://www.slideshare.net/Urbancode/adapting-deployment-pipelines-for-complex-applications