Introducción a Angular 2

Hace unas semanas estuve dando, Junto con @nicotourne,  un curso de Introducción a Angular en la UNICEN como propuesta de seminario para la Tecnicatura Universitaria en Desarrollo de Aplicaciones Informáticas.

El curso estuvo bueno y tuvimos  una muy buena retrospectiva al terminarlo, como para poder mejorar en la próxima iteración.

La idea de este post es comentar algunos highlights que descubrí en clases y compartir el material.

Alumnos del Curso

Material

El material esta basado en un ejemplo de una app de una Cervecería. La home page tiene una lista de cervezas y un carrito de compras. Durante las clases fuimos construyendo la lista de cervezas, explicando a la par los conceptos de Angular.

Los temas fueron:

• Introducción
• Components
• Directives & Pipes
• Mocks, Models & Property Binding
• Event binding & 2 Ways Data Binding
• Services & Dependency Injection
• Routing
• Communication Between Components

Algo que sumamos, es un branch de cada slide en el repositorio de GitHub para que los alumnos puedan ver qué cambios se van haciendo con cada nuevo concepto.

También durante la clase @nicotourne, fue aportando todo su conocimiento de Angular en producción, dando tips de buenas prácticas y detalles a tener en cuenta cuando hacemos una app un poco mas grande.

Trabajo Final

El trabajo fue agregar algunas features al proyecto:

• Filtrado en la tabla de cervezas.
• Hacer un componente que consuma la API de AccuWeather y muestre el clima de Tandil.
• Agregar un botón que guarde la compra en Firebase
• Hacer un componente de Contacto que guarde los mensajes en Firebase.
• Agregar la opción de Agregar Cervezas a la lista.

Highlights

La dinámica de la clase

Dar clases, siguiendo las slides, codeando la solución en vivo en el proyector y que los alumnos puedan seguirlo e ir haciendolo en sus computadoras.

Esto nos permite tener feedback de los alumnos en el momento, validar si se entendió el concepto o no. En base a esto podemos volver a explicar o avanzar con el siguiente concepto.

Branches con las soluciones

En la retrospectiva surgió, como algo muy bueno, poder acceder a solo la porción de código de ese juego de slides. Los alumnos pudieron usarlo para encontrar más rápidamente la solución a los problemas que les surgían en el trabajo final.

Trabajo final, Fork y Pull Requests

Para el trabajo final, los alumnos tuvieron que hacer un Fork del repositorio del curso y al terminar postear el PR.

Esto nos ayudo a corregir mas rápido, y poder agregar comentarios en el mismo código, aprovechando esto como una instancia más de aprendizaje.

Firebase

Wow! Que buenas cosas que están haciendo con Firebase en Google. Agregarlo al curso fue una excusa para aprender un poquito de esta plataforma. Sin dudas es para seguir aprendiendo y usándolo en otros cursos/seminarios o en la materia Web.

A los alumnos les sirvió para ver como una plataforma, que tiene una interfaz REST, es muy fácil de integrar.

Recibida de la primer alumna de TUDAI

Con la finalización de este curso Lucre, fue la primer graduada de la carrera, así que los compañeros y familia aprovecharon a hacer el clásico ritual de tirarle «Con de Todo». Felicitaciones Lucre!

Comentarios, ideas, Pull Requests, etc. son más que bienvenidos!

Travis CI – Integración Continua fácil!

 

Hace poco estuve trabajando en un proyecto en Ruby, el cual tenía configurado Travis como servicio de integración continua.

Me llamo muchísimo la atención lo sencilla que es la configuración y la buena documentación que tiene. Con un simple archivo .yml y unas pocas líneas tenemos configurado nuestro servidor de integración continua, que incluso puede correr nuestra suite de tests en diferentes versiones de Ruby paralelamente.

Travis tiene soporte para multiples lenguajes, yo solo lo probé con Ruby, pero estoy seguro que voy a seguir haciendo algunas pruebas más con algún otro lenguaje como PHP, C# o Go.

