Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

Por aquí ya hemos hablado una vez y otra sobre como gestionar los datos sensibles (como las cadenas de conexión) de nuestras aplicaciones, porque, claro, nadie debería de poner los datos de producción en el código fuente que grabamos en nuestro repo, ¿verdad?

Anteriormente las opciones pasaban por efectuar mezclas/transformaciones de tal manera que en tiempo de compilación se generara un archivo final con los datos sensibles correspondientes a cada entorno, lo cual si bien nos daba simplificación para colocar la clave correcta en el paquete y entorno correcto, nos obligaba a seguir versionando las cadenas de conexión en el código fuente (por no mencionar que había que compilar mas de una vez); la otra opción pasaba por gestionar dentro del entorno de destino (en nuestros ejemplos: WebApps) sobrescribiendo de esta manera los valores que vinieran desde el código fuente.

Dado que ni nuestro repositorio ni nuestra herramienta de integración/despliegue deberían contener datos sensibles, usaremos un servicio de nube que nos da la seguridad necesaria para gestionar nuestras credenciales, el Azure KeyVault, el cual nos permite almacenar de manera segura y granular ya sea certificados digitales como data sensible, pudiendo restringir quienes pueden acceder a que datos y a que no (aplicando Control de acceso basado en roles: RBAC). Un mecanismo usual de accesos a estos recursos sensibles es programar dentro de nuestra aplicación un código que lea los valores en tiempo de ejecución (procurando no releer el valor a cada uso, sino hacerlo una única vez), en este caso usaremos un enfoque distinto que consistirá en leer los valores almacenados en KeyVault durante nuestro pipeline de despliegue, alterando secciones del archivo appsettings.json (porque nuestro ejemplo se basara en .Net Core) que se alojara en nuestra Web App destino (aunque también funciona perfectamente en un despliegue sobre IIS).

Así que estos serán los pasos que seguiremos:

  • Crear un KeyVault
  • Crear un “Secret” dentro de nuestro KeyVault, ahí sera donde almacenaremos una cadena de conexión a la base de datos
  • Identificar el “Principal” mediante el cual nuestro Team Project se conecta a Azure
  • Dar los permisos sobre nuestro KeyVault a dicho principal
  • Identificar en nuestra aplicación las secciones a modificar en tiempo de ejecución
  • Enlazar nuestro TeamProject contra el KeyVault, fijando el scope respectivo
  • Configurar el reemplazo de valores en el appsettings.json
  • Validar que nuestros cambios han sido desplegados en el entorno destino

Para esta demo asumiremos que tendremos tanto un pipeline de Build como de Release, de una aplicación en ASP.Net Core, en nuestro ejemplo usare la aplicación de ejemplo del libro de EF Core in Action (excelente libro que tuve el honor de revisar) cuyo código fuente se puede descargar aquí, y claro, como es usual el despliegue lo haremos contra una Azure Web App.

Para el primer paso seguiremos las instrucciones dadas en la primera parte de este articulo, en mi caso he usado estos nombres: RG_DevmoVault01 para el Resource Group y ErnestoDemoKeyVault para el KeyVault, como en este caso la creación la hemos hecho vía linea de comandos verificaremos que podemos revisar este recurso en el Portal de Azure, así:

Finish Reading: Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

Presentando Azure DevOps

El día de hoy Microsoft anuncia Azure DevOps, que a primera vista podría ser un nuevo rebranding de VSTS, pero la realidad detrás de este cambio es mucho mas compleja, así que trataremos de explicarlo haciendo un poco de historia.

Team Foundation Server es presentado el 2005 como una solución integrada para las necesidades ALM de la época, en que se empezaba a buscar herramientas que apoyaran la gestión interactiva de proyectos, así como ir desarrollando los conceptos de Integración Continua y Gestión de Pruebas, rápidamente el producto fue adoptado por buena parte de las organizaciones que ya estaban trabajando con .Net como su plataforma de desarrollo de software, las versiones 2008 y 2010 fueron una mejora incremental que fueron simplificando el trabajo de los equipos, pero aun así el configurar un proyecto de Integración Continua requería pelearse con componentes de terceros y editar archivos XML.

