Compilar e implementar de forma continua

Cuando muchos desarrolladores colaboran en proyectos de software complejos, la integración de las diferentes partes de código puede ser un proceso largo e impredecible. Sin embargo, este proceso puede resultar más eficaz y más confiable si se compila y se implementa el proyecto de manera continuada.

La integración continua es el proceso de integrar el código en un repositorio compartido con tanta frecuencia como sea posible. Durante la integración del código, una interrupción de la compilación o un error de prueba pueden indicar sin demoras que hay un error en el código.

Martin Fowler ofrece el siguiente desglose de los procedimientos para la integración continua:

• Mantenga un repositorio de código fuente único.

• Automatice la compilación.

• Convierta su compilación en autosuficiente.

• Realice una protección al menos una vez al día.

• Compile cada protección en el servidor de integración continua.

• Mantenga la rapidez de la compilación.

• Pruebe en un clon del entorno de producción.

• Facilite que todos los usuarios obtengan el ejecutable más reciente.

• Sepa en todo momento lo que está sucediendo.

• Automatice la implementación.

Para obtener más información, vea la siguiente página en el sitio web de Martin Fowler: Continuous Integration.

Visual Studio Application Lifecycle Management (ALM) ayuda a administrar de extremo a extremo el proceso de desarrollo de software y admite la integración continua. Si se aprovecha la funcionalidad de Visual Studio ALM, se puede evitar que un proyecto sufra retrasos inesperados, costos excesivos y riesgos de ejecución.

En este tema

• Administrar las dependencias

• Integración continua en Visual Studio 2010

• Preparación e inicio

• Control de versiones

• Compilación

• Pruebas e implementación

• Integración del proyecto y comunicación

Administrar las dependencias

La integración del código es un proceso complejo debido a las dependencias. Por ejemplo, una biblioteca que dibuja un círculo en una pantalla depende del método Sqrt() de las bibliotecas matemáticas del sistema. Si el método Sqrt() cambia, se deberá actualizar la biblioteca en consecuencia. El hardware y los sistemas operativos cambian con menor frecuencia que los proyectos de equipo. Sin embargo, pasar por alto los cambios en cualquier circunstancia puede conducir a resultados desastrosos. La integración del código se puede realizar tan pronto como sea posible para examinar si se basa en hipótesis válidas y si funciona según lo previsto.

Los cambios en el código pueden afectar a las dependencias de manera distinta. En las siguientes ilustraciones se muestran dos situaciones. En el ejemplo que figura a la izquierda, se muestra un cambio relativamente aislado. Sin embargo, en el ejemplo que figura a la derecha, se muestra un cambio con un mayor impacto potencial porque tiene muchas dependencias.

En la siguiente ilustración, se muestra cómo los cambios constantes pueden tener efectos compuestos si no se integra y se actualiza el código de manera continuada.

En el paso 1, se cambia el bloque de código h, lo que posiblemente afecta a todos los bloques de código dependientes a, b, d, e y f. En el paso 2, se cambian los bloques de código a y b. Si el equipo no realiza una integración entre los pasos 1 y 2, es posible que los bloques a y b dejen de ser válidos. En el paso 3, se cambia el bloque de código f. Llegado a este punto y suponiendo que el equipo no realiza una integración entre los pasos 2 y 3, el bloque b se ha visto afectado, ha cambiado y se ha vuelto a ver afectado. Como resultado, la corrección del bloque de código b puede suponer un gran esfuerzo.

Integración continua en Visual Studio 2010

Visual Studio ALM proporciona conjuntos de herramientas integradas para admitir la integración continua. Como muestra la siguiente ilustración, estas herramientas incluyen el control de versiones, la compilación, la prueba, la implementación en un entorno de laboratorio, el seguimiento de los elementos de trabajo y la funcionalidad de almacenamiento de datos.

En primer lugar, se puede utilizar control de versiones de Team Foundation para administrar las bifurcaciones, los conjuntos de cambios y la integración entre ambos. Cada miembro del equipo puede utilizar las áreas de trabajo para trabajar de forma independiente. Para obtener más información, vea Bifurcar y combinar y Crear un área de trabajo para trabajar con el proyecto de equipo.

En segundo lugar, se puede usar Team Foundation Build para compilar, probar e implementar el software en un sistema automatizado y distribuido. Tal y como se muestra en las ilustraciones anteriores, Team Foundation Build tiene dos tipos de compilaciones. Un tipo utiliza una compilación continua para compilar la bifurcación de desarrollo. El otro utiliza un tipo de compilación de protección controlada para compilar la bifurcación principal. Visual Studio Team Foundation Server admite cinco tipos de compilaciones: manual, continua (que se desencadena con cada protección), gradual (acumula protecciones hasta que finalice la compilación anterior), de protección controlada y programada. Para obtener más información, vea Crear una definición de compilación básica, Descripción de Team Foundation Build System y Proteger los cambios pendientes controlados por una compilación de protección controlada.