Una última característica genial es que es gratis para proyectos Open Source.

Como funciona Travis CI

Tenemos que tener una cuenta de Github y entrar a travis-ci.org. Autorizamos a Travis a acceder a nuestros repositorios y voilà todo listo.

Los pasos a seguir son:

• Seleccionar el repositorio que queremos, haciendo click el botón que lo habilita.
• Subir a nuestro repositorio el archivo .travis.yml con la configuración.
• Hacemos un push a nuestro repositorio y automáticamente se ejecuta el primer build.

Travis.yml

Vamos a usar un ejemplo de un proyecto en Ruby.

	language: ruby
	sudo: false
	cache: bundler
	rvm:
	– 2.1.0
	– 2.2.1
	before_script:
	– chmod +x build_travis.sh
	script: "./build_travis.sh"

view raw

travis.yml

hosted with ❤ by GitHub

Como ven la configuración es sencilla, con las palabras claves nos damos cuenta que significa:

language: Es el lenguaje en el que esta escrita nuestra app. Ejemplo: ruby, go, rust, scala, etc.

sudo: Si vamos a ejecutar la suite como super usuarios. En nuestro caso vamos a hacerlo como usuarios normales.

cache: Los que programamos en Ruby sabemos que hacer un bundle install suele tardar un buen rato, es por eso que con esta opción, podemos tener el cache de la instalación de bundler hasta que nuestro Gemfile cambie, acelerando la ejecución de nuestros tests.

rvm: Esta opción nos permite tener diferentes versiones del lenguaje contra las cuales queremos probar nuestro código. Algo muy bueno de esto, en caso de usar Ruby, es que podemos probar nuestro código contra versiones de jRuby y con diferentes JDKs.

before_script: Podemos ejecutar comandos antes de ejecutar el script de build. En este ejemplo estoy dándole permisos de ejecución al script que va a correr mi build.

script: Es el script (o comandos) para ejecutar el build. En este caso arme un script de bash que contiene solo una linea bundle exec rake spec. Podría incluso escribir esta linea en el este archivo sin necesidad de llamar a un script para hacerlo.

Hay bastante mas posibilidades de configuración y de hacer cosas con Travis, pero en este post pretendo cubrir solo el escenario de correr una suite de test de Rspec.

Configuraciones en la aplicación

Haciendo click en More Options -> Settings accedemos a las configuraciones de Travis.

Podemos ver que tenemos activado el build con cada push a nuestro repositorio. Si nosotros hacemos un push a master o cualquier branch, Travis va a detectarlo y ejecutar un build.

También vemos que esta activado el build pull request. Esta característica es muy útil, ya que podemos estar trabajando en una algo nuevo, enviamos un PR para que nos revisen el código, y podemos asegurarnos que el código que vamos a mergear esta ‘Verde’ y no va a romper el build.

Vemos también una configuración de limitar jobs concurrentes. Esto nos sirve cuando tenemos tests de integración y estamos accediendo a la misma base de datos o API. No podemos ejecutar tests concurrentemente ya que los datos de prueba no serían consistentes. En este ejemplo no hay necesidad de limitar esto, ya que estoy buildeando una aplicación sencilla de una calculadora.

Por ultimo, si prestamos atención abajo de los botones están las Environment Variables. Estas variables las podemos configurar en el archivo .travis.yml, pero podemos también podemos configurarlas aquí. Podríamos poner en estas variables una conexión a una base de datos o alguna configuración del ambiente. Si es información sensible podemos ocultarla simplemente haciendo que la información no se muestre en el log con el botón al lado de la carga de la variable.

Esta del build en README.md

Un último detalle es que cuando usamos Travis, podemos tener el estado de nuestro build en nuestro repositorio.

Para eso podemos agregar al README.md la línea que nos da travis cuando hacemos click en el estado de nuestro build y seleccionamos Markdown como se puede ver en la siguiente imagen.