El primer punto de quiebre se produce 2011 con el lanzamiento del preview de Team Foundation Service (que luego seria renombrado como Visual Studio Online) que al inicio era una implementación basada en Azure de los servicios que ofrecía TFS (y que me entusiasmo mucho apenas saque mi cuenta), pero que además de proveer al publico de una infraestructura ALM sin depender de la instalación de un servidor, permitió a Microsoft acelerar sus ciclos de entrega de novedades y pruebas de nuevas funcionalidades, siendo que la versión 2012 de TFS incluía como novedad esencial (al menos para mi) un nuevo modelo de creación de Builds Definitions, basado en XAML, que efectivamente hizo mas sencillo el proceso de despliegue… si usabas las plantillas proveidas en el producto! y es que la idea original era posibilitar la creación de plantillas personalizadas para diversos tipos de entorno (recuerdo que por ahí encontré una plantilla para facilitar el despliegue con ClickOnce, pero que nunca pude hacerla funcionar), para este año ya era mas que notorio el crecimiento de Git y GitHub como plataforma preferida de los desarrolladores, así que la versión 2013 de TFS incluía su propio repositorio Git (al igual que el entonces llamado Visual Studio Online), pero los cambios recién empezaban… Finish Reading: Presentando Azure DevOps

Gestión de la Configuración de ASPNET 5 con Azure (y Docker!)

Quienes han leído mis anteriores artículos sobre el despliegue en Azure pensaran que uff, ya tenemos todo listo para buscarnos la vida hasta que Release Management de un soporte total a PaaS, pero la verdad es que la cosa tiende a evolucionar y hay que hacer pequeños ajustes de cara a los cambios que se anunciaron en el Build y que vienen con el Visual Studio 2015.

Esto a propósito de la posibilidad que nos ofrece Microsoft de desarrollar aplicaciones .Net que corran tanto en Mac como en Linux, una posibilidad totalmente disruptiva que es todo un ejemplo de los cambios que llegaron de la mano de Satya, pero claro, esto no implica que lo que hemos desarrollado hasta ahora en ASP.NET lo recompilamos y lo subimos a Linux y ya esta… no, claro que no, para lograr el objetivo Microsoft ha sacado una nueva edición del .NET Framework llamada Core, sobre la cual se ha desarrollado una nueva versión de ASP.NET (concretamente la 5) mas modular y ligera, sin las dependencias monolíticas usuales, aprovechando tendencias ya existentes en el mercado: Bower, Grunt, npm…

