Integración Continua (CI)

Pensando la integración continua

La integración continua consiste en verificar que todo sigan funcionando mediante la compilación y ejecución de test en forma desatendida. es una práctica altamente recomendada cuando se trabaja en equipos de desarrollo y sobre todo muy positiva cuando los equipos son distribuidos.

También se extiende a la generación desatendida de builds, deploy a QA, métricas como puede ser el coverage, etc.

Armando una integración continua

En este caso vamos a usar:

No voy a hacer un step by step de como configurar cada una pues depende de las variantes que se quieran instalar en cada caso particular, pero cualquier duda concreta podés dejar un mensaje y la vemos.

Armando proyectos en Cruise Control

primero vamos a definir nuestro proyecto:

<project name="dms.ci" queue="dms">

donde name es el nombre por el que nos vamos a referir a este proyecto, queue es la cola de trabajo en la que participa el proyecto, esto sirve para agrupar los proyectos que NO se quieren ejecutar simultáneamente.

cada proyecto se dividen en cuatro partes principales:

1. triggers: definición de cuando vamos a disparar las tareas y ante que condiciones

En este caso estamos actualizando el proyecto cada 5 minutos y si hay novedades ejecutamos las tareas.

<triggers>
    <
intervalTrigger seconds="3600" initialSeconds="1" />
</
triggers>

O el famoso Nightly build, que en este caso se ejecuta de lunes a viernes a las 4 am.

<triggers>
    <scheduleTrigger time="4:00">
        <weekDays>
            <weekDay>Monday</weekDay>
            <weekDay>Tuesday</weekDay>
            <weekDay>Wednesday</weekDay>
            <weekDay>Thursday</weekDay>
            <weekDay>Friday</weekDay>
        </weekDays>
    </scheduleTrigger>
</triggers>
2. sourcecontrol: obtención de las novedades del código fuente

En este caso las obtenemos desde el repositorio svn de google code.

<sourcecontrol type="svn">
    <trunkUrl>https://dmsneluz.googlecode.com/svn/trunk</trunkUrl>
    <workingDirectory>c:\cruisecontrol\dms\CI</workingDirectory>
</sourcecontrol>
3. tasks: tareas a ejecutar

En este caso se trata de una tarea de MSBuild escrita en el archivo src/dms.msbuild cuyo target es Testing. (ver: lista (in)completa de tareas)

<tasks>
    <msbuild>
        <executable>C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
        <workingDirectory>c:\cruisecontrol\dms\CI</workingDirectory>
        <projectFile>src\dms.msbuild</projectFile>
        <buildArgs>/noconsolelogger</buildArgs>
        <targets>Testing</targets>
        <timeout>900</timeout>
        <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
    </msbuild>
</tasks>
4. publishers: informar los resultados

En este caso estamos agregando al reporte del CruiseControl el contenido de Reports\nunit-test.xml que es donde tenemos el resultado de la ejecución de los test que posteriormente va a ser vizualizado en el dashboard de ccnet.

<publishers>
    <merge>
        <files>
            <file>c:\cruisecontrol\dms\CI\Reports\nunit-test.xml</file>
        </files>
    </merge>

    <xmllogger />
</publishers>

Dashboard del proyecto de ejemplo

ccnet

hay una copia de los archivos de configuración actuales de cc en el repositorio del ejemplo, en la carpeta ccnet.

Post relacionado: Coverage con PartCover en un servidor de CI

No hay comentarios.:

Publicar un comentario