Con lo sencillo que es configurar Travis y si estas haciendo un proyecto open source, ya no hay mas excusas para no tener integración continua.

 

Git – Comandos Básicos #1

Siguiendo con la serie de posts Git lo estas usando mal les voy a comentar los comando básicos y algunos conceptos que nos vas a ayudar a entender un poco más.

Lugares en GIT

Para comenzar con los comandos básicos tenemos que entender que en Git podemos distinguir 4 lugares.

 

El primero es el directorio local de trabajo,  es donde se trabaja, se crean nuevas funcionalidades, se arreglan bugs, se crean archivos, etc.

Luego el area de cambios (Staging), en este lugar vamos a poner todas las cosas que queramos versionar con Git.

Una vez que estemos seguros de lo que queremos versionar, lo vamos a pasar al repositorio local.

El último lugar es el repositorio remoto, donde vamos a enviar los cambios que tengamos en nuestro repositorio local, para hacerlos públicos.

A medida que vayamos viendo los diferentes comandos vamos a ir refrescando estos lugares.

Comandos Básicos

Crear repositorio

Lo primero que vamos a hacer es crear un repositorio en Github. Un repositorio es el lugar donde vamos a guardar el código fuente de nuestra aplicación.

Desde la pagina de inicio podemos crear un repo haciendo click en «+ New Repository»

Ponemos un nombre de repositorio y seleccionamos «Initialize this repository with a README»

Clone

En la página del repo nos va a indicar la dirección ssh.

Una vez que la copiamos, vamos a la consola y ejecutamos

git clone [dirección ssh]

En mi caso es

git@github.com:ignaciojonas/test-git.git

Este comando nos va a crear una carpeta (Directorio de trabajo local) con le nombre del repo que tiene, el README.md y una capeta oculta que se llama .git

Status

Con este comando vamos a ver el estado actual de nuestro repositorio local. Es importante recalcar que en Git siempre vamos a ver el estado de nuestro repositorio en nuestra maquina, ya que Git guarda toda su información localmente y te permite seguir trabajando aunque estés desconectado de internet.

Dentro de la carpeta del repositorio ejecutamos

git status

Si no cambiamos nada nos debería mostrar algo como esto:

• En que branch estamos parados (Ya vamos a ver esto mas adelante)
• Si nuestro branch esta sincronizado con el repositorio en Github (por defecto el repositorio de donde clonamos se llama origin)
• Por ultimo que no tenemos ningún cambio, y que nuestro directorio esta limpio

Si ahora modificamos el archivo README.md y le agregamos por ejemplo

Este es un repositorio de prueba para comenzar a usar Git.

Una vez que grabamos el archivo y volvemos a ejecutar git status vamos a ver algo parecido a esto:

Las primeras lineas son lo mismo que antes, pero vemos que ahora dice «Changes not staged for commit:» y nos da instrucciones para actualizar el archivo en el repo o rechazar los cambios. Por ultimo en rojo vemos el archivo que se modificó.

Add

Con el comando add vamos a indicarle a Git que queremos agregar algo al repositorio, ya sea algo nuevo o algo que modificamos.

Por ejemplo vamos a agregar el archivo README.md

git add README.md

Cuando tenemos muchos archivos y queremos agregar todos al area de stage podemos hacerlo con

git add .

Si tenemos archivos nuevos, tenemos que agregarlos por nombre (como lo hicimos con README.md) o bien agregando todo pero usando el siguiente comando.

git add -A

Ahora cuando ejecutamos git status vemos algo como esto:

 

Vemos en la segunda linea, «Changes to be commited», esto quiere decir que ya tenemos los achivos seleccionados para poder grabarlos en la historia.

Ahora nuestros archivos se encuentran en el segundo lugar de Git, el area de cambios (Staging). Para tener una imagen gráfica de esto es como poner las cosas arriba del mostrador, para que después alguien del otro lado lo guarde.

Commit

El comando commit nos va a permitir «grabar» en la historia los cambios que hicimos.

