Pues después de unos cuantos años haciendo builds, IC y demás os paso a poner un pequeño post para que los que estéis empezando con estos temas os resulte más fácil.
Primero creo que es importante hacer una pequeña referencia a lo que es Integración Continua.
Levels of Code Confidence
Antes de entrar en lo que es IC deberíamos tener claros los niveles de confianza del código, mejor lo ponemos en inglés que queda mejor. Levels of Code Confidence
• Primer nivel de Confianza. ¿Compila el código?. Si el código compila podemos asegurar que sintácticamente esta correctamente escrito, pero no podemos garantizar el fallo en ejecución.
• Segundo nivel de confianza. ¿Pasa el código nuestros Test?. Si nuestros test unitarios se ejecutan correctamente, habremos superado el segundo nivel de confianza.
• Tercer nivel de confianza. ¿Cubre el código nuestros requerimientos de negocio?. Si nuestras pruebas de usuario se ejecutan correctamente, habremos superado el tercer nivel de confianza.
• Cuarto nivel de confianza. ¿Cubre el código nuestros requerimientos de calidad?. Si se cubren nuestras métricas de código en cuanto a complejidad, habremos superado el cuarto nivel de confianza.
Integración Continua y sus Beneficios.
Entonces ¿Qué sería la Integración Continua?
La integración continua es un proceso que nos ayuda a cumplir con los niveles de confianza del código de una manera automatizada y entre otros nos aporta los siguientes beneficios.
• El código que hay en nuestro sistema de control de código “Funciona”. El código funciona a un determinado nivel: compila, pasa nuestros test unitarios, satisface nuestras métricas de código, etc.
• Menor tiempo invertido en integración. Permite la integración de los distintos componentes de un sistema de una manera más rápida y su evaluación de que funcionan correctamente y conjuntamente.
• Incrementa la visibilidad del proceso. Podemos ver el progreso de una manera más rápida, ya que cualquiera puede acceder a la versión actual desplegada mediante la IC y validar que lo que está 100% finalizado, realmente lo está.
• Reduce el riesgo del proyecto. Debido a este incremento de visibilidad del avance, se reduce el riesgo del proyecto.
• Reduce la fricción dentro de los equipos de proyecto. No hay que acceder al equipo para obtener una versión de software, la versión de Software estará siempre disponible.
• Incrementa la autonomía de los Testers. Disponen de los últimos avances desarrollados disponibles para probar.
• Menor tiempo invertido en la creación y despliegue de versiones. La automatización de la creación y despliegue de versiones, hace que todo este trabajo repetitivo sea considerado como una reducción notable de tiempo que no empleará el equipo.
• Incrementa la confianza entre los usuarios de negocio y el equipo de proyecto.
Integración Continua. Build de IC.
Sería difícil implementar IC sin disponer de una automatización de Builds que nos permita hacer de manera repetitiva algo que sino tendríamos que hacer de manera manual.
Para esto podemos utilizar Team Foundation Server. En realidad en una IC deberíamos pasar por todos estos niveles
Como esto es un pequeño ejemplillo, pues digamos que vamos a ver un proyecto que compila, se ejecutan los test, se crea el paquete de instalación y se despliega automáticamente en el entorno de test.
Los requisitos para este ejemplo son:
En el lado del servidor:
- Windows Server 2008 r2
- Team Foundation Server 2010 y Team Foundation Server Build
- Microsoft Web Deploy + todo lo que requiera por debajo en su instalación.
En el lado del cliente:
- Visual Studio 2010
- La solución ejemplo por ejemplo de MVC que ofrece el Visual Studio.
Se pueden hacer múltiples escenarios de deploy en el que tengamos que hacer cosas muy diferentes, yo he pasado por utilizar scripts, crear custom activities de WF para modificar los Templates de las Build de TFS, etc. Pero para este ejemplo he utilizado algo rápido y fácil de entender como webdeploy.
Sobre la solución original que crea Visual Studio, he añadido 3 transformaciones de ficheros web.config, para los típicos debug y release, así como un entorno personalizado que he llamado TestEnv.
En el Web.config principal he añadido una entrada en el Appsetings que sirve para almacenar el entorno en el que se “ejecuta” la aplicación.
En el caso de cada Web config transformado, se añade la conversión y el valor necesario para transformar el valor para el entorno en concreto.
También he modificado el controller del home para visualizar el valor de la variable del appconfig una vez que se ha desplegado, así podemos ver si se muestra el correcto, es decir si se ha producido la transformación de valores orientados para cada entorno, como pueden ser cadenas de conexión, etc.
En nuestro caso sólo la variable entorno.
Sí ejecutáramos en local, veríamos que aparece el literal “Entorno de desarrollo” y la versión 1.0 que es lo que tenemos puesto a pelo para empezar en el código de la vista.
Para preparar el servidor web, desplegamos a mano creando el sitio en el servidor de despliegue de pruebas, desplegando la misma versión y probamos que funcione.
Una vez que tenemos nuestra solución preparada, pues creamos la Build. Yo por norma suelo poner la rama y alguna información más como las siglas IC para saber que no es una build manual.
Después configuramos la build como build de integración continua.
Indicamos la carpeta base de los fuentes, etc
Especificamos la salida del Drop de la compilación.
Indicamos la solución a construir con la configuración que queramos, Release, Debug u otra que hayamos creado nosotros personalizada.
Lanzamos la build.
Y veremos si funciona.
Una vez que hemos probado la build, podemos pasar a indicarle los parámetros que forzarán a WebDeploy a desplegar nuestra aplicación.
/p:DeployOnBuild=True;
DeployTarget=MsDeployPublish;
CreatePackageOnPublish=False;
MSDeployPublishMethod=RemoteAgent;
AllowUntrustedCertificate=True;
MSDeployServiceUrl=MaquinadeDespliegue;
DeployIisAppPath=»Aplicación Web de despliegue»;
UserName=UsuarioDespliegue;
Password=ContraseñaUsuario
Una vez que hemos modificado la build, podemos cambiar el código de la vista home para que muestre por ejemplo 2.0 en el texto.
Creamos el Task (ya sabéis nada de subir las cosas de cualquier manera) y chacemos Checkin
Automáticamente se ejecuta la build de IC
Si ha pasado los Test, etc. La tendremos marcada como OK
Y si miramos lo que hay ahora en el servidor, veremos que se ha desplegado, que además nos pone “entorno debug” correspondiente con el tipo de compilación que elegimos (en mi caso debug).
En resumen, por cada checkin podríamos tener una compilación y una versión desplegada en un entorno de pruebas para probar.
Está claro que esto es un mundo, pero bueno los que queráis podéis empezar por aquí.