Actualmente tengo a cargo un proyecto en el que somos 13 desarrolladores en distintos lugares de Argentina y en Colombia. Por esta razón, lo primero que pensé es en armar un servidor de integración continua. Cuando lo planteé, la condición fue que no debía requerir licencias de software (salvo la de Windows). No tenía mucho tiempo para esta tarea así que fui a lo conocido: CruiseControl.Net, Subversion, MSBuild, NUnit, Wix, TortoiseSVN y un sin fin de scripts, xslts y herramientas propias.
Hasta ahora lo que tengo armado es lo siguiente:
- CC.Net verifica cada 60 segundo si han habido cambios en la rama de desarrollo o en la de release
- si hubieron cambios, baja a un directorio del servidor la última versión del código del branch que acusa cambios
- solicita a subversion el número de revisión del código que descargó y actualiza el archivo VersionInfo.cs con el número de revisión en AssemblyVersion y en AssemblyFileVersion
- Compila todos los proyectos .csproj de los directorios Code y Tests
- Corre las pruebas unitarias
- Crea los scripts de bases de datos a partir de los scripts en los proyectos de bases de datos .dbproj (este es un punto de interés ya que no contamos con VS2010 en el servidor)
- Crea los instaladores de bases de datos y del proyecto web
- Copia estos instaladores en una carpeta cuyo nombre depende de la versión del código (ver la imagen de abajo). Estas carpetas están publicadas carpetas virtuales “browseable” de manera que cualquiera pueda descargarse los instaladores via http
- envía los mails a quienes corresponda según la configuración para cada rama. Es decir, si es sobre la rama de release avisa al project leader y a quality control mientras que si es sobre la rama de desarrollo el esquema es bastante mas complejo.
- cuando se trata de la rama de release, el listado de defectos arreglados se obtiene de aplicar una transformación XSL al log del SVN buscando los comentarios que comienzan con BUGFIX# y se publica en CC.Net relacionado a la versión del buid (solución del hombre muy pobre)
Por otra parte, en las máquinas de desarrollo, impedimos la realización de commits con el build roto y sin comentarios mediante dos scripts que se engancha en el pre-commit hook de TortoiseSVN y se ejecutan justo antes de hacer el commit. el primero simplemente consulta a CC.Net sobre el estado del build y advierte si este está roto. el segundo simplemente advierte cuando se intenta hacer commit sin un comentario.
Lo continuaré.