git commit -m "[mensaje representativo]"

Es muy importante que los mensajes de commit (Lo que esta entre comillas dobles) sean representativos. De nada sirve un mensaje muy genêrico, como por ejemplo «Cambios Varios», siempre es mejor ser explícitos. Pensemos que lo que escribamos en la historia de git va a ser leído por todos los de mi equipo y cada uno le puede interesar ver donde se hizo un cambio especifico.

Por ejemplo en el ejemplo que estamos siguiendo en este post un buen mensaje sería

git commit -m "README.md - Agrego información de prueba"

Cuando ejecutamos este comando vamos a ver algo asi

Una vez ejecutado este comando, habremos agregado los archivos al repositorio local. Este commit queda grabado en la historia de Git en mi repositorio local hasta que lo subamos a un repositorio publico.

Ahora cuando ejecutamos git status, vamos a ver que nos da un mensaje que dice: Your branch is ahead ‘origin/master’ by 1 commit. Esto quiere decir que lo que esta en Github, esta «viejo», ya que yo tengo un cambio en mi maquina que no esta en ese repositorio publico.

En este punto nuestro archivos están en el tercel lugar de Git, el repositorio local, el cambio que hicimos a README.md esta grabado en la historia de Git.

En la próxima entrega de Git – Lo estas usando mal, vamos a ver como hacemos para que todos estos cambios que hicimos localmente, lo pueda ver otro miembro de nuestro equipo, como sincronizar nuestro repositorio local con el repositorio remoto y las primeras resoluciones de conflictos.

 

Configurar GIT

Siguiendo con la serie de post, hoy les voy a comentar como tengo configurado GIT en mi maquina.

Configuración basica

Identidad

Para empezar, tenemos que configurar el nombre de usuario y el mail. Para esto ejecutamos los siguientes comandos, reemplazando con nuestro nombre y nuestro email.

$ git config --global user.name "Ignacio Jonas"
$ git config --global user.email ignaciojonas@example.com

Editor de texto

Cuando queramos editar un mensaje de un commit o hacer un rebase o algunas otras cosas que vamos a ir viendo mas adelante, algo que vamos a necesitar es un editor de texto. El que más me gusta a mi es Vim, pero ustedes pueden usar el que quieran.

$ git config --global core.editor vim

Si no se sienten cómodos usando un editor de consola pueden incluso usar cualquier otro editor gráfico. Para configurar Atom por ejemplo:

git config --global core.editor "atom --wait"

El flag –wait hace que Git espere a que cerremos el editor para commitear.

AutoCRLF

Cuando estamos trabajando en diferentes plataformas (parte del equipo en Linux, otros en Mac OS y otros en Windows) es importante prestarle atención a cómo tenemos configurado Git con respecto a los fines de línea, ya que puede que tengamos algunos problemas.

Git nos ayuda a no tener estos problemas convirtiendo los fines de linea CRLF (Windows) en fines de linea LF (Unix).

Si usas Windows conviene tenerlo configurado en true, esto convierte los fines de linea LF en CRLF cuando hacemos checkout del código.

$ git config --global core.autocrlf true

Si estas trabajando en un sistema operativo Unix (Linux o MacOS), no es necesario que Git convierta los fines de linea, sin embargo, si por casualidad introducimos un fin de linea CRLF, conviene que Git se haga cargo por nosotros de convertirlo en LF. Para esto lo configuramos con el siguiente comando.

$ git config --global core.autocrlf input

Por último, si todo el equipo esta trabajando en Windows, haciendo un proyecto para funcionar solo en Windows.

$ git config --global core.autocrlf false

Como veo las configuraciones?

Para ver como tenemos configurado Git lo único que tenemos que hacer es ejecutar el siguiente comando

$ git config --list

Configurar la clave SSH

Para poder identificarnos contra un servidor que tenga una copia de el repositorio lo podemos hacer de diferentes maneras. La más común es conectarnos usando una clave SSH.

