Mucho se habla de gestión de riesgos, ya sea en metodologías ágiles como en, cof cof, waterfall, y claro, mucho se colocan tablas y con una mayor o menor pericia se indican los impactos y probabilidades respectivas, hasta ahí "lo normal".

Lo usual es que por lo usual los criterios de experiencia que se toman están basados en el tipo de proyecto: ERP, almacén, web o desktop o también en el grado de complejidad del negocio, estado de las relaciones con el cliente, primera vez, time to market etc, nada fuera de lo habitual.

El problema es que muchas veces la visión "de negocio" logra opacar al criterio técnico en un factor muy importante: no todas las tecnologías tienen igual riesgo, y no, no me refiero al hecho de que por ejemplo un consultor de SAP cobre mas que un diseñador gráfico (llevándolo a extremos), sino que las diversas tecnologías tienen diferentes niveles de disponibilidad de recursos de aprendizaje, lo cual quieras que no, impacta en las previsiones que se requieren tomar para un proyecto.

En algunos casos es evidente que hay muchos mas recursos (ojo, en este blog nunca hablamos de personas como "recursos", ¿ok?) para SQL Server y Oracle que para Informix o Sybase, por lo cual el tiempo en que un equipo puede llegar a ser productivo en un proyecto con estas dos tecnologías "raras" es mayor, pero mal que bien se puede solventar con la experiencia previa en otros motores de base de datos, así que tenemos un riesgo ligeramente mayor, pero justificable.

Visto a este contexto debemos pasar a un diferente tipo de escenario, los frameworks o soluciones "listas para usar", productos que se espera que puedan ser usados directamente por un usuario final, "casi" sin necesidad de desarrollo, pero claro eventualmente terminan pidiendose personalizaciones y como la aplicación tiene una API en un lenguaje "conocido" como PHP, C# o Java pues se empieza el desarrollo tomando los mismo criterios que cualquier otro proyecto a medida y .. ahi empiezan los problemas.

En concreto estas aplicaciones (concretamente los CMS que son con los que he tenido experiencia) presentan dos problemas que los hacen "bestias" diferentes a cualquier desarrollo a medida:

1. Esfuerzo extra para configurar los entornos, tanto de desarrollo, como de producción, en el caso de SharePoint por ejemplo era muy complicado, tan así que no se podía trabajar contra un servidor compartido sino que cada desarrollador debía de tener una Maquina Virtual para tener un entorno de trabajo, todo lo cual involucraba un esfuerzo que no era trivial.
2. Cambio de paradigma respecto a como desarrollar y/o depurar, pues aquí no eres tu desarrollando una aplicación, estas intentando construir algo sobre los cimientos que alguien mas hizo, y que le puso reglas que pueden ser no usuales (y sobre todo contraintuitivas), pero necesarias para que el producto funcione, lo cual deriva en una necesidad de conocimiento (y tiempo de aprendizaje) mas allá de cuan experto uno crea ser en el lenguaje en cuestión.

Queda claro que estos dos factores tienen alta probabilidad de incidir sobre el tiempo que le puede tomar al equipo implementar la solución, por lo que seria un grave error asumir proyecciones sin tomar en cuenta el esfuerzo extra mencionado, si, es difícil acometer estas cosas que nos dejan productos como Magnolia, Vignette, o SharePoint, pero al final son retos técnicos que terminan siendo superados, a menos claro que la dirección asuma que ".net es .net" y no tome en cuenta detalles como estos en sus proyecciones, ahora que si a estas dos cosas, se le suma la poca experiencia local, o poca documentación actualizada en foros, asumimos grandes riesgos que no podemos dejar de informar de antemano, y créanme, en el caso de CMS (salvo que tengas miembros del equipo que actúen como pilares del resto) siempre pasa algo de lo mencionado, por lo que debemos estar alertas, regresando al titulo de este post, no todo tiene igual riesgo (técnico).

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.