En tercer lugar, la funcionalidad de Lab Management de Visual Studio ALM ayuda a definir e implementar las compilaciones en entornos de laboratorio físicos y virtuales. Para detectar los errores de integración en tiempo de ejecución en un entorno concreto, se puede implementar una compilación en un entorno de laboratorio y, a continuación, ejecutar conjuntos de pruebas en esta compilación. Para obtener más información, vea Usar un laboratorio virtual para el ciclo de vida de la aplicación.

Además, la funcionalidad de prueba de Visual Studio ALM está disponible en las máquinas de los miembros del equipo, en la máquina de compilación y en el entorno de laboratorio. En primer lugar, ejecutar conjuntos de pruebas en el equipo del desarrollador detecta los problemas con el código que se ha cambiado o creado recientemente. En segundo lugar, al ejecutar las pruebas en el equipo de compilación se detectan los problemas relacionados con la integración con otro código. En tercer lugar, al ejecutar las pruebas en el laboratorio se detectan los problemas relacionados con un entorno concreto configurado por el equipo. Para obtener más información, vea Cómo: Configurar y ejecutar pruebas programadas después de compilar la aplicación.

En cuarto lugar, Visual Studio Team Foundation Server es el repositorio donde se almacenan los elementos de trabajo. Se pueden crear, administrar y realizar un seguimiento de los elementos de trabajo, como errores o tareas, que están asignados a los miembros del equipo. Si se interrumpe una compilación durante la integración del código, el equipo deberá corregir el problema lo antes posible. Puede configurar Team Foundation Server para crear elementos de trabajo para las interrupciones de la compilación. Para obtener más información, vea Seguimiento de los errores, tareas y otros elementos de trabajo.

En último lugar, las bases de datos del almacén de Team Foundation Server y de SQL Server Analysis Services agregan y relacionan todos los datos proporcionados por los subsistemas de Team Foundation Server. Estos subsistemas incluyen el control de versiones, la compilación, la prueba, la implementación y el seguimiento de los elementos de trabajo. Por consiguiente, el equipo puede visualizar el proceso de un extremo a otro de la integración continua. Para obtener más información, vea Generar informes con la base de datos de almacén relacional para Visual Studio ALM.

Preparación e inicio

El equipo puede seguir los procedimientos que se detallan a continuación para empezar a utilizar la integración continua y Team Foundation Server:

1. Utilice control de versiones de Team Foundation para integrar el código en una sola base de código.

2. Cree un tipo de compilación manual en Team Foundation Build.

3. Ejecute casos de prueba automatizada para comprobar la calidad de la compilación. Si no dispone de un conjunto de pruebas adecuado, cree un marcador de posición e importe algunos casos de prueba automatizada. Este conjunto puede servir como marcador de posición para pruebas futuras.

4. Asegúrese de que los binarios resultantes de la compilación se coloquen en una ubicación compartida. Esta estrategia ayudará a diagnosticar los problemas que aparezcan durante las pruebas.

5. Utilice Microsoft Test Manager para detectar los errores de integración en tiempo de ejecución en un entorno concreto.

Control de versiones

Un sistema de control de versiones proporciona un repositorio compartido al código. Un equipo reducido puede trabajar con una sola bifurcación. Sin embargo, trabajar con dos o más bifurcaciones es más factible porque normalmente hay que desarrollar varias versiones de código y lanzar el proyecto en diferentes hitos. Para obtener más información sobre cómo crear y combinar bifurcaciones de código, vea la siguiente página en el sitio web de CodePlex: Team Foundation Server Branching Guide 2.0.

Compilación

En la integración continua, un sistema de compilación genera los componentes ejecutables que se pueden probar e implementar. Un sistema de compilación también proporciona comentarios en forma de errores de compilación y advertencias. Estos errores son debidos a cambios que se realizan en el origen del proyecto.

Team Foundation Build proporciona los siguientes tipos de compilación:

• Manual: los miembros del equipo ponen las compilaciones en cola.

• Continua: una protección pone a las compilaciones en la cola de una bifurcación del control de versiones.

• Gradual: las compilaciones se acumulan hasta que termina la compilación anterior.

• De protección controlada: las compilaciones solo se aceptan si los cambios enviados se combinan y se compilan correctamente.

• Programada: las compilaciones se realizan conforme a una programación definida.

Para obtener más información, vea Crear una definición de compilación básica.

¿Cuáles son las expectativas de los miembros del equipo para implementar la integración continua correctamente?

Los miembros del equipo deben organizar sus orígenes para que la compilación no dure más de 10 minutos. En proyectos mayores, dicha frecuencia quizás no sea posible. Con Team Foundation Server, el equipo puede configurar varias definiciones de compilación que compilan diferentes subconjuntos de la base de código. Si las compilaciones tardan mucho tiempo, se puede usar un tipo de compilación gradual para generar de manera continuada binarios del código no cambiado.

