martes, 15 de abril de 2014
by Ernesto
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:
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.
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.
viernes, 20 de diciembre de 2013
by Ernesto
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:
Si tienes una duda no dejes de comentar y preguntarme.
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.
Si tienes una duda no dejes de comentar y preguntarme.
domingo, 10 de febrero de 2013
by Ernesto
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.
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.
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.
viernes, 1 de febrero de 2013
by Ernesto
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:
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!
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…
Espero que les sea de utilidad si por a o b tienen que usar un servidor de IC no hecho en .Net ;)
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 ;)
by Ernesto
Si algo se me ha pasado es compartir esta presentación con la que introduje Team Foundation Service en el ultimo Agile Open Lima, así como a algunos compañeros de trabajo
En este tiempo lo que ha cambiado es que TFS ya es RTM, por lo cual ahora si que se tienen los planes de licenciamiento, y algo muy interesante, ahora esta integrado con GIT. No queda sino animarlos a probar Team Foundation Service, el cual es gratis para equipos de hasta 5 personas y por supuesto seguir los blogs de El Bruno y Jersson, que siempre nos estan informando novedades sobre esta potente herramienta.
En este tiempo lo que ha cambiado es que TFS ya es RTM, por lo cual ahora si que se tienen los planes de licenciamiento, y algo muy interesante, ahora esta integrado con GIT. No queda sino animarlos a probar Team Foundation Service, el cual es gratis para equipos de hasta 5 personas y por supuesto seguir los blogs de El Bruno y Jersson, que siempre nos estan informando novedades sobre esta potente herramienta.
miércoles, 26 de septiembre de 2012
by Ernesto
Todo esto empezó cuando publique este twitt:
Era una idea que me había estado dando vueltas por la cabeza desde hace tiempo, y mas cuando en reuniones con la persona a cargo de un proyecto (a la que trataba de introducir en las bases de las metodologías ágiles) hacia referencias a que "en el proyecto se necesita mas recursos de nivel X y no de nivel Y" "tenemos que estimar la capacidad de los recursos disponibles", y claro el uso de ese lenguaje me repateaba (al margen del convencimiento de que se podría tener una estimación confiable "desde arriba" pero esa es otra historia) ya que como se ha conversado en varios sitios el llamar "recurso" a una persona equivale a cosificarlo, a ponerlo a nivel de una maquinaria o herramienta.
Era una idea que me había estado dando vueltas por la cabeza desde hace tiempo, y mas cuando en reuniones con la persona a cargo de un proyecto (a la que trataba de introducir en las bases de las metodologías ágiles) hacia referencias a que "en el proyecto se necesita mas recursos de nivel X y no de nivel Y" "tenemos que estimar la capacidad de los recursos disponibles", y claro el uso de ese lenguaje me repateaba (al margen del convencimiento de que se podría tener una estimación confiable "desde arriba" pero esa es otra historia) ya que como se ha conversado en varios sitios el llamar "recurso" a una persona equivale a cosificarlo, a ponerlo a nivel de una maquinaria o herramienta.
Y esa deshumanización del personal tiene de la mano no solo el aspecto de valorar a la persona como algo prescindible y fácilmente reemplazable, sino una visión errónea que puede a llegar a inducir que conceptos como el de "pool de programadores" son validos, que si que se nos dirá que la visión de negocio es tratar de reducir los costos fijos y moverse con costos variables, que con una adecuada metodología se puede dar una documentación que fácilmente puede ser convertida en código útil, etc, etc.. lo cual a estas alturas del partido deberíamos tener claro que es un engañamuchachos.
Entonces... ¿a que debemos tender? la respuesta nos la da el Manifiesto Agil en uno de sus items: "Individuos e interacciones sobre procesos y herramientas" (recordemos que llamar a la persona "recurso" lo pone a nivel de una herramienta), siendo asi a lo que debemos apuntar es tender a la construcción de equipos y mejorar la capacidad de estos y claro esta la colaboración entre sus miembros, así que podríamos hablar de "el equipo A tiene que ser reforzado en ...." "la performance del equipo se ha mantenido...", y claro no olvidarse que los miembros de los equipos son personas, con sus habilidades y debilidades, no una maquinaria.
Como anécdota en cuanto a un uso del lenguaje, me acuerdo de cuando mi empleo de entonces me subcontrato a un consultora mucho mas grande, entonces la responsable de RRHH tenia que darme instrucciones para iniciar mis labores en el cliente y me dijo "tendrás que hablar con XXX del Departamento de Compras.... si.. suena fatal", es que si, suena fatal que el trato con la gente que va a colaborar en un proyecto de responsabilidad sea caracterizador al igual que.... ¿las sillas?
Pero al pensar en este caso me acorde de otro escenario de cuando el lenguaje utilizado traslada algo detrás que podría ser contraproducente de cara a la cohesión de los equipos, no fue así el caso pero creo que se corrió un riesgo y desaprovecho una oportunidad, me explico: como ya he comentado lo usual para los informáticos es no ser considerado como core dentro de las organizaciones, siendo que la mayoría de los desarrollos se encargan a terceras empresas (con dispar resultado, la verdad sea dicha, pues bien.... cuando una vez me toco trabajar directamente para una "empresa cliente final" (el santo grial de los informáticos en España) me llamo la atención como el responsable del proyecto nos motivaba haciendo alusión al "cliente" y como había que tenerlo contento, lo cual si bien podría transmitir cierta deformación profesional, no dejaba de ser una oportunidad perdida para hacer que el equipo se sintiera mas parte de la cadena de valor del negocio y por ende mas identificado y comprometido con los resultados, motivación que puede estarse perdiendo cuando en las grandes empresas se pasa a ver que tu trabajo ya no es tu trabajo sino tu cliente.
Así que nada es casualidad, aun el uso inconsciente de ciertas formas del lenguaje tiene un significado detrás que debe valorarse para lograr lo mejor posible de los equipos.
martes, 7 de agosto de 2012
by Ernesto
- Team Foundation Service: Gestionando nuestro proyecto ágil desde la nube!
- Conversatorio: ¿Mi cliente (o proveedor) esta en el otro lado del mundo! ¿Que hago?
Sobre la segunda charla, intentare replicar un estilo "reality show" que pude ver en acción por parte del maestro Angel Medinilla en el Agile Open Spain del 2009, compartiendo las experiencias que hayamos tenido trabajando con equipos distribuidos, ya sea como cliente o como proveedor, en un momento en que el desarrollo de proyectos offshore esta creciendo en nuestro país, sera algo muy interesante para ver como mejoramos nuestra forma de desarrollar esta clase de proyectos desde un enfoque agil.
Así pues cuento con ustedes en este nuevo Agile Open Lima y en particular con sus votos para poder llevar a cabo estas sesiones :), ¡nos vemos en Ñaña!!.
martes, 17 de julio de 2012
by Ernesto
He estado pensando en escribir este post desde hace unas semanas cuando empecé una reflexión sobre que tan rígidos somos (o debemos ser) al intentar aplicar metodologías agiles, y todo empezó con este dialogo con un amigo que trabaja fuera de Perú:
Amigo: tudo bem?
Yo: tranqui...tratando de introducir Scrum por aqui...
Amigo: estas mismo scrum master? aca estamos en la iteracion 18
Yo: estoy mas bien haciendo coaching, explicando a la gente y tratando de armar nuestro tablerito
Amigo: revisa vxzs111.com ahora y vuelve en junio.... y me das los comentarios de los cambios q ves.
Yo: ok
Amigo: va a haber una nueva version del website
Yo: ese es tu cliente?
Amigo: oui
Yo: ook
y... usan planning poker para estimar?
Amigo: no idea....
hay jefes de proyecto en varios niveles....no se como hacen sus pronosticos del tiempo.
Yo: pero ... hacen retrospectivas?
Yo: me refiero, retrospectivas a nivel de equipo
Amigo: t refieres a feedback?
Yo: luego de cada sprint el equipo se reúne y dice como le ha ido y como se puede mejorar
Amigo: no hay psicología, siempre adelante.
lo q tu dices es la teoria
Yo: uhmm.... entonces no estan aplicando scrum
hacen daily meetings frente al tablero?
Amigo: bueno... antes habia tu mini reunion casi diaria,con tu tablero eetc etc luego se fueron espaciando, y espaciando. hasta todos los viernes
Yo: entonces dejaron de hacer scrum y estan aplicando algo iterativo
Amigo: pero en todo caso... todo desarrollo estaba en un solo lugar.
bueno, es un scrum flexible....o como lo quieras llamar, para un purista, no aplica
Yo: pero... alguna vez el equipo hizo retrospectiva? veamos... hay cosas en q si puedes ceder y cosas en que no...las reuniones y retrospectivas son mandatorias. claro q tambien es cierto q la regla de "nada interrumpe" al sprint a veces tiene que saberse gestionar si hay q corregir cosas de emergencia
Amigo: la negociacion de q se hace o q no se hace... eran del jp con el cliente, ahora... tu puedes indicar cuanto t puede tomar....y en base a eso el jp... trata de decir si va o no va... o si va, cuanto les va a costar.
Yo: veamos.... se negocia el orden del backlog y siempre hay repriorizaciones...
Amigo: para eso esta el jp
Yo: veamos... tu JP esta fungiendo de Scrum Master o Product Owner?
Amigo: hay un jp de desarrollo, hay otro jp, sobre el jp de desarrollo, y el cliente, tiene otros jp
Yo: de acuerdo... pero esos cargos como se mapean hacia los roles q plantea Scrum?
Amigo: desde el punto de desarrollo, el product owner es el jp de desarrollo, el prioriza en gral. q se hace...etc
el jp, del jp de desarrollo, seria el scrumMaster... mas politico, no tecnico.
Yo: ok
Amigo: y ademas hay una asistente de este ultimo, (que me parece jp en formacion)
Yo: y una vez q han definido el alcance del sprint... este permanece inamobible?
Amigo: todo depende del jp de desarrollo....el evalua en que casos se pueden hacer cambios
Yo: uhmm... los cambios deben hacerse al pasar de un sprint a otro, existen excepciones.. cuando hay q apagar un incendio....
Amigo: no hay nada q hacer.... q eres un purista
Purista…. esa es la palabra que se me quedo grabada, y me puse a pensar que si todo lo que le estaba “reclamando” a mi amigo era efectivamente purismo, o simplemente el querer establecer unos minimos respecto a como trabajar de manera agil.
Entonces tratemos de imaginar los contextos que pueden derivar a querer aplicar "Scrum" en un proyecto:
Adaptar... interesante, valido y a la vez arriesgado, hace pocas semanas un JP me indicaba "uno no tiene porque amarrarse a una metodología, sino coger lo mejor de cada una y adaptarlo a la realidad de la organización", lo cual tendría todo el sentido del mundo si detrás de ello hay un respeto a la filosofía base, respeto que llevaría a entender el porque los artefactos de Scrum son importantes: las reuniones diarias porque así se da prioridad a las personas e interacciones sobre los procesos y herramientas, el backlog como mecanismo que facilita la respuesta al cambio y la colaboración con el cliente. Es que claro, conceptos de "equipos autoorganizados" o "propiedad colectiva" del código son difíciles de aterrizar en ciertas jefaturas, pero el resto es tratar de llegar a ellos y emprender ese camino.
Como es evidente, poco de eso ha sido tomado en cuenta en esta implementación de Scrum, quedando solo las iteraciones, pero lo peor es que no ha sido asimilado por el Equipo, el cual puede llegar a ver todo lo demás como "purista", y si, caer en el purismo a rajatabla es un riesgo, por lo cual hay cosas que se pueden ajustar en cierto punto como el mapeo de roles a algo mas cercano a la realidad organizacional,
Ahora bien, esto de querer ser ágil (o implementar Scrum, o ya puestos... Kanban) no es un destino al cual llegar rápidamente, sino un camino de largo plazo en el cual las tentaciones de salir están a la vuelta de la esquina, pero de nuevo... lo importante es asumir la filosofía que esta detrás, y sobre todo no hacer las cosas de golpe, aplicar "baby steps" como nos recuerda Hiroshi; que si, que no sera Scrum lo que se tenga en un primer momento, pero si queremos aplicar mejora continua e involucramos al equipo (no, no se puede ser ágil con una imposición vertical de tareas) en llegar a un objetivo (de nuevo, propiedad colectiva del código, escuchar y no imponer plazos, etc), se lograra la meta y ahí si se podrá presumir de Scrum y de agilismo.
Y de nuevo, el purismo tampoco es la respuesta, en ese sentido me gusta mucho el ejemplo que da Angel Medinilla en un escenario de Scrumban, si, una mezcla pragmatica de Scrum y Kanban pero que era necesaria debido a la realidad del equipo/proyecto (leerlo, es imprescindible) pero que gracias al equipo se logra sacar lo mejor de la situación para lidiar con un escenario en el que no era posible cumplir lo exigido por Scrum de "nada interrumpe el Sprint".
Entonces, queda claro que si bien la evolución hacia el agilismo involucra concesiones temporales, ese tradeoff no debe darse en nada que sacrifique el que el equipo "compre" la idea y abrace el cambio y entre eso están elementos claves como: daily meeting, retrospectivas, backlog visible.... lo cual lamentablemente no era el caso de mi amigo por mas que lo llamara "scrum flexible".
Amigo: tudo bem?
Yo: tranqui...tratando de introducir Scrum por aqui...
Amigo: estas mismo scrum master? aca estamos en la iteracion 18
Yo: estoy mas bien haciendo coaching, explicando a la gente y tratando de armar nuestro tablerito
Amigo: revisa vxzs111.com ahora y vuelve en junio.... y me das los comentarios de los cambios q ves.
Yo: ok
Amigo: va a haber una nueva version del website
Yo: ese es tu cliente?
Amigo: oui
Yo: ook
y... usan planning poker para estimar?
Amigo: no idea....
hay jefes de proyecto en varios niveles....no se como hacen sus pronosticos del tiempo.
Yo: pero ... hacen retrospectivas?
| Amigo: no tengo vision global |
Amigo: t refieres a feedback?
Yo: luego de cada sprint el equipo se reúne y dice como le ha ido y como se puede mejorar
Amigo: no hay psicología, siempre adelante.
lo q tu dices es la teoria
Yo: uhmm.... entonces no estan aplicando scrum
hacen daily meetings frente al tablero?
Amigo: bueno... antes habia tu mini reunion casi diaria,con tu tablero eetc etc luego se fueron espaciando, y espaciando. hasta todos los viernes
Yo: entonces dejaron de hacer scrum y estan aplicando algo iterativo
Amigo: pero en todo caso... todo desarrollo estaba en un solo lugar.
bueno, es un scrum flexible....o como lo quieras llamar, para un purista, no aplica
Yo: pero... alguna vez el equipo hizo retrospectiva? veamos... hay cosas en q si puedes ceder y cosas en que no...las reuniones y retrospectivas son mandatorias. claro q tambien es cierto q la regla de "nada interrumpe" al sprint a veces tiene que saberse gestionar si hay q corregir cosas de emergencia
Amigo: la negociacion de q se hace o q no se hace... eran del jp con el cliente, ahora... tu puedes indicar cuanto t puede tomar....y en base a eso el jp... trata de decir si va o no va... o si va, cuanto les va a costar.
Yo: veamos.... se negocia el orden del backlog y siempre hay repriorizaciones...
Amigo: para eso esta el jp
Yo: veamos... tu JP esta fungiendo de Scrum Master o Product Owner?
Amigo: hay un jp de desarrollo, hay otro jp, sobre el jp de desarrollo, y el cliente, tiene otros jp
Yo: de acuerdo... pero esos cargos como se mapean hacia los roles q plantea Scrum?
Amigo: desde el punto de desarrollo, el product owner es el jp de desarrollo, el prioriza en gral. q se hace...etc
el jp, del jp de desarrollo, seria el scrumMaster... mas politico, no tecnico.
Yo: ok
Amigo: y ademas hay una asistente de este ultimo, (que me parece jp en formacion)
Yo: y una vez q han definido el alcance del sprint... este permanece inamobible?
Amigo: todo depende del jp de desarrollo....el evalua en que casos se pueden hacer cambios
Yo: uhmm... los cambios deben hacerse al pasar de un sprint a otro, existen excepciones.. cuando hay q apagar un incendio....
Amigo: no hay nada q hacer.... q eres un purista
Purista…. esa es la palabra que se me quedo grabada, y me puse a pensar que si todo lo que le estaba “reclamando” a mi amigo era efectivamente purismo, o simplemente el querer establecer unos minimos respecto a como trabajar de manera agil.
Entonces tratemos de imaginar los contextos que pueden derivar a querer aplicar "Scrum" en un proyecto:
- Queda bien de cara al mercado decir que se usa
- Hay una necesidad de mejorar la manera de hacer software (problemas de tiempos, alcance, calidad o todo junto)
- Se escucho en alguna conferencia y se decidió ir por ello, o algún "guru" que paso por ahí lo recomendó
- Se desea mejorar la organización y se pensó que Scrum seria un buen componente dentro de ese proceso
Adaptar... interesante, valido y a la vez arriesgado, hace pocas semanas un JP me indicaba "uno no tiene porque amarrarse a una metodología, sino coger lo mejor de cada una y adaptarlo a la realidad de la organización", lo cual tendría todo el sentido del mundo si detrás de ello hay un respeto a la filosofía base, respeto que llevaría a entender el porque los artefactos de Scrum son importantes: las reuniones diarias porque así se da prioridad a las personas e interacciones sobre los procesos y herramientas, el backlog como mecanismo que facilita la respuesta al cambio y la colaboración con el cliente. Es que claro, conceptos de "equipos autoorganizados" o "propiedad colectiva" del código son difíciles de aterrizar en ciertas jefaturas, pero el resto es tratar de llegar a ellos y emprender ese camino.
Ahora bien, esto de querer ser ágil (o implementar Scrum, o ya puestos... Kanban) no es un destino al cual llegar rápidamente, sino un camino de largo plazo en el cual las tentaciones de salir están a la vuelta de la esquina, pero de nuevo... lo importante es asumir la filosofía que esta detrás, y sobre todo no hacer las cosas de golpe, aplicar "baby steps" como nos recuerda Hiroshi; que si, que no sera Scrum lo que se tenga en un primer momento, pero si queremos aplicar mejora continua e involucramos al equipo (no, no se puede ser ágil con una imposición vertical de tareas) en llegar a un objetivo (de nuevo, propiedad colectiva del código, escuchar y no imponer plazos, etc), se lograra la meta y ahí si se podrá presumir de Scrum y de agilismo.
Y de nuevo, el purismo tampoco es la respuesta, en ese sentido me gusta mucho el ejemplo que da Angel Medinilla en un escenario de Scrumban, si, una mezcla pragmatica de Scrum y Kanban pero que era necesaria debido a la realidad del equipo/proyecto (leerlo, es imprescindible) pero que gracias al equipo se logra sacar lo mejor de la situación para lidiar con un escenario en el que no era posible cumplir lo exigido por Scrum de "nada interrumpe el Sprint".
Entonces, queda claro que si bien la evolución hacia el agilismo involucra concesiones temporales, ese tradeoff no debe darse en nada que sacrifique el que el equipo "compre" la idea y abrace el cambio y entre eso están elementos claves como: daily meeting, retrospectivas, backlog visible.... lo cual lamentablemente no era el caso de mi amigo por mas que lo llamara "scrum flexible".
About Me
- Ernesto
- Egresado de Ingenieria Informatica de la PUCP. Master en Direccion de Sistemas y Tecnologias de la Informacion por el Instituto de Empresa. MCSD,MCSD.NET.
Technorati