Genial, pero todo esto viene con un precio, el primero y para mi el mas doloroso es que esta nueva versión de ASPNET no incluye proyectos en WebForms (sniff :'( ), ha habido un reacomodo en algunas librerías (sobre todo de cara a lograr la integración entre MVC y WebAPI), desaparición de global.asax, en fin no doy mas detalle porque para eso mejor leer los artículos de José M. Aguilar que va cubriendo con detalle las cosas que van saliendo.

Pero dentro de todos los cambios habidos hay uno que nos afecta especialmente a quienes trabajamos en la gestión de entornos de trabajo y de despliegue, y es que por defecto al crear un proyecto nuevo ya no hay un archivo web.config, esto debido a que la gestión de configuración ya no esta centralizada en un archivo monolítico sino que puede estar dispersa a lo largo de un conjunto de archivos (de preferencia JSON) o de las variables de entorno del sistema, correspondiendonos a nosotros el elegir que archivos usaremos y en que orden de secuencia y prioridad se van sacando, y claro la forma de acceder a estas propiedades, que vimos anteriormente, han cambiado.

slots29

Si pues, ya no mas ConfigurationManager y similares…

Y por lado de la estructura de los archivos JSON seria de esta forma, mucho ojo a este config.json, lo usaremos mas abajo:

configjson

Ok, entonces ¿como hago para acceder a dichos valores desde mi código? Finish Reading: Gestión de la Configuración de ASPNET 5 con Azure (y Docker!)

Renombrado de Team Projects en Visual Studio Online

Al parecer si había una característica muy solicitada en Visual Studio Online era la de poder renombrar un Team Project una vez creado, me imagino que por ejemplo, tu cliente ha decidido cambiarle el nombre a todo el proyecto, o peor aun… que este decida cambiar su razon social y tu equipo tiene que alinearse acorde a ello, pues bien eso hasta ahora no era posible pues al momento de crear un Team Project se te indicaba que tu elección de nombre no se podia cambiar.

Lo bueno es que como ya se venia anunciando hace tiempo, desde este 24 de Abril ya es posible hacer dicho renombramiento, para lo cual podemos hacerlo desde la zona de administración de la Collection, como se nos indica en la pagina mencionada:

IC795516

O bien, desde la zona de administración del proyecto, para lo cual simplemente tenemos que editar el Nombre debajo de Project Profile y darle a grabar, en este caso he probado con un Team Project de una demo que realice hace dos años y que se llamaba Summit2013Beta al cual lo renombrare como Summit2013.

RenameTeamProjectNótese de la alerta que nos aparece, se nos indica que esta operación es disruptiva por lo que debería efectuarse fuera de horas de trabajo, lo cual tiene toda la lógica del mundo si es un TP que tiene un equipo que esta trabajando en él, adicionalmente se nos recuerda que:

  1. Las buils corriendo durante el renombrado pueden fallar
  2. Todos los usuarios deben reiniciar Visual Studio
  3. Los repositorios Git remotos deben ser actualizados con el nuevo nombre de Team Project
  4. Los Workspaces (si usamos TFVC) deben ser corregidos mediante un “Get latest versión”
  5. Si estamos usando workspaces locales (introducidos en VS 2012 ¡como pasa el tiempo!) se requiere usar VS 2013 Update 5 o VS 2015 (RC o mas reciente) a fin de que los workspace se actualicen en el siguiente “get”, si no se puede hacer la actualización o aun se sigue usando VS 2012 no quedara mas remedio que archivar (shelve) los cambios, crear un nuevo workspace y luego desarchivar (unshelve) los cambios (una razon mas para actualizar ¿no?).

Pues nada una petición de los desarrolladores ya esta disponible, a obrar con cuidado si necesitamos hacer uso de ella, mas detalles aquí.

Gestión automática de entornos de despliegue con Azure (tercera parte ¡desplegando!)

Luego de que el camino de usar las Azure API Apps no fuera el mas adecuado para la prueba de concepto (lo cual no quita que sea una tecnología muy prometedora para desarrollar con REST) de nuestro entorno de despliegue, toca proceder a usar los ya conocidos Azure Websites para el ejemplo, en ese sentido repasemos lo que tenemos hasta el momento:

  • Un Team Project en Visual Studio Online, bajo modelo Git (por cierto ¿sabían que está en camino la posibilidad de renombrar los proyectos?)
  • Ya sabemos cómo subir nuestros cambios de nuestro repositorio local de Git a VSO
  • Ya sabemos cómo crear un entorno de despligue en Azure desde Visual Studio, lo hemos visto con API Apps, pero el proceso es básicamente similar para Azure Websites, y claro también hemos aprendido a desplegar desde Visual Studio.
  • Hemos entrado al Portal de Azure y revisado lo que hemos instalado desde Visual Studio.

Con estas bases regresemos a nuestro problema inicial, gestionar los despliegues en entornos separados de QA, Staging, Preproducción, Integración, etc.., en ese sentido debo mencionar que las practicas usuales y conocidas respecto a Integración Continua se basan en el versionamiento de : Código fuente, scripts, datos de prueba, archivos de configuración, siendo lo de Infraestructura como Código un paso más allá en ello (algo en lo que tengo que ponerme cuanto antes); dicho esto el enfoque asumido por Microsoft en los web slots consiste en dejar que el entorno (Azure en este caso) se haga cargo de la gestión de ciertos atributos críticos (definidos por los usuarios, claro está) como las cadenas de conexión a BD de producción, lo cual permite copiar todo el contenido versionado con la seguridad de que no habrá forma de que se hagan públicos esos datos sensitivos, probablemente este enfoque (que personalmente me reduce la cantidad de Perfiles de Publicación que debo de crear en mi proyecto) sea chocante para algunos, pero yo lo veo como una apuesta muy seria y con bastante lógica especialmente cuando ya se trabaja con entornos muy sensitivos, recordemos que los archivos de transformación, que vimos en la primera parte de esta serie, obligan a tener una copia de los atributos variables de cada entorno a fin de luego poder regenerar un .config mezclado.

(Muchas gracias a Scott Hunter quien en el último DevDays me conto estos detalles y permitió que le diera un nuevo vistazo a los slots que es el que comparto con ustedes)

Ya sabemos a que vamos a enfrentarnos, así que manos a la obra.

Como primer paso agregamos a nuestra solución un nuevo proyecto ASP.NET Web que llamaremos WebSlots02SimpleWeb, en este caso lo estamos agregando dentro de la estructura de solución WebSlots01 que ya teníamos.

slots25 Finish Reading: Gestión automática de entornos de despliegue con Azure (tercera parte ¡desplegando!)

Gestión automática de entornos de despliegue con Azure (Primeros pasos y un pequeño tropiezo)

Visto el contexto del problema y la solución potencial, decidí verificar si era posible aplicar esta solución dentro de los nuevos Azure API Apps, nueva tecnología agregada a la oferta de Azure que permite generar APIs REST a nuestra aplicación de manera sencilla, evolucionando lo que ya conocíamos de las Web API.

De primera entrada fijemos los objetivos y características de lo que trataremos de demostrar:

  1. Gestionar nuestro respositorio en Visual Studio Online, usando Git como modelo de repositorio.
  2. Efectuar despliegues automatizados a cada vez que hagamos un commit y sincronización hacia VSO.
  3. Que cada entorno desplegado utilice distintos valores de configuración, que la aplicación sea capaz de “leer” dichos valores y actuar acorde a ello.
  4. Efectuar Intercambios (swaps) entre nuestro entorno de QA, hacia Producción, verificando que si bien la aplicación se actualiza, los valores de configuración se mantienen.

Nuestro primer paso es crear un proyecto en Visual Studio Online, asi que vamos a ello:

Slots01Creado nuestro proyecto vamos a Visual Studio 2013 y nos conectamos a nuestro servidor eligiendo al Team Project que acabamos de crear:

Slots02Hecho esto, nos corresponde “clonar” (esto es terminología Git) el repositorio para empezar a trabajar

Slots03

Finish Reading: Gestión automática de entornos de despliegue con Azure (Primeros pasos y un pequeño tropiezo)

Gestión automática de entornos de despliegue con Azure (Introducción)

510af5389e0b9b98decb66e3b5fd6577e3f73032a4e336aeb523b1c836901341   A estas alturas ya debería estar claro para que sirve la integración continua y sus ventajas: el tener un sitio donde se corran todas las compilaciones y tests, el evitar “en mi maquina funciona”, reducir el tiempo de despliegue, el tener una buena gestión de los diversos entornos ¿no?

Bueno, en esta ocasión quiero referirme a la gestión de los diversos entornos en que va a correr nuestra aplicación durante su ciclo de vida: Desarrollo, QA, Staging, PreProducción, Certificación, Producción, etc, como quieran llamarle, pero el caso es que mal que bien (aun cuando no se usen practicas Agiles, DevOps o Integración Continua) al menos hay un reconocimiento en las organizaciones de que no se puede pasar las aplicaciones directamente de la máquina del desarrollador a Producción, bueno, salvo el caso de un sitio donde trabaje en el que los entornos de PreProducción estaban tan desactualizados que no quedaba otra que hacer los pases “en caliente”.

Pero como ya sabemos, cuando trabajamos en múltiples entornos, debemos asegurarnos que cada entorno tenga un conjunto de parámetros separado, de tal manera que no vaya a ser que al entorno de Producción se le dé por escribir en el entorno de QA, o a QA buscar la máquina del ultimo desarrollador que hizo el pase de entorno, de ahí que en buena parte de los despliegues (manuales) se dedique buen tiempo a verificar que estamos copiando los archivos de configuración en el entorno adecuado, y claro esta tarea es pequeña pero estresante.

Entornos

Soluciones hay muchas y una de las que nos brinda desde hace buen tiempo Visual Studio son las “transformaciones” que básicamente consiste que en adición a nuestro Web.config y app.config incluyamos en nuestro proyClipboard01ecto archivos de nombre web.EntornoObjetivo.config como se ve en el gráfico, siendo que cada uno de estos archivos contiene fragmentos XML donde se indican que atributos de configuración serán alterados en el entorno destino y que valores se colocaran en reemplazo de los que habían en Web.config. Finish Reading: Gestión automática de entornos de despliegue con Azure (Introducción)

Decisiones de repositorio y workspace en TFS/VSO

Antes cuando desarrollabas SW y se te planteaba el versionar tu código fuente algunos no tenían idea de lo que se hablaba, y en el otro extremo solo había dos opciones ampliamente usadas: SourceSafe y CVS, aparte claro de opciones chapuceras como: diskettes, carpetas fechadas compartidas y USB.

Ahora mucha agua ha corrido bajo los puentes, así que el que no versiona SW es porque ha vivido aislado de la realidad, o porque de alguna manera no ve la justificación económica de ello (hace poco me comentaron que una entidad crediticia sigue manejando sus desarrollos con carpetas fechadas y comprimidas y recién iban a analizar la viabilidad de usar SVN), por lo que el problema en estos momentos es decidir que repositorio usar y las implicancias de su decisión.

En este momento me pueden decir “¡Pero tu usas TFS, ya no tienes que decidir!”, pues la verdad que no, hasta el 2010 no había que tomar muchas decisiones, pero en el momento actual también toca decidir como es que vamos a usar TFS, entonces.. vamos a ello, repasemos el escenario.

En este momento al crear un proyecto en TFS/VSO tenemos dos opciones de mecanismo de control de versiones:
 

TFVC: El mecanismo tradicional de TFS de toda la vida, heredando terminología de SourceSafe como “check-in” “check-out”, pero mucho mas potente, todo almacenado en SQL Server, permitiendo gestión de branches y merges, aparte claro esta de la integración de tus changesets con una actividad determinada. Su modelo es Centralizado al igual que Subversión por ejemplo, con todas las implicancias que eso trae, que no vamos a discutir ahora.

Lo curioso es que si optamos por usar esta modalidad hay que tener en cuenta un detalle adicional: el tipo de Workspace ya que hasta TFS 2010 solo había el workspace en servidor, vale decir que el servidor de TFS llevaba un seguimiento de cual es el estado de cada una de las maquinas que se conectaban al repositorio, lo cual debemos reconocer no funcionaba muy bien, llegando al extremo de que en algún momento el usuario sabia que no estaba sincronizado, pero el servidor insistía en que no tu workspace esta bien, y arreglar eso, complicado.

Con los workspace locales, esos problemas ya no existen, aparte de que proveen una mayor flexibilidad para trabajar sin problemas cuando el servidor esta desconectado, pero de eso nos cuenta con mas detalle El Bruno, solo debo añadir que si se opta por TFVC solo hay un escenario en el cual tendría sentido usar workspace en el servidor: cuando tu IDE aun es VS 2010 o anterior, en cualquier caso es workspace locales, ahh la decisión se hace en el IDE no en el servidor.

Git: ya hemos hablado anteriormente de este recién llegado a las plataformas Microsoft, y creo sinceramente que debemos probarlo, intentar usarlo en nuestros proyectos, pues los DVCS han llegado para quedarse y Git ya es casi el estandar de facto, proveyendo muchas ventajas; dicho esto debemos ser conscientes que a la fecha (si alguien lee esto 2 años despues puede que se ria), si bien Microsoft ha integrado totalmente el “protocolo” backend de Git en sus productos aun no ha terminado de pulirlo en cuanto a interfaz (quiero creer que la próxima versión de VS tendrá una interfaz para Git que rivalice con SourceTree) y que de momento no podemos usar una herramienta tan potente como los Code Review integrados, a los cuales me acostumbre rápidamente cuando use por primera vez TFS 2012, ni tampoco los Gated Check in a la hora de hacer Integración continua (en breve: esta modalidad permite que un cambio no se añade al repositorio si la Build falla).

Conclusión: si no tienes una demanda muy fuerte de hacer uso de CodeReview o Gated Check In, usa Git, pero de la mano ve aprendiendo los comandos aun no disponibles desde el IDE, pues seran necesarios para sacarle el jugo. En otro caso (el Code Review si que puede ser un deal breaker en muchos casos) no temer y usar los workspace locales con TFVC.

A ver cual es la situación de aquí a un año, probablemente nuestro flujo cambie para entonces.

“En mi maquina funciona” no es una respuesta, es un sintoma

Cuando trabajamos en despliegue de proyectos de desarrollo, y aun no hemos pasado a procesos de Integración Continua en algún momento tenemos a escuchar la frase “en mi maquina funciona” cuando se apunta que no se puede desplegar la aplicación o que estando desplegada no funciona como se esperaba.

Como indico en el titulo el que esa expresión aflora es un síntoma de que algo no esta bien dentro del ciclo de vida de la aplicación, lo mas sencillo podría ser suponer que no hay proceso de Integración y Entrega Continua, y en ese caso la alerta nos debería empujar a organizar uno (de eso trataremos en futuras entregas), no hay vuelta que darle, el tiempo que pierdes en hacer despliegues manuales es desperdicio y sujeto a grave riesgo de errores de los que “en mi maquina funciona” puede ser el menor de ellos (imagínate hacer que la aplicación grabe en la BD de otro entorno).

El problema mas serio es cuando habiendo esos procesos aun se escuche esa justificación, en este caso debemos plantearnos las siguientes preguntas:

  • ¿Los miembros del equipo son conscientes (o han sido educados) de la necesidad de contribuir frecuentemente código sano? No es raro que algo que compile en local falle en IC porque algún fuente no se subió.
  • ¿Se tiene una estructura que efectivamente permita hacer un despliegue de todo lo ultimo con un clic?
  • ¿La cobertura de pruebas unitarias es razonable?
  • ¿Hay una cultura (a falta de mejor nombre) de revisar y entender los logs cuando ocurre un problema en el servidor de Integración Continua?

Estas preguntas y otras que vayan surgiendo tienen que caer de alguna forma en las retrospectivas del equipo para alcanzar el grado de madurez que nos permita hacer unos despliegues exitosos y sin dolor; y claro, recordar que si bien la tecnología nos ayuda a automatizar nuestros procesos el factor humano es indispensable para que el ciclo funcione adecuadamente.

Integrando Continuamente Visual Studio 2012 con Hudson

Quienes me conocen personalmente saben que me encanta Team Foundation Service como herramienta ALM y de Integración Continua, pero a veces toca que por diversas razones no podamos contar con esta solución que out of the box nos ofrece muchas cosas, en este caso el stack con el que teníamos que trabajar era Subversion y Hudson, por las referencias que tenia ya varios proyectos habían utilizado el plugin de Hudson con MSBuild (y no estaba dispuesto a experimentar con Nant 😉 ), pero nuestro caso era diferente, iba a ser en Visual Studio 2012, por lo que se configuro de manera habitual (conexión de Hudson con SVN y configuración del MSBuild), nada fuera de lo habitual excepto que los builds fallaban.
clip_image001
Bueno, el primer error que pude ver en el log era que de alguna manera el MSBuild instalado “no entendia” la nueva versión de archivos .sln de Visual Studio 2012, investigando pude encontrar un caso similar, concretamente cómo hacer para que un Agent de TFS 2008 pudiera ser capaz de compilar soluciones de Visual Studio 2012, la solución que se planteaba era instalar los Agents de Visual Studio 2010, así que por analogía supuse que había que instalar los Agents de Visual Studio 2012 sobre nuestro servidor de integración, y si, eso era… el formato de VS 2012 ahora sí que era entendido por el MSBuil de nuestro Hudson.

Pero a pesar de eso la build seguía fallando, y al revisar nuevamente el log descubrí que era porque no se encontraba el Assembly System.Web.Mvc y otros mas , upss, asi que toco volver a Visual Studio y comprobé que a pesar de que había hecho un “update-package” para actualizar todas las referencias del Nuget (si no sabes de que estoy hablando revisa este interesante articulo) por ahí se me habían colado unas referencias a las librerías instaladas en mi sistema y no a las que estaban en la carpeta “packages” (que como recordaran es gestionada por Nuget), en este caso fue mas

clip_image003

sencillo, borrar las referencias e instalar las referencias en los proyectos respectivos:
En todo caso, la moraleja de esta etapa es “NuGet es tu amigo, si NuGet puede manejarlo, no lo hagas tu a menos de que estés seguro que no puede hacerlo (como puede ser una librería comercial”).
A estas alturas ya estábamos mas confiados en que saldríamos de esta, la build seguía fallando, pero esta vez el mensaje de error se encontraba al final del log:

error MSB4019: The imported project "C:Program Files (x86)MSBuildMicrosoftVisualStudiov11.0WebApplicationsMicrosoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

La búsqueda me derivo a este artículo, que si bien era enfocado a TFS nos daba una sugerencia totalmente valida: copiar esa carpeta de una máquina que tenga una instalación completa de Visual Studio 2012 (recordemos que la idea es nunca tener que instalar todo el VS en el servidor de Integración Continua, solo lo mínimo necesario), se hizo eso y.. listo!

Build succeeded.
    0 Warning(s)
    0 Error(s)
Time Elapsed 00:00:01.41
[DEBUG] Skipping watched dependency update; build not configured with trigger: xxxxxxx #16
Finished: SUCCESS

clip_image004

Bueno problema resuelto, ahora tocara ver que se puede hacer para que compile en el .Net Framework 4.5 ya que cuando coloco uno de los proyectos como 4.5 obtengo este hermoso error…

C:WindowsMicrosoft.NETFrameworkv4.0.30319Microsoft.Common.targets(983,5): warning MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Espero que les sea de utilidad si por a o b tienen que usar un servidor de IC no hecho en .Net 😉