Si una compilación se interrumpe, el equipo tiene que corregirla inmediatamente. Si suponemos que la bifurcación principal no se ve afectada por una integración inversa errónea, la mayoría de las interrupciones se deberán a una protección errónea en una bifurcación de trabajo o a una integración hacia delante desde la bifurcación principal. Se recomienda asignar a un miembro del equipo la tarea de corregir las interrupciones de compilación durante un período de tiempo y, a continuación, rotar esta asignación entre los miembros del equipo.

¿Cuántas compilaciones se deberían ejecutar al día?

Cuando se realiza la integración de código de manera continuada, se puede ejecutar una compilación continua para cada protección que se produce en cada bifurcación. También se puede ejecutar una compilación gradual que sea independiente del nuevo código protegido. Para obtener más información, vea Crear una definición de compilación básica y Supervisar el progreso de una compilación en ejecución.

¿Cómo Team Foundation Server puede ayudar a acelerar la compilación de código?

Configurar la definición de compilación para realizar compilaciones incrementales ayudará a aumentar la velocidad de la compilación. Los registros de compilación se pueden utilizar para identificar las partes lentas de la compilación, lo que permite realizar mejoras. Para obtener más información, vea Configurar Team Foundation Build para compilación incremental.

¿Cómo puede ayudar Team Foundation Build a escalar la integración continua?

Los controladores de compilación y agentes de compilación pueden ayudar a escalar el ciclo de integración continua.

Para obtener más información, vea Descripción de Team Foundation Build System.

Pruebas e implementación

¿Cómo encajan las pruebas y la implementación con la integración continua?

En la siguiente ilustración, se muestra cómo las características de pruebas e implementación de Visual Studio ALM encajan en la integración continua.

En primer lugar, al integrar el código de manera continuada, se pueden detectar los problemas con el código de la propia compilación. La compilación se ha realizado o no, dado el compilador que se ha utilizado. Se puede generar un informe de compilación que contiene mensajes de error y de advertencia del compilador. En Visual Studio ALM, el informe de compilación también proporciona información como qué errores se corrigieron en esta compilación, qué conjuntos de cambios se incluyeron en esta compilación y si se ejecutó el análisis de código durante la compilación. Con Visual Studio ALM, se puede comprobar si el diseño del código sigue las reglas definidas por el equipo. Para obtener más información, vea Cómo: Validar código .NET con diagramas de capas.

En segundo lugar, se pueden detectar los problemas con el código ejecutando pruebas unitarias. Estas pruebas diagnostican los problemas de manera diferente que los compiladores. Las reglas de los compiladores comprueban los problemas en materia de sintaxis de código y construcciones de lenguaje. Por el contrario, las pruebas unitarias (que se pueden ejecutar en una compilación una vez completada esta) pueden comprobar cualquier aspecto funcional del código. Estas pruebas unitarias también pueden proporcionar métricas como la cobertura de código de una compilación dado un conjunto de pruebas unitarias. Para obtener más información, vea Cómo: Configurar la cobertura de código mediante la configuración de pruebas para pruebas automatizadas.

Con Microsoft Test Manager, se puede configurar un entorno específico en el que ejecutar pruebas. Las pruebas unitarias aisladas pueden proporcionar un nivel de comprobación funcional. Sin embargo, los entornos tienen los siguientes aspectos importantes:

• Los entornos variables pueden afectar al funcionamiento del código. Por ejemplo, la configuración y topología de red podrían ser difíciles de probar sin un entorno de administración de laboratorio.

• La automatización de la implementación de código en un entorno concreto ayuda al equipo a disminuir el tiempo de implementación y aumentar el número de iteraciones de implementación.

Para obtener más información, vea How to: Create an Environment from Virtual Machine Templates y Configurar máquinas de pruebas para ejecutar pruebas o recopilar datos.

¿Cómo se pueden organizar los conjuntos de pruebas para habilitar la integración continua?

Puede optar por ejecutar los conjuntos de pruebas más importantes para las compilaciones continuas porque un número excesivo de pruebas puede retrasar la finalización de la compilación. Asegúrese de ejecutar estas pruebas para la iteración actual.

En un ciclo de compilación nocturno o programado, también puede ejecutar las pruebas de compilaciones anteriores y las pruebas completas superadas que comprueban la funcionalidad en sprints anteriores.

¿Cómo afecta la integración continua al equipo de pruebas?

La integración continua ayuda a identificar compilaciones que contienen errores para que el equipo no pierda tiempo instalando y trabajando con compilaciones erróneas.

Integración del proyecto y comunicación

El esfuerzo de implementar la integración continua puede ser considerable en función del tamaño del proyecto. El equipo debe definir y programar el trabajo de la integración continua en el primer sprint del proyecto.

Si desea adoptar la integración continua en diferentes fases, puede comenzar por implementar la compilación automatizada. A continuación, puede modificarla para incluir la ejecución de pruebas unitarias. Por último, puede agregar la funcionalidad de implementar la compilación probada en un entorno de laboratorio y, a continuación, puede ejecutar pruebas en el entorno para comprobar si un entorno variable afecta al código.