Durante el año pasado tuve la oportunidad de ser revisor de el libro de Marcus Hammarberg y Joakim Sundén: Kanban in Action.

Fue una gran oportunidad el poder ver los borradores del libro, y desde el inicio me engancho con su enfoque, un primer capitulo destinado a demostrar como es posible (mediante la ayuda del equipo ficticio Kanbaneros), partiendo de la situación actual, implementar un flujo de Kanban en tu organización o proyecto de manera sencilla.

El resto del libro nos ayuda a ir comprendiendo la teoría detrás de Kanban (metricas, clases de servicio, planificación, etc), el porque es bueno tener controlado el Work In Process, recomendaciones y alternativas para cuando nos encontremos con situaciones particulares (una emergencia que debe ser solucionada de inmediato, por ejemplo), de una manera muy clara. Para lograr esto en todo momento los diversos Kanbaneros aparecerán con preguntas y conversaciones para clarificar los puntos.

Definitivamente recomiendo la lectura de este libro, pues como digo en mi comentario en la contraportada es "A practical way to start with kanban … and learn the theory along the way", lo unico que lamento del libro es que al final no se incluyo el capitulo de Scrumban o el detenerse un poco mas en utilizar Kanban en procesos iterativos como.. si.. Scrum.

Pues nada, si quieren tener una buena introducción a como empezar a usar Kanban les recomiendo leer el capitulo 1. Ademas nuestros amigos de Manning nos estan regalando el capitulo 13, con diversos juegos para aprender Kanban de manera divertida.

Desde hace dos semanas ha causado cierto revuelo en las comunidades de desarrollo este articulo de David Heinemeier Hansson, creador de Ruby on Rails, donde básicamente apunta que él seguirá usando Unit Test pero que TDD (entendido como programar los tests antes de codificar) ya esta muerto y que no tiene beneficios, de ahi me quedo con esta porción:

The current fanatical TDD experience leads to a primary focus on the unit tests, because those are the tests capable of driving the code design (the original justification for test-first).
I don't think that's healthy. Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.

Y si, se podría decir que había mucho de fanatismo en esto, expresiones como "código legado es código sin tests", "WebForms es malo pues pues no deja testear", "elabora una arquitectura evolutiva basada en tus tests" y similares estaban a la orden del día en blogs y conferencias, de hecho cuando publique este post sobre si los nuevos patrones (inducidos por TDD) ayudaban o no a la legibilidad del código un guru dijo que yo había "missed the point".

No se me entienda mal, yo creo que los tests son necesarios y salvadores de tiempo... en algunas circunstancias, por ejemplo hace un tiempo vi a un QA probar una aplicación que calculaba ciertos valores, para hacer esto iba a su Excel, copiaba los parámetros en la aplicación, y si la aplicación devolvía el valor esperado que estaba anotado en el Excel, estaba Ok, y claro, como es usual si la aplicación era actualizada, estos tests deberían ejecutarse de nuevo para verificar que no hubiera una regresión, este es un caso muy evidente como batería de Unit Test con diversas combinaciones de valores ayudaría a reducir los tiempos de prueba, garantizando la calidad de la aplicación en cuestión, como siempre digo, ¡si en una aplicación de cálculos matemáticos o financieros no le metes Unit Test no te puedes fiar de la calidad para nada!.

Personalmente creo que en este caso opero mucho el "principio de autoridad", eran pocas las voces quienes cuestionaban de que el modelo de TDD (y la compleja arquitectura a la que podria derivar) sea totalmente valido, y era necesario que alguien con cierto peso dijera "el emperador esta desnudo".

Como era de esperar, algunas respetadas voces han respondido al manifiesto de DHH, destacando Robert Martin con este articulo, y luego un debate online entre DHH, muy interesante.



Creo que el debate continuara un buen rato, pero lo bueno es que ha permitido que quienes teníamos reparos al fundamentalismo del TDD podamos salir de nuestros agujeros sin ser abucheados.

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.

