Categoría: Visual Studio Online

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

Posted on by ecardenas

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)

Consideraciones al usar Git con Visual Studio y TFS 2013

Posted on by ecardenas

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 .gitconfig 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 .gitconfig (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.