Para todos los ejemplos de esta serie de posts, vamos a usar GitHub. Si no tenés un usuario podes registrarte acá.

Crear una clave SSH

Si tenés una clave ssh creada, entonces podes ir a Configurar la clave SSH en Github.

Para generar una clave SSH basta ejecutar el siguiente comando.

$ ssh-keygen -t rsa -C "your_email@example.com"

Cuando ejecutamos, nos va a aparecer algo parecido a lo siguiente, apretamos enter. La clave SSH se va a guardar en una carpeta .ssh dentro de la carpeta de nuestro usuario.

Generating public/private rsa key pair.
# Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Apretar Enter]

Luego nos va a pedir que ingresemos un passphrase. Es recomendable que pongamos una buena frase, aunque no es obligatoria.

Una vez que hecho esto tenemos la clave SSH generada.

Configurar la clave SSH en GitHub

Para agregarla a Github, lo primero que hacemos en loguearnos con nuestro usuario.

Vamos a Settings->SSH Keys y hacemos click en Add SSH Key.

Completamos un titulo (Para recordar donde tenemos configurada esa clave SSH) y en el campo Key ponemos el contenido de nuestro archivo ./ssh/id_rsa.pub.

Para copiar el contenido (al menos en Mac OS) podemos ejecutar

$ pbcopy < ~/.ssh/id_rsa.pub

Este comando nos copia el contenido de la clave publica en el portapapeles.

Por último hacemos click en Add Key.

Con esto terminamos la configuración básica de Git. En los próximos posts les voy a contar como empezamos a usarlo.

Instalar GIT

Empezando con esta serie de posts, les voy a contar como instalar GIT.

Hace muy poco me mude a trabajar en Mac OS Yosemite y un colega del trabajo me mostró iTerm2, es una consola mejorada para Mac OS. La verdad que es mejor que Terminal (Default en Mac OS). Así que te recomiendo que la instales porque mejora muchísimo la experiencia.

Si estas pensando usar GIT en Linux, la consola por default esta más que bien.

Si vas a usar Windows, te recomiendo que te instales cygwin, que es un emulador de la consola de Linux para Windows. Con esto tenes todo el poder de la consola de Linux, pero en Windows.

Si no sos muy amigo de las consolas, existen interfaces gráficas para GIT y en algún post voy a publicar algunas, pero para entender bien el funcionamiento de GIT lo mejor es la consola (@mrleinad dixit).

Instalación en Mac OS

En Mac OS, GIT, viene instalado por default, pero es recomendable que te instales la ultima version usando brew y algunos plugins más.

Antes de empezar podemos ver que GIT es el que tenes instalado, abrí iTerm y ejecutas

which git

Si la ruta de GIT es /usr/local/git entonces vamos a desinstalarlo haciendo lo siguiente (Usar sudo en los comandos cuando sea requerido).

rm -rf /usr/local/git
rm /etc/paths.d/git
rm /etc/manpaths.d/git

Ahora vamos a instalar brew con el siguiente comando:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Una vez instalado brew vamos a seguir con la instalación de GIT

brew install git
brew link git

Si el último comando produce un error podemos arreglarlo haciendo

brew update
brew upgrade
brew doctor

Por último instalamos git-completion que nos sirve para que la consola autocomplete los comandos de GIT cuando apretamos TAB.

brew install git bash-completion

Instalar GIT en Windows

Para empezar hay que bajarte la ultima versión de cygwin.

Ejecutas el instalador de cygwin y seleccionas todas las opciones por default hasta el menu de seleccionar paquetes (Select Package)

En ese menu hay que elegir:

• git-gui
• gitk
• git-completion
• openssh
• vim (si no esta seleccionado por defecto)

Update: Un aporte del grande  de @andresgariglio

@osolaborioso También para la windola tenés https://t.co/ioGRJp3BKS

— andres (@andresgariglio) January 15, 2015

Instalar GIT en Linux (Ubuntu)

Simplemente

sudo apt-get install git-core git-completion