En los últimos meses quienes trabajamos con tecnologías Microsoft, especialmente con TFS hemos sido arrastrados a una voragine de cambios que empezó con la herramienta Git-TF que permitia cierto grado de sincronización entre repositorios Git y TFS, pero eso fue solo el primer paso, luego vino el soporte nativo de Git en Team Foundation Service Visual Studio Online, el soporte a repositorios Git en un update a Visual Studio 2012, y ahora con Visual Studio 2013 y TFS 2013 la total integración entre Builds y repositorios Git.

Así que en los últimos meses hemos tenido que acercarnos a Git y experimentar con el, en ese sentido como primer punto de partida sugiero revisar los articulos de Eduard sobre el tema, pues nos permiten acercarnos a esta plataforma desde una perspectiva de quien ha trabajado en modo centralizado toda la vida.

Ahora bien, nuestro principal interés es tratar de seguir usando nuestras herramientas de TFS de toda la vida pero vinculado al nuevo repositorio, la buena noticia es que si, podemos tener lo mejor de ambos mundos, pero hay que tener unas consideraciones a fin de sacarle el máximo partido a nuestra nueva herramienta (Si aun dudas en usar Git, mejor lee a El Bruno) asi que aqui vamos:

• Los repositorios Git de Microsoft (TFS on premise y Visual Studio Online) cumplen totalmente las especificaciones de Git, en ese sentido puedes conectarte a tu repositorio no solo desde Visual Studio 2013 sino también desde una herramienta como SourceTree.
• El soporte de Visual Studio para los flujos de trabajo de Git (stash, rebase, etc) que tanto gustan a los veteranos de Git aun esta en progreso, en ese sentido nunca viene de mas poder tener un SourceTree a la mano configurado para conectarse a nuestro repositorio, si, funciona perfectamente.
• Cuando te conectas a un Team Project con Git, se te ofrece la opción de clonar el repositorio a fin de poder empezar a trabajar, lo cual crea un repositorio Git local, y dentro de este repositorio el archivo \.git\config queda apuntando a la ruta del repositorio online (en el caso de VSO la ruta tiene la forma de https://midominio.visualstudio.com/DefaultCollection/_git/MiTeamProject), todo bien hasta ahi, pero si por alguna razón queremos cambiar de repositorio remoto tendremos que recurrir a la edición manual del archivo en cuestión (o usar SourceTree).
• Ya que hablo de usar linea de comandos y/o otra herramienta cabe indicar que hay que configurar nuestra cuenta de VSO para poder conectarse transparentemente a entornos diferentes a Visual Studio, para ello nos vamos a la esquina superior derecha de nuestro portal de VSO, elegimos nuestro nombre
  
  Le damos a "My profile"
  
  y veremos que tenemos un nombre de usuario primario en formato "email" que es el que usamos para conectarnos al portal de VSO, pues bien lo que toca es crear un nombre de usuario secundario (que NO debe tener formato email) el cual sera el que usemos cuando intentemos conectarnos con linea de comandos o SourceTree.
• Como mencionaba lineas arriba Visual Studio reconoce directamente la configuración Git estandar, en ese sentido es perfectamente posible agregar un repositorio remoto adicional a nuestro archivo \.git\config (en este caso un repositorio GitHub), o via SourceTree:
  
  quedando de la siguiente manera:
  
  [core]
  bare = false
  repositoryformatversion = 0
  filemode = false
  logallrefupdates = true
  symlinks = false
  ignorecase = true
  [remote "origin"]
  url = https://xxxxxxx.visualstudio.com/defaultcollection/_git/Applicat%C3%B3n
  fetch = +refs/heads/*:refs/remotes/origin/*
  [branch "master"]
  remote = origin
  merge = refs/heads/master
  [remote "Github"]
  url = https://github.com/fisica3/Applicaton
  fetch = +refs/heads/*:refs/remotes/Github/*
  
  Ocurrido esto, cuando sincronizemos nuestros cambios desde Visual Studio, se efectuara una sincronización simultanea a ambos repositorios remotos, lo cual puede venir muy bien en ciertos entornos, pero lamentablemente por ahora no tendremos la opción de elegir cuando hacer los sync por separado, seran en simultaneo.
• Otro detalle de cuando tenemos mas de un repositorio remoto configurado en nuestro repositorio local: hay que tener cuidado pues si tenemos alguna Build Definition basada en Integración Continua esta puede no dispararse, tratare de encontrar una solución para evitar este problema, pero de momento hay esa pequeña limitante.

Pues nada, espero que estas consideraciones sobre Git en nuestro Visual Studio sean utiles para empezar a sacarle partido y empezar a trabajar, confio que en los proximos updates Microsoft mejorara el IDE para soportar flujos mas avanzados, pero de momento ya tenemos todo para empezar a trabajar, asi que si no has sacado tu cuenta en Visual Studio Online hazlo ya!.

Si tienes una duda no dejes de comentar y preguntarme.

Bueno, ya son poco mas de 3 años usando Windows 7, así que como esencialmente me dedico a trabajar con tecnologías Microsoft el migrar a Windows 8 es un paso que eventualmente tendré que dar, por lo que faltando dos días para el vencimiento de la oferta decidí comprar el Windows 8 Pro a 40$, si no lo hiciste hasta el 31 de Enero, lastima, ahora toca desembolsar 160$.
Siendo que la disponibilidad del software ya no es un problema, toca hacer un planeamiento de los pasos necesarios antes de hacer la migración, saltando dos esencialmente:
- ¿Mi equipo actual aguantara Windows 8? Como comente la última vez (el 2009) que hice un gran cambio de hardware actualmente tengo la Asus P5E WS Pro, con un procesador Core2Duo de 2.13, siendo que a poco de regresar a Perú (si! Estoy usando la misma compu que tenía en España!) le puse 8GB de RAM en vez de los 4 que ya tenía. Oficialmente esta configuración sobrepasa los requisitos mínimos para la instalación de Windows 8 (*) por lo que no debería tener problemas, pero lamentablemente las pruebas de upgrade sobre Core2Duo se han hecho sobre chip de 2.6Ghz, por lo que los datos de performance no aplican totalmente para mi.
En ese sentido (con un procesador de mas de 6 años) se impone un upgrade de hardware, siendo la duda el si lo hare antes o después de instalar Windows 8, se supone que no debería haber diferencia, excepto a que no se si luego de cambiar la placa tendré que Activar Windows nuevamente, y de ser así, si estaré permitido de hacerlo o no, queda para la reflexión.
- En todo caso una duda que tenía desde que se anunciaron las primeras versiones de prueba de Windows 8 era sobre el destino del Windows XP Mode (en simple: una máquina Virtual de XP muy integrada con Windows 7), siendo que el soporte de Windows XP acaba el 2014 y que W8 retira a MS Virtual PC para adoptar la tecnología Hyper-V (existente desde Windows 2008 Server) Microsoft decidió descontinuar Windows XP Mode ofreciendo como única alternativa el poder recuperar los datos que hubiera en las Maquina Virtual existentes, y es aquí lo que me plantea el reto de tener algo listo para poder seguir corriendo mi Máquina Virtual y sus aplicaciones (y no solo acceder a sus archivos) cuando tenga Windows 8 instalado, y es en esto en lo que me enfocare en este post.
Repasemos el escenario, tengo un disco duro virtual VHD de 30GB Gigabytes+/-, el cual actualmente corre sin problemas en mi instalación de Virtual PC, este disco duro no podrá ser “levantado” por Hyper-V por lo que la alternativa es intentar correrlo en otro motor de virtualización, en mi caso particular he optado por VirtualBox, el cual debe instalarse previamente si es que no lo has hecho ya..

Al investigar en Internet me he enterado con dos problemas bloqueantes para lograr dicho propósito (que luego pude corroborar):
- Al intentar levantar el disco VHD desde Virtual Box se me informa que falta un disco maestro, upss
- Si de alguna manera se logra levantar la máquina virtual en Virtual Box, nomás iniciar sesión se requiere Activar la máquina virtual, esto debido a que ese Windows XP detecta que el BIOS de VirtualBox es diferente de Virtual PC, por lo que las alternativas en teoría son dos: usar una clave de Windows XP (hay una que viene con la instalación de XP Mode) para intentar la activación o hacer que la máquina virtual crea que el BIOS es el mismo, en concreto la única alternativa es la segunda, así que ni se esfuercen en intentarlo y vayamos a lo seguro, que es de lo que trata esta guía.

Advertencia: Llegados a este punto debo indicar que en algunos foros se comenta que bajo Windows 8 ya no tenemos la licencia para ejecutar XP Mode, que esta solo es válida bajo Windows 7, así que habrá que estar atentos a lo que diga Microsoft de manera oficial al respecto, pero en ese sentido lo que mas me preocupa es que para el 2014 ya se acaba oficialmente el ciclo de vida de Windows XP.
Como medida de seguridad es imprescindible copiar el archivo del disco duro virtual ( .vhd) a un lugar seguro por si por a o b algo nos sale mal; hecho esto nuestro primer paso es crear un nuevo disco duro virtual que si pueda ser levantado por VirtualBox, para lograr esto debemos iniciar nuestro XP Mode y una vez dentro instalar y ejecutar el Disk2VHD, este programa nos permitirá crear un disco duro virtual “sin problemas”, como se ve en el gráfico.

Nótese que el nuevo archivo lo estamos creando en una ruta \\tsclient\d\... que es la ruta mediante la cual podemos acceder desde nuestra maquina a los archivos y unidades alojados dentro de la maquina anfitriona (nuestro Windows 7) , en esta etapa sugeriría que antes de iniciar el proceso se desinstale los componentes de integración (Virtual PC Integration Components) pues harán algo complicado el proceso de inicio en su nuevo sistema anfitrión, en mi caso no lo hice aunque al final todo quedo bien como comentare luego.
Este proceso puede tomar como 20 minutos o mas, no hay problema, podemos esperar.
Ya con el nuevo disco duro virtual (oh sorpresa, pesa solo 15GB en comparacion de los 30 del original!) procedemos a crear la máquina virtual desde VirtualBox, nótese que debemos indicarle que vamos a hacer uso de un disco duro ya existente.

 IMPORTANTE: una vez creada la máquina virtual no iniciarla aun.

Bueno, ya tenemos la máquina virtual creada, ahora lo que toca es preparar nuestro VirtualBox para que provea a nuestra Maquina Virtual con un Bios compatible con Virtual PC, para esto debemos bajar este archivo, desempaquetarlo y ejecutar esto en una línea de comandos con privilegios administrativos:
VBoxManage.exe setextradata el-nombre-de-tu-mv "VBoxInternal/Devices/pcbios/0/Config/BiosRom" "c:\vmlite-bios\pcbios.bin" (en lugar de C:\vmlite-bios... usar la ruta donde se haya desempaquetado el archivo pcbios.bin)

Y listo… ahora si podemos iniciar nuestra máquina virtual, en este punto deberemos (si no lo hicimos desde Virtual PC) desinstalar las extensiones de integración de Microsoft para poder instalar las que nos provee VirtualBox, esto podrá requerir algunos reinicios hasta que quede estable, pero como ven ya tengo básicamente bajo VirtualBox la misma Maquina Virtual que tenia bajo Virtual PC.

Espero que esto haya sido de utilidad para poder seguir trabajando con nuestras máquinas virtuales de Windows XP Mode bajo VirtualBox y por ende luego bajo Windows 8.
Referencias:
TOPIC: VMLite XP Mode Plugin for VirtualBox and Virtutal Box 4.0
Windows XP Mode for VirtualBox 4
(*) se supone que si una maquina corre W7 deberia correr Windows 8 igual o ligeramente mejor.

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.

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

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)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.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

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:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.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 ;)