Con esto tenemos todo el ambiente funcional para empezar a aprender GIT.

Git – Lo estas usando mal

Muchos sabemos que GIT es un «muy potente» sistema de control de versiones. Y también muchos pasamos horas/días tratando de entender que es lo que «esta haciendo». Cuando me pasa eso, @falvarisqueta siempre me dice a tono de chiste «Los estas usando mal», o también, «el problema esta entre la silla y el teclado; y no en GIT».

En esta serie de posts (GIT – Lo estas usando mal) voy a ir publicando lo que fui aprendiendo en este último tiempo que comencé a usarlo de una forma un poco más intensiva y profesional.

Algunos de los tópicos que tengo planeados:

• Instalar GIT
• Configurar GIT
• Comandos Básicos
• Rebasing
• Como hacer un merge
• Re-escribir la historia
• Workflows de Trabajos – Feature Branch

 

Git – Cómo poner el nombre del branch en la Consola

Para todos los usuarios de Git, algo importantísimo es saber donde uno esta parado, en que branch está. Hace unos meses estoy usando Ubuntu para el trabajo y modifique un poco la consola para que se vea el nombre del branch cuando estoy parado en un repositorio.

Para hacer esto hay que seguir los siguientes pasos:

• Parados en el home de nuestro usuario ejecutamos: gedit .bashrc
• Agregamos el siguiente código en el archivo (abajo del todo)

• Guardamos y cerramos .bashrc
• Ejecutamos: source .bashrc.  Esto recarga la configuración de la consola
• Voila el nombre del branch va a aparecer en la consola cuando estemos dentro de un repositorio de Git.

Integración Continua – Team City + GIT + MVC4

Dentro de los desarrollos de aplicaciones, utilizando metodologías agiles existen muchisimas buenas practicas, que nos ayudan a llegar a una mejor calidad del producto que estemos desarrollando. Una de estas es implementar un servidor de intregración continua.

En este post vamos a explicar, cómo instalar y configurar un build server, utilizando Team City en un Windows 7. Este build server va hacer build de nuestra aplicacion MVC 4 y genere un paquete de instalación.

Para los que no saben que es la integración continua o continuous integration es:

Un modelo informatico propuesto inicialmente por Martin Fowler que consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes.

Manos a la obra

Pre-requisitios

Una maquina con Windows 7, Visual Studio 2010 y MVC 4.

El instalador de Team City 7.1

Ahora si, con todo esto, manos a la obra.

Instalación de Team City

En nuestra instalacion de Windows 7, ejecutamos el instalador.

Click Next

 

Click I Agree

 

Seleccione la carpeta donde quiere instalar Team City y click Next

 

Seleccione toda las opciones. Click Next

 

Seleccione el puerto donde va a atender la web de Team City. Click Next.

Seleccione directorio donde Team City va a guardar las configuraciones. Click Next.

Configure el agente que va a hacer el build (configuracion por defecto). Click Save

Seleccione los usuarios para ejecutar el agente de build, (en ambos casos configuracion por defecto). Click Next

Seleccionar ambos. Click Next

En este punto Team City ya está instalado en nuestra maquina,

Configuración de Team City

Luego de aceptar la licencia, seleccionando accept license agreement un haciendo click en Continue.

Completamos el nombre de usuario y contraseña del usuario que va a ser nuestro administrador. Click  Create Account.

En este momento podes hacerte un marcador en tu navegador de la URL de Team City, para tenerlo bien a mano.

En la página principal de Team City hacemos click en Create a Project.

Lo primero que hacemos es ponerle un nombre al proyecto. Click Create.

Click Create Build Configuration.

Complete el nombre con el que se va a identificar el build. Por ejemplo si en su poryecto se van a compilar mas de una solución, un buen nombre sería el nombre de cada solución,

Click VCS Settings

Click Create and Attach a new VCS Root.

Seleccione Type VCS -> Git.

• VCS Root Name: Dirección del repositorio GIT( accesso ssh) + #master
• Fetch URL: Dirección del repositorio GIT.
• Default Branch: master

En la sección Autentication Settings

• Authentication Method: Private Key
• Private Key Path: Dirección de la key ssh privada que tiene permiso de accesso al repositorio en GitHub.

Click Test Connection.

Si la conexión se pudo establecer, vamos a obtener un cartel como el siguiente

Click Save.

Dejar todas las configuraciones por defecto. Click Add Build Step.

• Runner Type: MSBuild
• Step Name: Un nombre que identifique el paso de build.
• Build Path File: Dirección dentro del repositorio al proyecto que vamos a compilar.
• MSBuild Version: Framework 4.0
• MSBuild Tool Version: 4.0
• Run Platform: x64
• Targets: PublishtoFileSystem (esto lo vamos a configurar más adelante en el archivo del proyecto)

Click Save

Click Build Parameters

Click Add New Parameters, agregar uno con las siguientes características:

• Name: PublishDestination
• Type: System
• Value: Lugar en el disco donde queremos que se genere el paquete de instalación.

Click Save

Ahora en General Settings agregar a la sección Artifacts Path la dirección donde se va a generar el paquete. Click Save

Configurando un trigger

Si queremos que al momento de que cualquier miembro del equipo suba código al repositorio, el build server compile nuestra solución y genere un paquete instalable, tenemos que configurar un trigger en Team City, para esto vamos a la sección 5 de las configuraciones del proyecto Build Trigger. Hacer click en Add new trigger.

Seleccionar VCS Trigger, y chequear Trigger a build on each check-in. Click Save.

Ahora cada vez que alguien suba algún cambio al repositorio, el agente de Team CIty va a ejecutar la compilación de nuestra solución.

Nuestra solución MVC 4

Para este ejemplo, hice una aplicación «Hello World» en MVC4, para poder compilar la solución utilizando un repositorio público de GitHub. El que quiera usarlo, solo tiene que bajarlo.

Dentro del proyecto de la solución, tenemos que agregar un nuevo Target. Esto nos va a servir para indicarle a MSBuild como generar y donde dejar el paquete instalable.

Para hacer esto tenemos que, hacer unload del proyecto. Para eso hacemos click con el botón derecho en el proyecto y seleccionamos Unload Project.

Botón derecho sobre el proyecto y click Edit…

Buscar la sección Target y debajo de la existente crear una nueva con el siguiente contenido:

	<Target Name="PublishToFileSystem" DependsOnTargets="PipelinePreDeployCopyAllFilesToOneFolder">
	<Error Condition="'$(PublishDestination)'==''" Text="The PublishDestination property must be set to the intended publishing destination." />
	<MakeDir Condition="!Exists($(PublishDestination))" Directories="$(PublishDestination)" />
	<ItemGroup>
	<PublishFiles Include="$(_PackageTempDir)\**\*.*" />
	</ItemGroup>
	<Copy SourceFiles="@(PublishFiles)" DestinationFiles="@(PublishFiles->'$(PublishDestination)\%(RecursiveDir)%(Filename)%(Extension)')" SkipUnchangedFiles="True" />
	</Target>

view raw

gistfile1.xml

hosted with ❤ by GitHub

 

Guardar el proyecto y subir los cambios a GIT.

Una vez subido los cambios a GIT, el build server ejecutará automáticamente el build de la aplicación. Si vamos a la página principal de Team City veremos que el build esta corriendo.

Cuando éste termina, en la sección Artifacts vamos a encontrar todo lo que se generó en el paquete de salida.

Si hacemos click en Artifacts vamos a ir a una sección donde podemos bajar el archivo .zip con el paquete de instalación.

Ahora ya pueden decir que número de build de su aplicación están instalando en un servidor, llevar tracking de las features que se van agregando y en que build están presentes, integrar toda la aplicación en cada commit y demás.

Espero que les sirva este post y puedan implementar un build server en todos sus proyectos.

Nos leemos!